At Agile 2008, Henrik Kniberg
gave a presentation on 10 ways to screw up despite Scrum and XP1. Believing the Hype: That is, believing that if you go agile, all problems will disappear. You throw out everything you are doing now even if it works and then get the latest and best tools and focus on perfection.
2. Definition of Done: But you said you were done? Not having a definition, or not obeying the definition, or having done be outside of the teams control (no access to production). Good examples of Done are: unit and integration tested, acceptance tested and deployed to demo site. Or Releasable (acceptance tested, release notes written) and no increased technical cost.
3. Velocity: Not having one makes it hard to create a release plan. Having one and misusing it by comparing different team velocities. Or having a yo-yo velocity where it is high one sprint and very low on another sprint (indicates spending a lot of time fixing bugs).
4. Retrospectives: We are very busy so we skip it. And if we do it, changes and recommendations are ignored and not implemented. Having unwanted people in the meeting where the team feels uncomfortable and do not participate. Punishing the team for bad changes (the whole point is to try something and later evaluate it to see if things improved).
5. Team commitment: Team is pressured, Team is not sitting together, team does not track and learn and keeps repeating the same mistakes. Team is always undercommiting (team always looks good) or always over committing or has a velocity of 0 (doing a lot of stuff but not finishing stories to the end).
6. Technical Debt: No time to write unit tests or refactor code. This results in duplicate code, unreadable code, lack of code coverage and all add to technical debt. Technical debt slows team down. Things become harder. This also leads to inappropriate solutions like a big bang re-write or fixing the product instead of the process.
7. Teamwork: Fixed roles (no one helping anyone else), personal backlogs (results with attitude of at least I finished my stuff!), not helping each others, personal incentive models, implementing all stories in parallel, management interference (team not self managing).
8. Product backlog/product owner and customer: Product owner does not have time to maintain product backlog so team does not have one or it is not prioritized. Product owner does not know the system or does not have the authority and thus cannot make decisions. Having multiple product owners that do not agree with each other. Product owner becoming a bottleneck where no one can do something unless they talk to the Product owner 1st. Product owner not always available.
9. Mergophobia: Fear of merging code. Not integrating early and often, No branching policies, not taking responsibility (everybody ignoring team rules regarding code checkin),
10. Spring backlog or taskboard: Does not exist, too far from the team (not easily accessible), too complicated (many states to keep track off ) result in it not being used during daily scrum, not owned by the team, no burndown, not updated daily, warning signs ignored.
11. Worry about 1 – 10. Problems are normal. Don’t panic. Don’t despair. Tackle them gradually, prioritize and try to improve sprint after sprint.
This presentation is available on InfoQ at http://www.infoq.com/presentations/Fail-Scrum-Henrik-Kniberg
