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
- Don't have it
- Don't obey it
- Outside the team's control
- Isn't known
- Isn't used
- Is misused
- Death marches (everyone commits to something most know will fail but do it anyway)
- 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
- 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
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
- 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
- Fixed roles
- Personal backlogs
- Not helping each other
- Personal incentive modes
- Implementing all the stories in parallel
- Management interference
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
- No "done" code branch
- No branch policies
- Not integrating early enough or not often enough
- Hiding behind branches
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)
- 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
http://blog.crisp.se/henrikkniberg/2008/02/01/1201823760000.html
1 comment:
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.
Post a Comment