In any major endeavor, pitfalls, misunderstandings, conflicts and other traps abound. Agile software development is no exception. Here are the top 10 agile traps:
- Over planning at project inception then not updating the plan
- Protecting functional departments
- Poorly managing the backlogs
- Focusing on tools
- Focusing on process
- Believing that the customer cares about the implementation
- Thinking the customer knows all the answers
- Failing to track velocity
- Not allowing time to pay-down technical debt
- Not doing enough testing
Here is a brief discussion of each of these traps. Please feel free to add or refute this list in the comments.
1. Over planning at project inception then not updating the plan
It’s common for teams new to agile to over plan. It derives from their waterfall background. Compounding matters, they fail to keep the plan up to date as new information becomes available.
2. Protecting functional departments
This is an organizational problem. Engineering, QA, Project Management, Product Management, etc. want to preserve their command and control structures. So much for self-organizing teams.
3. Poorly managing the backlogs
Agile development includes several backlogs — product, sprint, defect, release, etc. These backlogs have to be actively reviewed, prioritized and culled.
4. Focusing on tools
Software people love software tools. While those tools can help in operating agile projects, they are not a panacea. You can do it without automation tools.
5. Focusing on process
Some people like procedures — step 1, step 2, step 3… Software development is not like that. It is part science and part art. Agile approaches are lightweight and should remain so.
6. Believing that the customer cares about the implementation
Customers care about operational processes and business results. Talking to them about implementation details and technology trade-offs will cause them to glaze over and lose interest.
7. Thinking the customer knows all the answers
Customers have a wealth of information and so do developers. Neither has all the answers. That’s why we create cross-functional teams.
8. Failing to track velocity
The only way to reliably estimate new stories is to have a track record. The team needs to know how long stories will take and how many stories can be done in a sprint.
9. Not allowing time to pay-down technical debt
Technical and other forms of project debt are inevitable. That’s okay as long as the team allocates time within sprints to pay-down the debt.
10. Not doing enough testing
If your sprints are jam-packed with stories, you will likely skimp on testing. Call it testing debt. It will catch up with the team and the customer will not be happy about it.
Okay, that’s what I think. What do you think?