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

Hey all!

Just joined this group on recommendation from Pat Welsh from http://www.saorsa.com/. 

I've been working with a company for the past two years, where we used XP from day 1. We had a truly distributed development environment with nearly 20 developers all over Canada and the US, as well as Europe and Australia (gotta love CVS sometimes). Code was heavily, heavily reviewed and refactored, unit tests were written under penalty of death. Stability was huge and productivity was awesome. All meetings were done via wiki, IM and, if push-came-to-shove, the phone. 

Then I switched companies. 

Design for several weeks. Write mountains of documentation (that was immediately obsolete). Code like hell to meet a schedule imposed by sales and marketing. Code was never reviewed and now is so tightly coupled and in dire need to refactoring, it's almost a monumental effort. Integration nightmares. Debug for weeks on end. Ack! You know where I'm going. 

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."

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

* 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"

The list goes on. 

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.

In addition to letting us know the state of the code-base, this also permits me to understand which developers are the most/least productive. 

I'll chat more about this as I get closer to some results. It should all start to shake out over the next week or two. 

Stay tuned, and I look forward to your input. 

-Zeb (alias :-)

 

 



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now