Introducing Extreme Programming
From J. Arrizza Wiki
>From: "Christian Sepulveda" <email@example.com> >This experience has contributed to a question for which I am conflicted: Is >it better to adopt a gradual transition to agile development or commit to >full XP, for example, and adjust later? I think context has a lot to do >with >it, but its not clear what context "markers" indicate whether a transition >or a dramatic change is the more appropriate.
Big Bang does not work unless: - your team is already working well together. They are sincere about trying XP, they are technically and emotionally competent. e.g. if there is a weak member on the team or a passive-aggressive on the team, his/her attitude will show up in with a big loud bang and you will blame XP for it.
- your development team is *really* on board with XP. They must not have a "say-yes-to-management-because-I'm-scared-to-get-fired" attitude. XP requires capital-P Participation from everyone. Especially when it is being initially rolled-out. e.g. They can't say "I'll refactor" and then pull out 2 lines out of their 150 line function and claim "I refactor!"
- your development environment is already up to snuff. XP stresses development environments. e.g. if you don't have your source control under control it will show up with a big loud bang and you will blame XP for it. In my experience, there is a tremendous amount of politcal and techincal inertia in the build system. I guess the difficulty in getting the thing to work at all and the criticalness of it causes the inertia. You might not be able to change it because too many people refuse to allow you to.
- management is *really* on board with XP. They must not be doing "airplane-magazine" management. e.g. they say yes we want emergent design, no BDUF, etc. and then call week-long design sessions with "the boys". They can't say "1 week iterations except this week and next week and that week"
- management is patient. They must recognize that your development enviroment and your development team are tightly integrated as a symbiotic whole, changing an aspect of one will affect the other. Those changes perturb other aspects of the whole and so on. It is a dynamic system that is held in equilibrium by a lot of effort by a lot of people, changing any part of it requires those people to understand at a fine level what is required for them to do in the new setup. Your management has to recognize that it will take time to change all these things *and* have it run as smoothly or better than it did before.
Now assuming you have all of these things in place, why do you want to convert to XP? You have a well-run shop with intelligent, coherent management and developers! :) My point here is that chances are you are considering XP because you are having problems not because things are going well. Because of that you will face a lot of political, technical and personell problems. I suggest, then, going slowly, i.e. gradual transition.
just a thought, john ] [ >The individual practices, just like XP in general, need a supportive >context to be successful.
Very much true in my experience! However this is not as negative a situation as it appears. In fact, it can help in introducing XP into a company.
First step, analyze the company's context. What are they currently doing? what are they competent at? what are they most amenable to changing?
Second step, determine which one of the XP practices is most likely to be acceptable to them. Which one requires the least amount of change for the company? Which one are they already doing or almost doing?
Third step, introduce the practice to them and then "predict" where there will be failure points. For example, say 1 week iterations are the most likely to be acceptable. Some failure points with 1 week iterations are: - a task can take longer than a week, how do we merge that task in? - the integration time for only a week's worth of work is pretty small, but as a percentage it can be fairly high. How can we reduce that integration time? - it seems that Fred likes to claim he's "done" but every week we have to go back and "fix" his stuff. What can we do about that? - etc.
If this step is done well you should have a bagful of credibility at this point. You have to sell this to the developers and the managers. If the developers don't buy-in, they will sabotage your efforts. If the managers don't buy in, they will override your efforts or just cancel them altogether. Beware of the manager who wants a complete process revamp "yesterday", this stuff takes time.
Fourth step, use that credibility to introduce the other practices to fix the failure points that you "predicted".