Q&A with Mike Burrows about the book Kanban from the Inside

In the book Kanban from the Inside Mike Burrows describes the Kanban Method, explores various models that can be using with Kanban and provides a process for implementing Kanban in organizations.

You can download a sample of Kanban from the Inside which contains chapters of different parts of the book to get an impression.

Earlier this year InfoQ published a series of three articles from Mike: The Sustainability Agenda in Kanban, Kanban’s Service Orientation Agenda and the The Kanban Survivability Agenda.

With his book now out, InfoQ interviewed Mike about Kanban’s values, flow and classes of service, combining Kanban with Agile or Lean Startup and implementing Kanban in organizations.

InfoQ: Why did you write this book on Kanban? What can readers learn from reading this book?

Mike: First of all, it is four and a half years since David Anderson’s original Kanban book was published. It is standing the test of time really well, but as a community we have come a long way since its publication. There seemed to be room therefore for a definitive presentation of the Kanban Method as we now understand it. And of course there will always be room for new stories.

Secondly, I felt that we have reached a level of maturity and confidence that permits us to step back and see how Kanban relates to other bodies of knowledge, in particular Systems Thinking, Lean, Agile, and Theory of Constraints. There is so much for the serious practitioner to learn from them, and I sought to celebrate each of them individually (even though they share some fundamentals, I have little time for those that say that they’re all the same). It’s possible that I may frustrate a few readers by only scratching the surface in areas that are rightly dear to them, but I think that this is a risk worth taking in the cause of broadening knowledge.

My third and most powerful motivation is more personal. I found myself uniquely positioned to write book deeply grounded in values, the nine I described in the three InfoQ articles referred to in your introduction. When you are writing a book that no-one else is likely to write, motivation is not a problem!

InfoQ: The first part of the book covers the Kanban values. What makes these values important?

Mike: Far from being fluffy, fragile, or merely the tool of corporate spin doctors, values turn out to be surprisingly robust and practical. Whether we are aware of them or not, they help to explain what we actually do now, not just what we aspire to. At the same time, they describe the benefits we expect from doing things the way we do them.

In nine values—transparency, balance, collaboration, customer focus, flow, leadership, understanding, agreement, and respect—I can describe not only how the stated principles and practices of the Kanban Method work, but also the thinking behind features found in more mature implementations. This makes them a useful shorthand. When teams prioritize values (through the Kanban Values Exercise or Kanban Knowsy, perhaps), they are prioritizing changes in practice, presumably because they are eager to receive the corresponding benefits. And when these priorities have strong echoes elsewhere—for example in Agile with collaboration, in Lean with flow­, or in Systems Thinking with understanding—you know that you will not be short of outside inspiration from which to draw.

Conversely (and this is advice that applies not just to Kanban), if a value seems incompatible somehow with the prevailing culture, you can expect a harder time when trying to implement its corresponding practices. It isn’t necessarily wrong to try, but we generally advise against pushing change in ways likely to provoke unnecessary resistance when the momentum for change can be maintained in other directions. To use one of David’s favorite metaphors, why try to go through the rock when you can go around it? Here, going around the rock means either prioritizing other values initially or accepting that a different approach may be more contextually appropriate.

InfoQ: Balancing the interests of the stakeholders often isn't easy. How can kanban help to do this?

Mike: At its most straightforward, I have more than once found it necessary as a manager to make sure that the allocation of effort across our various customer groups is seen to be equitable. In my experience, doing this transparently and proactively helps to level the load across the course of the year. Once trust is earned, customers may become more willing to make sacrifice their selfish, short term interest for the sake of longer term or wider benefit.

With Kanban, different sources of demand can easily be visualized with dedicated swim lanes or colors. With explicit policies on minimum and maximum allocations, the system can be self-governing on a day-to-day basis; the additional management overhead of ensuring fair allocation over the medium term need not be burdensome.

Veto-holding internal stakeholders (various forms of internal governance, for example) can be trickier to manage, but recognizing and understanding their interests can be essential to achieving smooth flow. Often, the flow through these groups must be managed carefully; why not make them just as visible as we would for dependency on (say) a service provider?

And let’s not forget the people who work inside the system. I have a rule of thumb: if a change seems to benefit customers, the wider organization, and the team, it is probably a good improvement that is likely to stick. Playing one group against another is unlikely to be sustainable, so try harder, think again. Improvement is not a zero-sum game.

InfoQ: Your book talks about classes of service. Can you elaborate what they are and how Kanban uses them?

Mike: The postal service provides an excellent analogy here. As the sender, you choose between expensive overnight delivery or something cheaper and slower based on your understanding of the needs and expectations of the recipient. For the same payload, different recipients can have completely different needs; they may direct you to make an appropriate choice, or leave you to make that determination as best you can yourself.

