Why agile transitions fail ?

I finally had the revelation, the answer to that puzzling fact that, no matter how much effort and faith a company puts into its transition to Agile methods, it fails. Well it is a bit blunt. Some actually succeed. And others manage to maintain a pretence of success for years.

I have been reading Peopleware recently and found the answer there. I am sure it exists in other places as well. It is not as if it was a hidden treasure of wisdom or a lost manuscript by aristotle. It is the well known fact that change is difficult. So difficult actually that the authors of Peopleware advise to effect only one change at a time ! And here is my realisation. To transition to Agile takes more than a single change. You have to change how people work together collectively, how they work individually, how information flows inside and out of the team and even what type of communication is needed. Any of these changes is challenging by itself. These categories may even hide multiple changes (switching to Test Driven Development and Pair Programming for instance).

Interestingly, this realisation ties perfectly with an open space discussion that happened at the BayAPLN a while back where we discussed the strategies to effect a successful transition to Agile. We came to the conclusion that it was easier (necessary ?) to foster change agents (positive deviants). Another successful approach was to sandbox agile practices. Agile sand boxing is essentially an attempt to transition small isolated (geographically or functionally) groups that are willing to become agile. For obvious reasons, groups that are not sand boxed are likely to be crushed by the rest of the company. The sand boxed group is freer to experiment with practices and to be allowed to progressively install new standards. The rate of possible change is also arguably improved.

So now I think I have linked the reason for failure and the path to success. Or am I missing something ?

3 Responses to “Why agile transitions fail ?”

  1. tim Says:

    I think you’ve got a good point. Agile contains so many mutually-reinforcing practices that it’s difficult for an organization to see the full benefit from only adopting some at a time. But on the other hand, most rational organizations would be reluctant to adopt a whole slew of entirely new practices without first trying to phase them in and measure benefit as they go along.

  2. cesar Says:

    I agree with tim. I would also suggest that agile transformations would benefit from making a bigger issue of “pairing” practices. What have others experienced on this front? Are the “agile” teams you have observed conscious of the cause and effect of picking and choosing practices? I’m not saying you shouldn’t pick and choose; I’m just saying that the reason why the luminary likes of Craig Larman advice the rest of us to “try it by the book first” is that picking and choosing is challenging even to them!

    My hypothesis is therefore that the reasons agile transformations fail include “not doing it by the book and picking unpaired practices”. The next test is to find what are the success rates of companies that choose all-out transformations.

  3. Denis Says:

    So how can the people in an organization absorb so much change in a single go ?

    I probably need to get on reading Fearless Change now ;)

Leave a Reply