Re: My experiences moving a company from traditional development to XP ...

Hi Zeb / Sandy,

I know you didn't ask for advice, but I found that I had some left over
from a time when someone did ask. Feel free to ignore it. ;->

On Tuesday, January 14, 2003, at 9:33:02 AM, Sandy wrote:

> Fortunately, my position allows me to change that. I'm currently trying to move the
> company to a hybrid of XP and Scrum, but it's a harder battle than I first imagined
> for several reasons:

> * Sales and Marketing are used to getting their way, so it's hard to say "We won't
> give you a date for all the features you've requested, but we'll show you stuff as it
> gets done."

So don't say that. Say instead: "Here's how long it will take to do each of
your features. We'll do them in any order you want. You want a release by
August? OK, you can have any twenty."

> * Developers aren't used to having people review their code and some even take
> offense to it. Hilarious.

Neither Scrum nor XP recommend code reviews, though some teams use them. XP
does recommend working together. That's not code review, it's partnership.

> * Management from other departments don't like to know that time is being spent to
> refactor ugly, but functional, code. "Just get me more features"

Then don't refactor ugly but functional code. Write clean functional code.
Do so by making sure that your code never deviates from clean by very far,
and bringing it back into line immediately, not as a separate process.

> During this current release that the team is working on (the old way), my promise to
> management is to quantify a set of development metrics. Ideally this will help my
> manager know what we are working with code-wise and how applying a new methodology
> might improve it. 
> 
> So, during this phase, we are focusing on two things:
> 
> 1. Consistant coding style (it's a hodge-podge of personal conventions right now).
> 
> 2. Code review 50% of all functional areas, but don't start refactoring or writing
> unit tests. 
> 
> The code reviews should identify common programming errors like:
> * Tight coupling between modules/components
> 
> * Block-copy code
> 
> * No error checking
> 
> * Dead code
> 
> * Bogus comments
> 
> etc.

Sounds good. The code review should serve, if nothing else, to help the
programmers see, hopefully in a non-threatening way, that there is
improvement to be made.

Keep us posted, please ...

Ron Jeffries
www.XProgramming.com
Speculation or experimentation - which is more likely to give the correct answer?


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Flexible Keyboard is the ideal accessory for PDA users that are on the move.
http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/nhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
[email protected]

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/