Classes of service in Kanban are very similar. Even where the work is similar in terms of technical content, the customer’s sensitivity to delay may vary widely. We give names to common profiles of schedule risk—conventionally Standard, Expedited, Fixed Date, and Intangible, but “local” names may apply too—make sure that work items are easily distinguished visually according to their given class of service, and manage them through the system accordingly. Once again, explicit policies guide day-to-day decisions (hand-carrying items through the system should be necessary for exceptionally sensitive items only), and longer term feedback loops ensure that we have a good understanding of the delivery performance that is possible for each class of service. This in turn helps customers make informed decisions.

The more subtle message of classes of service is that we should embrace variety in the design of our systems. Not all work is alike!

InfoQ: I consider flow to be an important aspect of Kanban. Can you give examples how flow can look in software development projects? How do you know that things are flowing?

Mike: You’d be right! “Manage flow” is a long-established core practice, and flow is the obvious value to abstract from it.

When we see delay or unpredictability, or people overburdened or starved of work, we are seeing the symptoms of the lack of flow and some clues to its root causes. We are perhaps less willing to recognize symptoms and causes when they are the result of deliberate system design, but this is very common. Batching (release cycles, for example) can seem so convenient that we can be in denial to the delays that it causes. A management focus on utilization may seem to make sense, but very high levels of utilization correlate with extremely poor performance (not to mention significant discomfort at the human level).

In Kanban, flow looks as good as it feels. We see work moving swiftly across the board. Work does not wait long between active states; in those active states, the workload is well matched to the system’s capacity, and spends little time unattended to or blocked. At the right hand side of the board, we are rewarded by the feedback that matters most, new understanding of how the work just delivered is (or isn’t) meeting customer needs.

The Kanban Method describes a well-trodden path by which to achieve flow:

• Visualize work is in ways that amplify the experience both of flow and its lack
• Keep work-in-progress (WIP) in balance with system capacity through limits and other policy mechanisms, further heightening the experience of flow and accentuating its impediments
• Identify and address impediments to flow, thereby driving further reductions in WIP

There are some positive reinforcement loops at play here, encouraging visual representations, work-in-progress limits, work item sizes, and other policies and parameters to evolve hand-in-hand with improved flow. And with better flow comes better performance. It’s all good!

InfoQ: You explained in the book that Kanban and Agile are related. Can you give some examples on how to combine them?

Mike: The classic combination of Agile and Kanban is Scrumban, quite simply the application of the kind of approach I described above but in the specific context of a Scrum implementation. In the book I describe some common changes that Kanban can help to bring about here, including:

• Hand in hand with WIP reductions, work gets to whatever counts as “done” in less time
• Work gets managed more effectively through its later acceptance, deployment, and customer validation states
• Deployments can more easily be planned independently of sprints, accelerating a drive towards continuous delivery
• Different types of work and classes of service are accommodated more comfortably; attention is paid to the cost of delay of individual work items and to the mix of work overall

This list is by no means exhaustive, and it has to be said that the journey each team goes on will vary. To me, the more exciting examples end up “kanbanizing” a process whose scope is very much bigger than the internal activities of a sprint, and thereby help to inject more customer focus into it. Where the focus is merely on team productivity, the impact is likely to be rather less dramatic.

Another approach is to apply Kanban in a context that is not explicitly Agile, and to speed its evolution by deliberately introducing Agile practices along the way, the kanban systems serving to make their impact more visible. My first experiences with Kanban (and in particular the formative experience that illustrates Part I of my book) were along these lines, and by any reasonable definition the end results would be described as Agile. Kanban’s humane, start with what you do now approach to change can be very helpful whenever there is high uncertainty around an Agile adoption, or where “transformation fatigue” has already set in.

InfoQ: Also lean startup can be combined with kanban. One of the benefits from using lean startup that is the early feedback loop on customer needs. Can you elaborate on that?

Mike: I speak from the privileged position of someone who has worked with two of the UK government’s digital exemplar services (thank you Valtech UK for making this possible). Both of them demonstrate a strong commitment to genuine user research and a humble acceptance that many requirements represent nothing strong than hypotheses about how real customers (regular citizens, not just internal users and their project-based proxies) will behave. I love this!

On a more philosophical note, I observe in my book that XP succeeded in moving feedback loops “rightwards”, so that they ensure that systems behave as they currently claim they should, rather than keeping them anchored on some historical model. That’s liberating. Lean Startup is exciting to me because it continues that rightward trend, centering feedback loops on the interaction between system and customer. In Lean Startup, progress is driven by an ever-increasing understanding of that interaction, measurable through the hypotheses that get proved and disproved through disciplined experimentation.

