Lean development #7
(Continuing my unfinished post from yesterday.) So, doing by-the-book XP is wrong (unless, magically, your circumstances happen to match those of the primordial XP project). It’s a starting point; after a few iterations, you will begin adapting it to your organization.
Poppendieck writes about an automobile plant that was a real disaster: alcohol problems both on and off site; strikes; high sick leave rates. It is closed down, only to re-open under mixed management between GM and Toyota. The bulk of the previous workers return. The plant turns into a huge success: productivity is higher than any other GM plant; quality is much higher; the problems are essentially gone and the 90% of the workers say they are satisfied, or very satisfied.
The decisive factor seems to have been the fact that the workers are reorganized into small teams with the power to self-organize, self-manage. Previously, there were trackers measuring their effectivity; after the reopening they were trained to measure themselves and left with the freedom to find out how to improve. (This makes me think of the Engines of Democracy article in Fast Company that I have blogged about earlier.) But the interesting thing was when GM wanted to transfer this success to their other plants, something that they according to Poppendick have been unable to do.
Poppendieck is careful to point out that there are no simple answers to this question, but one interesting clue is that they might just have tried to clone what had evolved at the successful plant, forgetting that it had evolved to that form because of local circumstances, and that it was still evolving. It’s the same with XP.
One thing I remember having read on XP mailing lists (and in some XP book, I think) is what you should do with team members that refuse to program in pairs. The basic idea is that you should tell them that pair programming is the most effective way to do things, and if they don’t stop resisting, you should have them replaced. But you can’t force XP on people. It won’t work if it isn’t accepted by the team members. Adopting XP is in most cases a rather dramatic change of culture; even if you consider yourselves “agile” from the start, there can be many subtle, but significant culture clashes – subtle because you thought that your organization was something that it was not, so the reality clashes with XP and you might not be able to easily see why. (See my XP and culture post.)
Popppendieck quotes someone (I can’t find it now) as saying that the greatest demotivators are policy, supervision, and administration, and that the greatest motivators are achievement, recognition, and responsibility. I have thought lately about the importance of individual freedom in software projects. These demotivators and motivators are definitely about freedom, and the NUMMI story shows that individual freedom can make a big difference (the same goes for the team portrayed in the Engines of Democracy article). What is needed is a clear overall vision and a team of skilled people that are free to find the best way to make that vision real. I can’t remember if I have blogged about this, but Poppendieck writes about the importance that individuals feel that they are allowed to make mistakes – or, in fact, that they should make mistakes. Making mistakes is a necessary element of achieving success, and she writes that companies that are very successful (and hence innovative) have a tolerance for mistakes (I know that she mentions 3M in this context).