Last year I sent out a tweet that really took off! It was bit of a joke, mixed with seriousness and a tribute. Here’s how it looked:
To explain, I’m not a big fan of Tolkien (can I say that out loud? 🙂 ) , so I’m totally honest with the statement. It was also a homage to Henrik Kniberg who really started my agile journey. At the company I was working on at the time, we got an introduction to Scrum by one of Henrik’s colleagues from Crisp, and then we set sail. I don’t remember now if I read ”Scrum and XP from the trenches” (first edition that is) before or after the introduction, but this book really started my agile journey; that it was possible to build software without using the waterfall model! Scrum was easily accessible and something we could start to use almost right away.
Scrum and XP from the trenches, 2nd edition (Director’s cut)
A few weeks ago I learnt that the book just had been published in a 2nd edition. It’s the same book as when it was released 2007, but annotated considering the eight more years of Henrik Kniberg’s experience (working together with for example Jeff Sutherland, Mary and Tom Poppendieck, Jerry Weinberg, Alistair Cockburn, Kent Beck, Ron Jeffries and Jeff Patton).
I let Henrik explain the new version by quoting from the preface of the 2nd edition:
”So that’s what the second edition is – an annotated version of the original book. Like a director’s cut. Think of it as me standing behind your shoulder as you read the book, commenting on stuff, cheering you on, with the occasional laugh and groan.”
Since I have previously read the book, and also seen that it has have been downloaded more than 250.000 times, I will not focus on the content from the first edition. Instead I will comment on the annotations entered in the 2nd edition. Basically I wanted answers to the following questions:
- What has Henrik learnt since 2007
- How does his experiences compare to mine
I’ve selected seven sections from the book and commented on them using the format of: then, now & my thoughts. Here we go.
1. ”The product backlog is the heart of Scrum”
Then: The product backlog was a file in Excel that (almost) only one person cared about, the product owner.
Now: A good product starts with customer needs and thoughts how to fulfill those needs. The backlog then is a (cloud) shared document that all in the team are involved in, and take responsibility for.
My thoughts: The product backlog is really ”the map forward” and all stakeholders needs to be able to access it easily. Therefore we use the priority pyramid to visualize our backlog.
2. ”Sprint planning is a critical meeting, probably the most important event in Scrum”
Then: The sprint planning meeting kicks off the following sprint and a badly performed sprint planning leads to a poorly executed sprint, according to the saying: ”shit in, shit out”.
Now: Still an important meeting, but not the most important in Scrum.
My thoughts: More important are to conduct retrospectives regularly to be able to continuously improve the process, this is also called kaizen. We have kaizen-meetings for all the teams 30 minutes every Friday to discuss the past week, what is working good, what needs to be improved etc. We keep track of our improvements using a Kaizen-board.
3. Focus factor
Then: ”Available man days” multiplied by the ”focus factor” was used to calculate the team’s ”estimated velocity” for the sprint.
Now: As Henrik writes, he wants to ”rip out these pages” from the book. This way of calculating is not used anymore! Instead, use data from past sprints. For example select the same amount of stories that was completed in the last sprint as a target for the upcoming.
My thoughts: This is painful reading. All the sprint planning meetings I have been in, that spent time on estimating and then trying to fit the scope (that we wanted to do) into the length of the sprint. We fooled ourself with manipulating the focus factor (this sprint ”we will reach” a focus factor of 80%, despite we have never done it earlier…), or ”can we expand just this sprint to six weeks?” to fit everything in. Luckily we don’t do this anymore 🙂
4. Definition of done
Then: The product owner and the team agreed on a clear definition of done for each story.
Now: A concrete check list is used instead.
My thoughts: We have criterions for each of the columns in our team boards. Those have to be fulfilled before the task can move on to the next column/step in the process.
Then: The name of the person working on the task was written on the sticky.
Now: Avatars are being used instead. Each team member pick something that represents them, print it and put it on magnets.
My thoughts: We used to write names on the stickies. Since several persons usually works with one task during the flow through the process the stickies got messy towards the end. Now we use magnets with pictures or the initials of the team members printed on them.
6. Burn-down chart
Then: Scrum was originally done for teams doing one-month sprints and using Excel to track the tasks. The burn-down chart (also produced in Excel) was vital to see the progress of the sprint.
Now: Since most teams do shorter sprints (2-3 weeks) the board itself (with stickies in different columns) is enough for other stakeholders to understand ”where the team are”. Burn-down charts can be skipped.
My thoughts: We never got burn-down charts to work properly, and we struggled a lot with it. You can read more about that here.
7. Bad approach: ”Focus on building new stuff”
Then: The bad approach was to focus on building new stuff rather than getting ”old” (= already completed stuff) into production.
Now: Still the same problem. Henrik says that solving this problem (by limiting the number of features in process at the same time) he have seen companies become seven times faster.
My thoughts: The saying ”Stop starting, start finishing” doesn’t seem to take effect. Is it human nature that it is ”more fun” to start new stuff rather than completing ”old” ongoing work? I don’t know, all I can do is to agree that this is still true.
With the new annotations in this second edition I can really recommend you to read this book! Best of all? You can make your own judgement by downloading the book for free and read it yourself! I let Henrik end with another quote that sums up his agile experiences:
”I’ve found some strong common denominators though: work in cross-functional teams, visualize things, deliver often, involve real users, automate your tests and release process, and experiment a lot. The basic agile principles, really.”
All the best,
Tomas from TheAgileist