As Eric Ries’s 2011 book ¹ describes, Kanban is readily applicable to the management of experiments in Lean Startup. Going in the other direction, my book documents my first-hand experience (pre-2011) of adding customer validation (the proof or otherwise of the hypothesis) as a final step to existing Kanban-based delivery systems, and for this to catalyze a profound shift in attitude towards feature development that extends upstream right through the whole process. Knowing that my experience has been repeated by others, I can say with some confidence that Kanban and Lean Startup are natural companions.

InfoQ: Part III of the book describes the Systems Thinking Approach to Introducing Kanban (STATIK). Can you explain what this is and how it can be used to implement kanban?

Mike: I coined “STATIK” this year in the hope that the Systems Thinking Approach to Introducing Kanban (David Anderson’s work, not mine) would get the recognition that I think it deserves. I’m delighted to report that its new name does indeed help to make the concept stick.

STATIK describes a repeatable process for creating appropriately contextualized kanban systems. It comprises six main steps:

1. Understand sources of dissatisfaction
2. Analyze demand and capability
3. Model the knowledge discovery process
4. Discover classes of service
5. Design kanban systems
6. Roll out

Steps 1-5 make up the bulk of the second day of our foundation-level Kanban training class. Step 6 is considered a more advanced topic, and it often comes with an additional step “Understand the purpose of the system”, either up-front as step 0 or incorporated into steps 2 or 6.

We allow for the possibility that steps 5 and 6 may involve the implementation of system changes beyond the minimum implied by the initial introduction of kanban systems. However, be in no doubt: steps 1 through 4 are all about the system as it currently is. Start with what you do now!

We have understood for some time (it gets mentioned in passing in my book) that STATIK is also useful in the context of existing implementations, especially when they are in need of some reinvigoration. I recently described “Reverse STATIK” ², which starts at step 5, and backtracks through steps 4 to 0 as far as is necessary to identify meaningful improvements. Changes are then worked through in the forward direction.

InfoQ: Can you give some advice for organizations that are interested in Kanban and are looking for ways to get benefits from it? What could they do to get started?

Mike: In terms of reading, my book ³] very clearly positions the Kanban Method as a management approach, and David’s ⁴ does a great job of demonstrating its organizational impact. Marcus Hammarberg and Joakim Sunden’s recent book Kanban in Action ⁵ contains some valuable team-level advice.

I have published two resources under Creative Commons licenses: the Kanban Values Exercise ⁶ is a thought-provoking way to introduce the values, principles, and practices of the Kanban Method, and Featureban ⁷ is a simulation game that illustrates the benefits of operating kanban systems. With Luke Hohmann we have developed Kanban Knowsy ⁸, an online game that explores team alignment. As a by-product of my book there is also a values-based assessment tool under development that is available on request and currently being tested in a few places.

Any significant implementation will benefit from the input of an experience trainer or coach; multiple providers globally are listed on the LKU website ⁹. I am an Accredited Kanban Trainer (KCP) and Kanban Coaching Professional (KCP) myself and although I’m less involved in the day-to-day running of these programs than I used to, I still have responsibility for the training curriculum.

For help and idea exchange there are a number of online forums, principally the kanbandev Yahoo group and a number of groups on LinkedIn. There are plenty of opportunities to meet people in person also, from Lean Coffees and evening meetups to conferences. Of the several the autumn conferences ¹⁰ I’ll be opening Lean Kanban UK (London, November 3^rd and 4^th) and will be speaking at Lean Kanban Central Europe (Hamburg, 11^th and 12^th) also.

References

¹ Eric Ries, The Lean Startup (Crown Business, 2011)

² Mike Burrows, Reinvigorating an existing Kanban implementation with STATIK 

³ Mike Burrows, Kanban from the Inside (Blue Hole Press, 2014)

⁴ David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010)

⁵ Marcus Hammarberg and Joakim Sunden, Kanban in Action (Manning Publications, 2014)

⁶ Mike Burrows, Kanban Values Exercise 

⁷ Mike Burrows, Featureban 

⁸ Kanban Knowsy 

⁹ Lean Kanban University 

¹⁰ Lean Kanban Conferences 

About the Book Author

Mike Burrows is UK Director and Principal Consultant at David J Anderson and Associates. In a career spanning the aerospace, banking, energy, and government sectors, Mike has been an IT director, global development manager, and software developer. He sits on the management board of Lean Kanban University (LKU), with whom he is an Accredited Kanban Trainer (AKT) and Kanban Coaching Professional (KCP). He speaks at Kanban-related events around the world, blogs at positiveincline.com and tweets as @asplake and @KanbanInside.