I was introduced to “Lean Thinking” by my friend Jane, who’s been involved in applying the “Toyota Production System” principles in a major public hospital setting (not the first place you’d think of finding something that was created by a car manufacturer). After learning about Lean and considering that it seemed to have some overlap with the Agile software development processes that have become more popular in the last 10 years, I then discovered the work of Tom and Mary Poppendieck who had published Lean Software Development: An Agile Toolkit, the first of 3 books on the subject.
Reading their work is still on my ‘to do’ list, but it was while I was reviewing their recommended reading list that I decided to purchase Kniberg’s book.
Lean from the Trenchesis an fascinating case study in applying Lean and Kanban to the development of a software application for the Swedish Police. Kniberg worked as a coach part-time on the project for about 7 months before publishing this book. As I understand it, this was a ‘greenfield’ application (which might explain how they could do the 30 bug limit).
I found this book very interesting. In particular, the following stood out for me:
- the regular Process Improvement Workshops – initially a weekly cross-team meeting to look at implementing change quickly
- the way they used Kanban and the changes made over time to the board to make it work better.
- Identifying recurrent bugs with root-cause analysis
- Having limits for work in progress (which doesn’t include bugs)
- Not using story points (though features are estimated with Small/Medium/Large T-shirt sizes)
- The “Next 10 features”
- Balancing features and ‘tech stories’ (technical debt)
- Limit list of bugs to be fixed at 30!
- Testers working in development teams
- Many bugs get fixed immediately if possible
- Importance of visualisation and communication
I’m most familiar with Scrum, so there was a reasonable amount of familiarity with some of their practises. The focus on the Kanban board was interesting. I do like the fact that it is so visible. Kniberg feels having a physical board is important, though I wonder how that would work if he had to manage distributed teams.
In summary, a great read with some thought-provoking ideas.