Q&A on the Book Practical Kanban

The book Practical Kanban provides solutions for typical problems that continually occur within Kanban implementations. It explains how you can create a Kanban system for the entire value creation chain to coordinate the work of teams.

InfoQ readers can download an extract of the book Practical Kanban. They can also use the Leanpub coupon to download the full book for $9 instead of $24. This coupon is valid until November 26, 2017.

InfoQ interviewed Klaus Leopold about the benefits that Kanban can give, how to use Kanban boards effectively, what can be done to increase the success of retrospectives, how to coordinate the work of multiple teams in large projects or for developing complex products, how to use Kanban metrics, how we can use Cost of Delay to deliver more value to customers, and how to use Kanban flight levels.

InfoQ: What made you decide to write this book?

Klaus Leopold: I am a Kanban practitioner. I was not completely happy doing pure research at the university despite the work being very satisfying, because the results of the research were never implemented in the “real world”. I often thought that I had great solutions without a corresponding problem. Once I started working as a Kanban trainer and consultant, this was no longer an issue. Since 2008, when I started my Kanban career, I have worked on several hundred Kanban Systems. After the implementation of a Kanban System, I often return to the company some time later, analyze the system and hold improvement workshops. Experience has shown me there are typical problems that continually occur within Kanban implementations. When I understood the problems, I was able to offer better solutions. I began to catalog the solutions for these problems, and eventually had a library of solutions for all possible issues. This book brings structure to my experience and solutions and makes them available for everyone to use.

InfoQ: For whom is this book intended?

Leopold: This book is definitely for practitioners: people who have started with Kanban and who want to find answers to the following questions:

• Are we using Kanban properly?
• How can we improve our Kanban?
• How can we scale our Kanban?
• How can our work become more predictable?
• What should we work on next?

InfoQ: What kind of goals does Kanban aim to support; which benefits can you get from applying Kanban?

Leopold: That is a really big question that opens up a lot of doors. Rather than endlessly rambling on, I will give a very short answer: the goal of Kanban is to improve an existing work system in an incremental and evolving manner. Probably the two most obvious advantages you have when you implement Kanban are: (1) A reduction of the cycle time for work and with it a better time to market, and (2) an increase in predictability about when work will be completed. A not so obvious but more important result is that the employees understand the point of working effectively. This enables a permanent, autonomous development of the work system, as well as continuous improvement.

InfoQ: What tips do you have for using kanban boards effectively?

Leopold: I believe the most important tip I can give is to build the Kanban system so that it completely focuses on generating value. You do not want to just optimize some organizational structures such as teams or departments, rather the creation of value for the customer should be optimized. In concrete terms this means do not implement Kanban for your team or department. Think outside the box! How and where are you included in a value creation chain e.g. products, projects, etc.? Identify the most important stakeholders in the value chain and find out together what you want to improve in terms of delivering value for your customer. And then build a Kanban system which addresses these points. Most likely you will find out that you need other teams on board because I have never seen a company with more than 50 people where one team alone can deliver 100% of the customer value.

InfoQ: You mentioned that in many cases retrospective meetings are unsuccessful. Why is this, and what can be done to increase success?

Leopold: I often notice that retrospectives are either completely ignored or they are used exclusively as a team event. The retrospective could be any meeting in which a group of people in a safe environment can solely think about themselves. Regardless, I still believe the retrospective is not a team event! I'm in favor of thinking outside the box in the retrospective and regularly including anyone who is connected to your work—whether an external stakeholder or other parallel services or teams where dependencies exist. Precisely in this review, it is useful to take a broader perspective as it offers the chance to learn with and from one another.

In "Kanban Change Leadership", Sigi Kaltenecker and I described in great detail how you can and should include stakeholders at the beginning of a Kanban implementation so it is successful, versus being just a flash in the pan. Through this cooperation, you know which problems need to be solved. However, this is not a one-time deal! For me, never again asking the stakeholder how the solution is working and never again including them in the improvement cycle is a strange way of thinking. A team should want to hear about what can be done better for their stakeholder. In this case, having frequent discussions directly with the respective person is hands-down better than speculating. In many companies that are newly agile, I have observed retrospectives at the team level conducted by the book, but the knowledge gained in the individual teams is never linked or, at the very least, connected.

The team optimization way of thinking is often still strongly anchored within the company. A project leader at an automobile company described their situation. "Ah, now I understand. We build a lot of Ferraris, but we don't have a road." Thanks to this insight, we found a simple solution for them. In addition to the team retrospectives (the Ferraris), the team representatives met for an overall retrospective (we called it the Ferrari convention) to improve interaction and build a better product together, versus optimizing individual pieces. Gradually, a road on which the company could move forward together was created. What you should take away from this is: do not limit retrospectives to your immediate Kanban system!

InfoQ: How can you use Kanban to coordinate the work of multiple teams in large projects or for developing complex products?

Leopold: One of the biggest misunderstandings about Kanban is that Kanban would be a team method. That isn't the case! It is, generally speaking, wrong to think that you must improve the teams within an organization in order to develop better products. If a company has more than 50 employees, it doesn't matter how it is set up, there will always be dependencies between teams.

