Saturday, March 12, 2011

How to fail at agile

So I found a nice little article while researching scrum. It's written as 20 ways to sabotage the adoption of an agile development process, but what I think they're really getting at is traps and pitfalls to avoid. It has sections on the manager, team, and product owner, but since most of us are going to be in the "team" category, I'll focus on summarizing that part. Each point is labeled with the number used in the article, which can be found here

Guideline 6: Continually failing to deliver what you promised.
This would be a big problem in any situation, but with agile it can kill the entire process. The team is expected to deliver a functional "product" that could potentially be shipped at the end of each iteration, and to do that they need to know what the team can commit to. Having a team member keep everyone else guessing like that is just cruel

Guideline 7: Moving work forward to the next iteration casually.
If you're missing your sprint goal, you need to evaluate your estimations of how long those items are supposed to take. Brushing off incomplete goals like that is just asking for trouble

Guideline 8: Not creating cross-functional teams. This one's fairly obvious. If you want to go through the entire design-build-test process for an iteration, you're going to need people who can do all that. Putting all your testers on one team, for example, practically guarantees that you won't be able to have a team put out a complete product for that iteration

Guideline 9: Large groups. As group size grows, group overhead grows with it, and you lose the responsiveness and speed an agile process is supposed to help create

No comments:

Post a Comment