Subscribe to the blogWhen Agile Projects Go Bad
Posted on March 30th, 2009 in Agile, Methodology by siddharta || No Comment
ComputerWorld UK has an excellent article that quotes Alistair Cockburn and Kent Beck about agile projects that go bad. The most common cause of failing agile projects is when teams apply agile practices without understanding the principles behind them, leading to dysfunctional application of agile. This has been documented many times. However, it is also possible to reach a dysfunctional state when you apply the practices too much to an extreme, ignoring everything else. This is an interesting case – a team that is too religious about the practices, that again causes the project to fail.
I was long ago involved in a project where I decided to adopt unit testing. This was sometime in 2003 or so. I got so fixed up on it that we stopped delivering value to the customer. This is a perfect example of what can happen when you focus too much on the practise that you ignore the bigger picture. But the reverse is also true: Stop writing unit tests and you may deliver value for a while, but you will incur a huge amount of technical debt.
An experienced agile team can see both these extremes and choose a path that is best suited for them. Teams new to agile will usually end up on one of these extremes, probably even oscillating between both for a while before they correct the course to a level that works for them.
In the article, Alistair and Kent mention the following dysfunctions:
- Checklist processes: When you have a checklist in front of you and you do practices without understanding them only because the checklist tells you that it needs to be done. Example: Checklist says we need to do a standup – so we do a status meeting that takes 1 hour, everyone reporting to the ScrumMaster
- Missing out the big picture: Asking the customer only for requirements for the next iteration and missing out the big picture in the process. This happens whe you become so focussed on gathering and completing individual stories that we lose out on why we are developing them or whether these are the right stories to be done in the bigger context of the system. Jeff Patton has a fantastic explanation of this dysfunction along with a possible solution in his article “The new user story backlog is a map.”
- Sudden increase in scope: Quoting Cockburn – The ‘Agile’ team might say, “This looks like 170 story points,” but they don’t have any basis for that estimate. It turns out to be 700 story points, “But they only discover that as they go along, much to the depression of everyone involved”
- Not knowing when a practise doesn’t make sense: A variation on the checklist process is when a practice doesn’t make sense for the situation at hand, but it gets done because the book/coach/checklist said so.
- Not engaging the sponsors and customers: With a weak product owner, the programmers may end up deciding the backlog. At the other extreme, the programmers never make a decision, pushing all decisions back to the product owner.
- Sometimes agile is not the right process: For certain situations, another process may make more sense, but the management adopts agile because its the latest buzz word.
Finally, the biggie (especially with hardcore agile teams): Agile as a religion. Quoting Cockburn again:
Sometimes Agile principles are grossly misinterpreted, according to Cockburn. “I get called in by a CIO, CTO, any CXO, and they’re suffering because their programmers are telling them ‘You don’t know anything about Agile. Agile means we don’t have to give you a plan, Agile means we don’t need an architecture’-a whole bunch of rubbish that isn’t in the Agile manifesto.”
So Cockburn, or people like him, have to come in and tell the CIO that it’s okay to ask for a plan and an architecture. “But it takes me to come and do it,” Cockburn says. “If anyone else says it, they get told that they’re just an old fuddy-duddy, [and that] they don’t know anything about Agile.”
All in all, this is a fantastic article. I highly recommend everyone to read it, especially those who have been doing agile for a while. It provides a balancing view to a lot of the agile stories on the web. Read the whole article here.