For instance, there will be several teams that work on one product, or there will be specialists like legal counsel, marketing experts or user experience experts that are simply too few in number to be a part of every team. In a world of dependencies, optimizing individual pieces leads inevitably to sub-optimization. This always reminds me of a keyboard. The individual keys on the keyboard have dependencies. When I want to type the word "tree", for example, I must tip the keys in the order T-R-E-E. Let's assume a company is a keyboard, where the individual keys represent the various teams. When I optimize an individual team, I can type really fast on that one key, but the entire document will not be completed more quickly because, when writing the document, it is more important to type the right key at the right time. The same thing happens in companies when teams are optimized.

The individual teams might deliver their work more quickly, but the end product will not be finished more quickly. In a world of dependencies, it is more important to be sure that the right team is hitting the right key at the right time. This is exactly the area where you can implement Kanban: effective Kanban systems span across teams! The creation of value is optimized by creating a system for the entire value creation chain. When creating value, there will be teams that must complete individual pieces of work. The first step, however, is to make sure you optimize the right teams working on the right work at the right time. Afterwards, as a second step, you can optimize the individual teams. If you reverse the order, however, you will sub-optimize the entire work system.

InfoQ: What Kanban metrics do you suggest, and how can they be used?

Leopold: The nice thing about flow-based systems like Kanban is that you only need a relatively small amount of data in order to get a lot of information. In many cases, it's enough to categorize our work (for example, Feature or Bug, etc.) and make a timestamp at the start of the work and the completion of the work. An important measurement, in my opinion, is the cycle time, which can be calculated (somewhat simplified) by subtracting the work completion time from the work start time. When you carry over these values on a scatter plot, you can already have good predictions about the amount of time it takes to complete individual pieces of work.

Another important metric is the throughput, for which you only need the completion date of a piece of work. The throughput gives you information about how much work in a given time period will be completed, for example: features per week, stories per sprint, projects per month, etc. With the throughput you can make simple forecasts about when, for instance, projects will be completed or how much work can be delivered in a given timeframe. Metrics also have another very important area of application: they form a feedback loop, and with it give you information about your work system. We know that we need changes in order to become better, but not every change must be an improvement. For example, if you want to improve time to market, it would be a good thing to measure what your current time to market is. When you then make changes, you can see with the measurement whether or not you are on the right path. If the time to market improves, that's good. If not, we should do something different. Thus, a perfect feedback loop.

InfoQ: How can we use Cost of Delay to deliver more value to customers?

Leopold: The classical prioritization of work has one disadvantage: It rarely deals with economically accountable criteria. Through outside pressure, or through political pressure within the company, there is constant re-prioritization. The resulting bottlenecks are often countered by increasing resources, but doing this increases the complexity even more. The result: too much work gets started and eventually, as a result, no work is finished on time. With economic assessments, balance between demand and resources can be achieved and an organized inflow to the work system established. Prioritization based on Cost of Delay results in an economically rational order of processing. Cost of Delay is always based on value-generating, deliverable units that give the customer tangible benefits. It is a function of the value generated by a piece of work and its urgency. Sequences that are economically based, together with the WIP limits of a Kanban system, help a company to quickly get working on generating value. Determining Cost of Delay requires that everyone involved put personal interests aside, and focus instead on what's best for the customers and the company.

InfoQ: What are the Kanban flight levels and how can they be used?

Leopold: The Flight Level model poses one main question: which organization levels offer which leverage for improvement? Although the flight levels came about through working with Kanban, it is still a general-purpose model for organizational development. When working with my customers, for example, often the focus is to implement measures at Flight Level 2 and 3 to improve coordination and strategic direction, while the team level, or operational level, works with Scrum. As such, it isn’t important which method is used at the individual levels, but rather how the communication and coordination between the levels will be organized. If you can make improvements here, the entire creation of value will begin to be optimized—and that is ultimately our goal.

I did not randomly choose the label “flight levels”. Flight level relates to flight altitude and so it should also be understood in this context: the higher you fly, the more of an overview you have with fewer details. The lower you fly, you can see more details but no longer the entire landscape. The Flight Level model is an instrument of communication that reveals the effect of specific improvement steps at different levels, and for finding the most useful starting point within the organization to begin with improvements.

There are three flight levels:

• Flight Level 1—Operational Level This flight level belongs to the team. A team that coordinates their work.
• Flight Level 2—Coordination If a company has more than 50 employees, regardless of how the company is set up, there will always be dependencies between teams. Exactly here is where Flight Level 2 comes into play—it focuses on generating value and makes sure that the right team is working on the right stuff at the right time.
• Flight Level 3—Strategic Portfolio Management At Flight Level 3, the work in the entire organization is made visible, on which the strategy can be aligned and managed.

About the Book Author

Klaus Leopold is computer scientist and Kanban pioneer with many years of experience in helping organizations from different industries on their improvement journey. He is author of the book “Practical Kanban” and co-author of the book "Kanban Change Leadership”. He publishes his current thoughts on his blog and you can follow him on Twitter at @klausleopold.