The book Real World Kanban by Mattias Skarin provides four case studies where Kanban is used to visualize, provide insight and improve product development.
InfoQ readers can download a sample of the book Real World Kanban.
InfoQ interviewed Mattias Skarin about his view on the essence of kanban and lean, why flexibility in organizations is needed, using data on product usage to do continuous improvement, how visualization can help teams to understand problems, making time available to do improvements, how retrospectives can be used within Kanban for continuous improvement and advice on how to get started with kanban.
InfoQ: What made you decide to write a book with case studies on Kanban?
Skarin: A good way to learn is through examples. So I wanted to show people what happens in real companies when you apply Kanban. Things don’t always play out as in theory.
Secondly, I felt it important to share examples from traditional companies and how they can improve by a factor of 2 or more. Very few companies start up as the next Spotify. They have legacy - roles, functions, processes, tech debt and a perception of how the world works which indeed has taken them to the position they are in today. We don’t usually talk much about how these companies make improvements as they adapt and evolve, but there is so much to learn from them.
InfoQ: Can you briefly describe what you consider to be the essence of Kanban and Lean?
Skarin: To continuously improve end-to-end flow (improving the whole is more important than improving parts). Then there’s also the people aspect, building organizations that use and leverage human strengths (creativity, ingenuity, teamwork, making a difference) - rather than building systems that make it impossible for people to do work with high quality and to grow. Leadership (lead by example), responsibility and building a culture of experimentation, are three important keys to make this happen.
InfoQ: Can you explain why no defects should be passed on to the next stage when developing software?
Skarin: There are two aspects to this. The economic aspect - fixing a problem becomes exponentially more costly the later we wait. But just as important is building a culture of responsibility and quality. We simply don’t pass on bad stuff to others. That’s the other aspect.
InfoQ: In the book you explained why flexibility in organizations is needed to seize market opportunities. Can you give some examples?
Skarin: We might need flexibility to explore a different business model, to use a different business process in order to innovate. But also when building the product, flexibility to change the architecture and allow teams to explore different technology options. Finally, flexibility to train new people fast. In short, flexibility is more important than conformance.
InfoQ: One of the cases in the book talks about doing continuous improvement based on data on the usage of the products that are being developed. Can you explain how the team did this?
Skarin: We had a very low-tech solution :) When the new product was launched, the marketing department interviewed the users about their experience. This information was then relayed back to the product development in two different forums. First, we had a monthly company demo where marketing would report back the most important findings from previous launches. Secondly, the owner of that product idea would join at the standup meeting at the Enterprise Kanban board and share experiences there. We also visually kept track of successful launches (customer happy and using it) and unsuccessful launches. If the customer weren’t happy we would do a root cause analysis together to find out what to change.
InfoQ: Can you give an example that shows how visualization has helped a team to understand their problems, and solve them?
Skarin: Just seeing the combined work the full team had going on was often a surprise. This caused multiple teams to focus and prioritize, as a team, rather than as individuals. Another case was visualizing platform improvements that had been going on for months. By just visualizing what really needed to be done we could focus and deliver those within a week or two.
Another aspect is that visualization can also helped clarify what wasn’t a problem. In one case, we choose to visualize how teams focused their time. This helped us debunk the myth that individual parties weren’t suboptimizing the overall product idea flow by going straight to individual teams.
InfoQ: Many teams are overloaded with work. Do you have suggestions how such teams can make time available to do improvements?
Skarin: Yes, there are a few things you can do.
First, visualize the work you are doing. Just seeing it will give you insights.Second, learn to apply WIP limits. If this is hard, use physical tokens. This makes it easier for team members under stress to realize that they are breaking a team commitment.
Third, prioritize the inflow. If your upstream functions don’t take on their responsibility in doing this, then do it for them (and communicate to them that they will need to accept the consequences) .
Fourth: When overloaded, you have strong arguments for deferring the following types of work.
- Planned work far ahead in the future (it’s better to realize these types of work “just in time” than “a long time in advance”. One thing is certain: The plan will change!).
- Deadlines without clear explanation of consequence. There are real deadlines with clear economic consequences (“we miss our market window”) and planned deadlines (“we promised“).
- Low quality inflow. Step by step, return low quality work hitting your backlog from upstream teams and return it to the team that produced it (instead of fixing it for them).
- Information type questions “where is my.. “ .. “how do I..”. Decrease the inflow of these by creating a Wiki with simple questions, training up surrounding functions on answering basic questions themselves and get a Kanban board in place so status questions can be answered by the board instead of through phone calls to people.
None of these choices are easy, but would you rather continue thrashing? We may not be able to fix the entire organization in one go, but we can decide to get a healthy work environment for people in our unit.
InfoQ: Can you share some examples of how retrospectives can be used within Kanban for continuous improvement?
Skarin: A good retrospecting starts with walking the board. What happened, what got blocked, what solved those blocking events, did we produce work of quality? Then look at the charts “what happened with lead time? What percentage of work is rework ? (And where does it come from?) Finally, we look at the experiences from team members. A crucial component is participation by management reporting back on what they have done to address bottlenecks and solve problems across organizational borders.
The key to making retrospectives work is making them flow focused, data driven and getting management participation in cross-team problem solving.
InfoQ: If organizations are interested in deploying Kanban, can you give them advice on how to get started?
Skarin: A good way to get started is by reading a book. Another way is by observing other kanban teams. Then take a course to learn the basic principles and how they drive value (help you continuously improve) and finally, get your feet wet and give it a try! We learn through experimenting. It can be helpful to have an experienced coach to hold your hand from time to time. An experienced coach can help by bringing in fresh perspectives.
About the Book Author
"Sun Tzu once said the ultimate responsibility of generalship is maneuver into a position of success.How do we do this in software? This is my quest."
Mattias Skarin (a Crisp guy) coaches and trains management teams and value streams how to build and sustain a competitive edge in a global, fast moving environment. Mattias is the author of the book ”Real world kanban” and co-author of ”Kanban and Scrum, making the most of both”. See also Mattias' blog.
