Wednesday, August 6, 2008

10 Ways to Screw Up with/despite Scrum and XP

This talk was given by Henrik Kniberg from a Swedish consulting company called Crisp.

I had the change to get a copy of his paper called "Scrum and XP from the trenches" which can be downloaded in PDF format at the following link:

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

I will summarize the content of this presentation in point form. The goal of Henrik was to expose different failure modes which scrum and XP teams can fall into. Sometimes identifying the problem is enough to get a discussion going so people address it.

1. Believing the Hype
  • Believing in magic
  • Not willing to change
  • Throwing out stuff that works
  • Focusing to much on process perfection
  • Trying to get it right from the start
  • Blaming the messenger
  • Tools focus
  • Focusing on the wrong issues
2. The Definition of Done
  • Don't have it
  • Don't obey it
  • Outside the team's control
3. Velocity
  • Isn't known
  • Isn't used
  • Is misused
  • Death marches (everyone commits to something most know will fail but do it anyway)
4. Retrospectives
  • Doesn't happen
  • Doesn't result in concrete improvement proposals
  • Changes not executed
  • Unwanted people at the meeting
  • Team members not participating or the product owner is not participating
  • The team is penalized for bad changes
5. Team Commitment
  • Team is pressured
  • Team is not co-located
  • Team doesn't track and learn
  • Under commitment
  • Over commitment
  • Velocity = 0 (No fully finished user stories delivered at the end of a sprint or cycle)
  • No slack time
6. Technical Debt

Quote: "We don't have time to write unit tests of refactor code". Technical debt can be compared to accumulating interest on a loan. You let it go and forget it for awhile but you'll eventually have to pay up! Examples of technical debt are: duplicate code, lack of test coverage and unreadable code. Failure modes for this are:
  • Letting it pile up
  • Ignoring it
  • Fixing the product but not the process
  • Big bang rewrites
One way of dealing with technical debt is to:
  • Slow down, stop accumulating debt and adopt a sustainable pace
  • Slow down even more and start repaying debt; this will eventually increase your pace over time
7. Teamwork
  • Fixed roles
  • Personal backlogs
  • Not helping each other
  • Personal incentive modes
  • Implementing all the stories in parallel
  • Management interference
It is important to talk to the team in order to focus their efforts.

8. Product Backlog, Product Owner and Customer
  • Product backlog (PBL) does not exist
  • PBL not visible
  • Big or never ending user stories
  • Product owner (PO) without proper domain knowledge
  • Multiple conflicting POs
  • PBL not maintained by PO
  • PO surprised at sprint demos
  • PO is the bottleneck
  • PO is not prioritizing
9. Mergophobia (The Fear of Merging)
  • No "done" code branch
  • No branch policies
  • Not integrating early enough or not often enough
  • Hiding behind branches
Quote: "You don't get and agile organization without agile engineering practices"

10. Sprint Backlog/Taskboard
  • Does not exist
  • Too far from team
  • Too complicated
  • Not used during daily meetings
  • Not owned by team
  • No burndown chart
  • Not updated daily
  • Warning signs are ignored (such as burndown chart burning up)
11. Worrying to Much About the Other Ten (Bonus)
  • Problems are normal
  • Never stop looking for problems
  • Don't panic, don't despair
  • Visible problem = killable problem (this is an opportunity for improvement)
  • Prioritize and fix problems one by one
  • Look back once in awhile and pat yourself on the back
You can find some useful scrum checklist at the following link:

http://blog.crisp.se/henrikkniberg/2008/02/01/1201823760000.html

1 comment:

Anonymous said...

Very useful info, J, thanks for sharing all of this.
IMHO, retrospectives are often not given the importance they should be, especially if one sprint has gone wrong and the team is already behind schedule as far as the product backlog is concerned. The tendency then is to quickly jump into the next sprint, without taking the time out to really retrospect and fix problems, before they are repeated all over again.