Henrik Kniberg. He is known to many for his (really worth seeing) videos on the Spotify Engineering Culture or to the Effects of work in progress limits on daily work. To be honest, I didn't have him on my radar as an author before. I was proven wrong here and would like to share my top three learnings from Kniberg with you.
In our certified Kanban trainings we like to use the Microsoft XIT study to illustrate the effectiveness and design of a Kanban system.
The study is informative, recommendable and compact, but also quite densely written and requires a lot of cognitive resources.
The reward: you will understand a lot about Kanban systems and their introduction. Henrik Kniberg's book is a wonderful addition to this (from my subjective perspective). His book is written in lightweight English and focuses on suitability in practice.
What both texts have in common: Henrik Kniberg's book is also a case study. The practical relevance is omnipresent throughout the chapters and is accompanied by pictures of real backlogs.
So what is it all about?
The book describes a Swedish police project whose IT components were coordinated using a Kanban system. The actual state at the time, or the point of pain, is described in the book as follows:
"Suppose an officer catches a drunk driver. In the past, the officer would have had to capture all the information on paper, drive to the station, file a report, and then hand the case over to another investigator for further work. This would take a month or so." (Kniberg 2011, p.3)
The product objective is a system that enables the Swedish police to retrieve, edit and maintain all relevant information directly on site on a laptop. This means that all connected authorities and judicial authorities can also continue to work with it.
A large part of the book deals with the presentation of how the product goal was implemented with the help of a Kanban system and leads you as a reader past the most relevant points: What did the daily/weekly/monthly meeting structure look like? What did the Kanban system look like and how were their boards organized? How were tech stories and overarching bugs handled and resolved? How were releases planned and rolled out? Who were the stakeholders and how were they tested? How did continuous improvement work in the project? How were metrics and velocity used?
As you can see, these are pretty relevant questions that arise during a complex project.
What did I particularly like about the book?
Admittedly, I love practical reports and case studies. That's why I'm perhaps a bit biased (is there a German word for this? Feel free to write it in the comments :D). Above all, Henrik Kniberg writes honestly and unpretentiously. It is not a glossy, glossy report, but a practical book. The project team had the presence of mind to take lots of photos during their work, so that you as a reader can see real photos from everyday project life for almost all the points listed. You can also see the changes made in the Kanban system.
As an agile coach, I was able to take away 3 key points for my everyday life:
I am currently supporting a customer in setting up several Kanban systems, which are connected to each other at a higher flight level and need to be coordinated. The book showed me how much power and effect a structured upstream can have. In other words, how much added value a coordinated system can deliver if it is clear how the actual work for processing by individual teams enters the system.
Learnings from Kniberg:
In a complex Kanban system, it is not only the reduction of the WiP limits within the downstream that is relevant, but also the limitation of the work that is pulled into the system. This is where something that I already liked in the Microsoft XIT study comes into play: A rudimentary drawing of the workflow creates transparency and helps Agile coaches and, above all, working teams to understand the 'path of work'.
The second gold nugget for me as an agile coach: the book describes in detail how the teams were 'trained' to achieve a good balance between tech stories, bugs and features and what effect the introduced WiP limits have had on the teams. For me as a non-techy, this has opened up a lot. Henrik Kniberg has repeatedly printed dialogs between two or more people in his book. This allowed me to understand the process and the thoughts of the people involved in the project.
earnings from Kniberg:
Create a balance in the processing of features, tech stories and bugs. This is about finding the right balance. As an agile coach, you can also help significantly with this.
"Tech Stories are things that need to be done but that are uninteresting to the costumer, such as upgrading database, cleaning out unused code, refactoring a messy design, or catching up on test automation" (Kniberg 2011, p.39)
In the project described above, the team proceeded as follows: These three categories form the different types of work. All are subject to a limit: Next Ten Features, Next Five Tech Stories, Next Five Bugs. These are committed and are pulled from prioritized backlogs as required. The team is involved in prioritizing the following entries. This creates a pull system that offers comparatively 'few' surprises and remains stable for a fixed interval.
The book is divided into two parts: the 'project report' comprises 100 pages and on another 50 pages individual techniques are explained and deepened (How to reduce the Test Automation Backlog, Sizing the Backlog with Planning Poker, How to use Cause-Effect-Diagrams). I was also able to take something nice away from this part of the book: It contains a detailed description of how you as a coach can create cause-effect diagrams and what they have done in the practice of the project. You can also recognize reinforcing loops in these diagrams.
Learnings from Kniberg: I already knew cause-effect diagrams before the book.
You will need a large sheet of paper (A3 plus) and a team with an impediment (often found in practice :).
Step 1: Identify the problem together ("anything thats bothering you" Kniberg 2011, p.134) and describe it. What bothers you, what do you observe?
Step 2: Write the consequences for the organization/your team on the map. What is the 'visible damage' of the problem (cf. ibid.).
Step 3: Write the hypothetical origins under the card. What is your hypothesis about the cause of the problem? What else? (The 5 Whys technique from the Liberating Structures (link) also helps here)
Step 4: Look at the result together and search for relationship patterns and causal connections. What is connected? What reinforces each other?
Step 5: Repeat this process a few iterations as a team. Have the courage to simplify or 'clean out' things. What is still blocking our view? Where do we need clarity in the diagram?
Step 6: Select a cause and define experiments that can help you solve the problem. What can help us in the long term? How and when do we monitor the experiments and assess their effectiveness?
The result may look something like this:
Learnings from Kniberg as an Agile Coach:
Talking about complex impediments is exhausting. Visual support through a cause-effect diagram (or another form of representation) helps you to find a solution. It creates a visual communication framework, so to speak, and helps to create a shared focus within the complexity. What else do these diagrams do? When you are surrounded by complex impediments as a team, it feels 'modest' to say the least. At best, the shared activity of co-creative design transfers to the solution-finding process and helps to overcome team-subjective passivity. Ok, that might be a bit too 'thick', but I just had to think about it 🙂
My summary of the Learnings from Kniberg
A great book for anyone working in and on Kanban systems. In his publication, Henrik Kniberg combines the essentials of Kanban with illustrative examples from a real project. The nice thing for me is that the product/service of the project is understandable and provides the framework for understanding the effect of Kanban as a reader. In short: If you want to get a lot of knowledge about Kanban in larger projects for a small price, this book is the best choice.
Do you want more Kanban and people for exchange, and a common way of thinking about how this could work in your organization? Then take a look at our offers in the Kanban over!
Sources:
Kniberg, Henrik (2011): Lean from the Trenches. Managing Large-Scale Projects with Kanban. The Pragmatic Programmers. Texas (USA).
Anderson, David; Dumitriu, Dragos (2005): From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft's IT Department. http://images.itrevolution.com/images/kanbans/From_Worst_to_Best_in_9_Months_Final_1_3-aw.pdf (last retrieval: 11.05.22)
Write a comment