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

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

  > Welcome! And thanks to Pat.

   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.

  > What's the result? From the customer end that is?

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

  > I'd guess they aren't /really/ getting things the way they would like.
Do they know that? Do they have a set of problems that /they/ would like to
have solved?

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

  > Great opportunity: Do code review! Make it unpleasant - which ain't
hard. Then introduce voluntary pairing, exempting those who do it from the
code reviews. Manipulative? Maybe. ;-)

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

  > Since you are going to be introducing (proper, small-step) refactoring,
I suggest finding another word for what you have to do to the ugly, but
functional, code. Or, lacking that, find a way to do it in small steps.

  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.

  > Try from the start to get management to look at the team output, not
effort. And  by output, mean output in terms of business function. As a new
person, you have an opportunity to get them looking at the right measures...
which have nothing to do with code.

  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.

  > I can't tell if you've let the developers know where you hope to go
eventually. If not, consider doing it and seeing what parts of it they may
be willing to buy into right away. Negotiate the others as the occasion
arises by getting them to give them a good trial - three or four weeks. This
is a bit scary, since they may use their freedom to /not/ do what you want,
but if done right it can result in a much stronger buyin.

  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.

  > Again, tell them you're doing this. They'll assume you are anyway.

  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.

  > Fascinating. Please continue.

  Charlie Poole
  [email protected]
  www.pooleconsulting.com
  www.charliepoole.org