Henrik Kniberg, author of Scrum and Xp from the Trenches, talked today at Agile 2008 about the most common ways for teams to fail despite applying agile practices and tools. His presentation was organised as a talk about common problems and symptoms of those problems, with audience voting on what hurts them the most. From my perspective, it was a very effective way to see problems of other teams and definitely raised the awareness of some of these issues.
The audience voted by raising coloured cards. A green card signaled that a particular issue was not really hurting the voter, a yellow card signaled that it hurts a bit and a red card meant that the issue was a serious problem.
Here are the things that Kniberg talked about:
- Believing the hype (mostly yellow cards)
- belief in magic — “all the problems will magically go away when we install XP 1.0”
- not willing to change — “trying to chop the tree with a chainsaw”
- throwing out stuff that works
- focusing too much on process perfection
- trying to get it all right from start
- blaming the messenger — scrum flushes out problems in the open
- tool focus —”let's buy the biggest most expensive XP tool”
- focusing on the wrong issues (should we use postits or index cards)
- Definition of done (mostly yellow and red cards)
- not having one
- not obeyng it
- it's outside the teams control (in production, but team has no access to it)
- Velocity issues (mixed – yellow, green and red)
- it's not known
- it's not used
- is misused (connected to salary)
- death marches
- cheating
- yo-yo velocity — bugs leaking into other iterations
- Retrospective problems (mixed – yellow, green and red)
- doesn't happen
- doesn't result in concrete improvements
- changes not executed and evaluated
- unwanted people in the meeting – team not open
- team members or product owner not participating
- team is penalised for bad changes
- Team commitment issues (more red than anything else, but mostly yellow)
- team is pressured – deadlines, death marches, aggressive managers
- team is not sitting together
- team does not track and learn
- always under-committing
- always over-committing
- velocity=0 —nothing actually delivered to the end
- no slack
- Technical debt (mostly red)
- letting it pile up
- ignoring it
- fixing the product but not the process
- big bang rewrites
- Teamwork issues (yellow-red)
- fixed roles — “I don't touch your stuff ever”
- personal backlogs
- people not helping each other
- personal incentive models
- implementing all stories in parallel
- management interference
- Product backlog and product owner/customer issues (mostly red cards)
- not having a backlog
- having backlog but not visible
- big or never-ending stories
- product owner does not have power or domain knowledge
- multiple, conflicting product owners
- product backlog not being maintained
- product owner surprised at sprint demo
- product owner is a bottleneck
- product owner not prioritising
- Mergofobia — merging is a pain and therefore we do it as seldom as possible (mixed colours)
- no “done” branch
- no branch policies — purpose of each branch not clearly defined
- not integrating early and often
- not taking responsibility
- hiding behind branches — “whenever we have a problem, we add a new branch”
- Sprint backlog/taskboard (relatively mixed, mostly yellow)
- does not exist
- too far from the team
- too complicated — "too many columns"
- not used during daily scrum
- not owned by he team — tool or way of maintenance imposed from above
- no burndowns
- not updated daily
- warning signes ignored
From the votes, it looks like technical debt and product backlog and product owner/customer issues are the biggest problems for most teams
An interesting thing happened at the start of the talk, when Kniberg asked the audience to vote on “this conference is too big”, with most people raising red cards. From what I can work out, at any time there are at least 30 sessions running concurrently and it is often a challenge to select a single session to attend.
