ENTERPRISE SOFTWARE DEVELOPMENT SERIES JESPER BOEG Biography: Jesper Boeg PRIMING KANBAN Jesper has worked as an Agile and Lean coach A 10 step guide to optimizing flow in your software delivery system since early 2006, and he is now VP of the depart- ment for ”Agile Excellence” at Trifork. He has a Master’s degree from Aalborg University in the area of Information Systems and wrote his thesis on how to successfully manage distributed soft- ware teams. Jesper helps teams and organizations adopt Agile and Lean principles, with a strong focus on un- derstanding “why”. He has a reputation for being honest and straightforward, with a firm belief that change management is much more about people than process. Jesper believes that trust is best established through an unrelenting focus on transparency in the entire organization. He has a strong passion for Lean Product Development and continuously emphasises that one must look at the entire soft- ware delivery system in order to guide success. Context Based Strategically Aligned Agility are keywords in Jesper’s work. It is his experience that in order to create lasting change, organizations cannot rely on Best Practice rule sets, but rather must put effort into understanding “why” as well as aligning Agile principles with the overall busi- ness strategy. Otherwise, they will quickly revert to former practices when faced with difficulty and will restrict themselves from great improvement opportunities. Jesper regularly speaks at Agile and Lean confer- ences. He is a member of the GOTO Aarhus Pro- gram Advisory Board and has served as a track- host on numerous GOTO and QCon conferences. 2 Priming Kanban Priming Kanban 3 Thanks to everybody that helped review this mini-book. The readability and the content have been greatly im- proved as a result of your comments. I would like to give a special thanks to Yuval Yeret, Karl Scotland and James Sutton for your insightful comments as well as taking the time to review the book in such detail. Written by Jesper Boeg Foreword by James Sutton Designed by Cecilie Marie Skov Graphics by Cecilie Marie Skov and Jesper Boeg First edition October 2011, Second edition February 2012 2. printing Printed in Denmark at Chronografisk A/S Trifork A/S Aarhus: Margrethepladsen 4, DK-8000 Aarhus C Copenhagen: Spotorno Alle 4, DK-2630 Taastrup Phone: +45 8732 8787 E-mail: [email protected] 4 Priming Kanban Priming Kanban 5 Contents Foreword, James Sutton.................................................................................................8 Step 6: Prioritize............................................................................................................54 Introduction...................................................................................................................10 Cost of Delay (COD)........................................................................................................55 Background.....................................................................................................................11 Visualizing Priority.........................................................................................................56 When should I consider working with Kanban?................................................................12 Step 7: Identify Classes of Service..................................................................................58 What is Kanban?..............................................................................................................13 Types of work.................................................................................................................59 How do we get started with Kanban?..............................................................................16 Define Classes of Service................................................................................................60 Where can Kanban be used?...........................................................................................17 Visualizing Classes of Service..........................................................................................61 Kanban Myths.................................................................................................................17 Step 8: Manage Flow.....................................................................................................65 Step 1: Visualize your workflow......................................................................................20 Decision filters...............................................................................................................66 Understanding your software delivery system................................................................21 Optimize flow not utilization..........................................................................................67 Visualizing your system...................................................................................................22 Relieve bottlenecks........................................................................................................69 Step 2: Limit Work in Progress (WIP)..............................................................................27 Introduce buffers............................................................................................................70 Understanding WIP........................................................................................................28 Release planning............................................................................................................70 Visualizing WIP Limits.....................................................................................................28 Experiment.....................................................................................................................72 Finding the right WIP limits.............................................................................................31 Step 9: Establish Service Level Agreements (SLA)..........................................................74 Step 3: Set Up Quality Assurance Policies and Make Them Explicit.................................33 Establishing the right Service Level Agreements.............................................................75 Understanding quality....................................................................................................34 Step 10: Focus on Continuous Improvement..................................................................78 Visualizing policies..........................................................................................................35 Good luck on your journey.............................................................................................81 Step 4: Adjust Cadences.................................................................................................38 Understanding Cadence..................................................................................................39 Finding the right cadences...............................................................................................41 Step 5: Measure Flow.....................................................................................................42 Understanding Metrics...................................................................................................43 What to measure?...........................................................................................................44 Cumulative flow diagrams (CFD).....................................................................................44 Reading the CFD.............................................................................................................45 Cycle time.......................................................................................................................46 Defect rate.....................................................................................................................47 Blocked Items.................................................................................................................49 6 Priming Kanban Priming Kanban 7 zed that Jesper had succeeded at both. Foreword by James Sutton He has a unique gift for getting to the core of a matter, and then helping others get to the core of it for themselves. Kanban is an industrial technique for “pulling” work through its entire life- cycle, causing the work to flow more smoothly and at a higher rate. Kanban I heartily recommend “Priming Kanban” as a practitioner’s quick-start intro- also shines a light on the activities that are normally hidden. This visibility is duction to using Kanban. It will enable you to try out Kanban more quickly at two levels; for individual activities, and also over the lifecycle as a whole. and painlessly…and defuse your anxiety about doing so. On a broader scale, as it inspires many people to take the same plunge, our industry will expand For many decades factory production has enjoyed the benefits of kanban: the use of this newest tool in our toolkit, Kanban…with all the benefits it higher productivity, better quality, and more-satisfied workers who enjoyed brings. increased insights into and control over their work. Until recently, howe- ver, nobody had figured out how the ideas of kanban might translate into a knowledge work field like software development. It wasn’t even clear if it And that’s good for all of us. would help in such fields. In the 2000s, David Anderson worked out the Rosetta Stone for such a translation, and developed the ideas of Kanban into an approach well-suited   for software development. His 2010 book “Kanban” painted the picture at, CEO, The Jubata Group say, VGA-resolution. It set an entire industry experimenting with the Kanban JPreasimdeents, LeSanu Stotftownare & Systems Consortium approach in many different product types and situations. They found that Shingo Prize, 2007 Kanban works with any development lifecycle, from Scrum to Waterfall. It INCOSE ESEP complements rather than competes with them. Anderson’s book left two things still wanting, however: An additional level of detail in the theory and practice of knowledge-work Kanban, and a “starter’s guide” for people about to take plunge. The additional needed level of detail is in an upcoming book by David Ander- son. You could say that it will be at HD-resolution for display on a big screen TV (I’ve talked to David some about the book). The other piece of the puzzle, the “starter’s guide,” is what you are about to read: Jesper Boeg’s mini-book “Priming Kanban.” Call it an iPhone video- podcast with which to follow along wherever you do your own work. A great complement to the big HD picture. When I recently received a draft of Jesper’s book for review, I didn’t think it possible for such a small book to contain both a concise overview and a practical, step-by-step worker’s introduction. As I read along, though, I reali- 8 Priming Kanban Priming Kanban 9 Background Before we dive into the step-by-step guide to implementing Kanban, let us spend a few minutes introducing the concept so that you will be able to recognise where each step fits into the overall Kanban change management framework. The scope of this mini book is not to describe Kanban concepts in depth; for that, I refer to David J. Anderson’s excellent book Kanban, which I n t r o d u c t i o n I strongly recommend reading: http://www.amazon.com/Kanban-Successful-Evolutionary-Technology-Busi- ness/dp/0984521402/ref=sr_1_1?ie=UTF8&qid=1313588404&sr=8-1 Instead, I hope to give a short introduction, followed by step-by-step advice on how to get started. Kanban, or more precisely “Kanban system for software development”, represents a more direct implementation of Lean Product Development principles in software development, compared to traditional Agile methods. With a consistent focus on flow and context, Kanban offers a less prescrip- tive approach to Agile and has become a popular extension to traditional methods, like Scrum and XP. The word “Kanban” is Japanese and means “Visual Card”. The reason that Google returns more than 5 million results on a search for Kanban is, howe- ver, that it also used to describe the system that has been used at Toyota for decades to visually control and balance the production line and which has become almost synonymous with the implementation of Lean principles. Therefore, while kanban systems are a relatively new concept in IT, it has been used for more than 50 years in Lean production systems at Toyota. The use of Kanban in software was pioneered by David Anderson, who, in close collaboration with Don Reinertsen, has strived to expand the know- ledge of Lean and the use of Kanban to visualize and optimize the workflow in IT development, maintenance and operations. 10 Priming Kanban Introduction | Priming Kanban 11 When should I consider working with What is Kanban? Kanban? There are a variety of approaches to Kanban, but most agree that Kanban is a change management method that focuses on the following principles: If the answer is yes to one or more of the following questions, there is a good chance you will benefit from reading the rest of this book: • Visualize Work - Visualize every step in your value chain from vague concept to releasable software. • Have you been struggling with implementing Agile in your organiza tion for a while without much success? • Limit Work-In-Progress (WIP) - Set explicit limits on the amount of work allowed in each • Have you been using Agile for a while and performance improve stage. ments have started to level off? • Make Policies Explicit • Are you using valuable time on Agile practices, which no longer - Make the policies you are acting according to explicit. seems to fit the context you are working in? • Measure and Manage Flow • Have you been using Agile as a checklist without fully understading - Measure and Manage Flow to make informed decisions the underlying principles? and visualise consequence • Do you have a need for more flexibility than frozen, committed and • Identify Improvement Opportunities planned iterations have to offer? - Create a Kaizen culture where continuous improvement is everyone’s job. • Do your priorities shift on a daily basis? With the underlying philosophy that you should: • Are you using processes designed for Agile product development in a context where they are not an easy fit, e.g. maintenance and • Start with what you do now operations? • Agree to pursue incremental, evolutionary change • Respect the current process, roles, responsibilities & titles • Do you need a gradual transition from waterfall type execution to Agile in order to avoid high levels of organizational resistance? Those of you familiar with Lean will recognize many of these principles as being the foundation for a Lean pull system and the building of a continuous Despite whether your goal is to work in a strict Scrum context, if you are improvement (Kaizen) culture. What Kanban first and foremost does is serve using waterfall or are trying to find a way to super optimize your current as a catalyst to introduce Lean ideas into software delivery systems. This is Agile implementation, most will benefit from the deeper understanding of also stated in David’s book: Lean, which Kanban has proven to be an excellent catalyst for. 12 Priming Kanban | Introduction Introduction | Priming Kanban 13 ”...Kanban (capital K) is the evolutionary change method that utilizes a kanban (small k) pull system, visualization, and other tools to catalyze the introduction of Lean ideas into technology development and IT operati- ons” David J. Anderson, Kanban 2010 We will show a lot of examples of Kanban boards in the following chapters and will explain the mechanics. To give you an idea of the concept, figure 1 shows an example. As you can see, all work is made visible. WIP limits are in place (written in each column header). Policies are made explicit and flow is measured. As you will notice, the last column does not have a WIP limit assigned. This is due to the fact that this particular team has opted for a regular weekly release cadence (3pm Tuesday), which means that all finished work is released at this time. Kanban is all about driving evolutionary change and these simple steps have proven extremely helpful in doing that. The reason we refer to such a system as a “Kanban Pull System” is that visualized flow and WIP limits ensure that you can never introduce more work into the system than it has capacity to handle. There is only a certain number of work permits (kanbans) available, so you must complete existing work before new work can be started. This results in functionality being pulled through the system, based on capacity rather than pushed based on forecasts or demand. There are no rules in terms of how your board should look. The only limitati- on is your imagination, creativity and the constraints of an electronic system or wall space. Since this is a starter’s guide, we will, however, use pretty basic board examples to demonstrate the principles. Fig. 1 Kanban Principles in Action 14 Priming Kanban | Introduction Introduction | Priming Kanban 15 How do we get started with Kanban? Where can Kanban be used? Hopefully, the 10 steps in this book will get you well on your way, but before Now we are almost ready to get started. However, before we dive into the we get that far, it is important to understand that Kanban has a different ap- implementation details, let us just quickly bust some of the myths about proach to change management than most other Agile methods. Kanban to make sure that the following sections are read with the right mindset in place. Kanban is built on the concept of evolutionary change. Start by understan- ding how your current software delivery system works. When you have At Trifork, we have helped a lot of companies and teams increase their ef- managed to visualize, measure and manage your flow, improve it one step at fectiveness by adopting Kanban. At first, it seemed that the primary target a time by relieving the largest bottleneck. This is quite different compared groups were teams working with maintenance and operation, but Kanban to e.g. Scrum, where you will often start out by redefining roles, process and has proven to be just as helpful for software development. Moreover, teams artefacts. This makes Kanban ideally fitted for use on top of existing proces- and organizations working with waterfall-like methods have found the evolu- ses, which can be anything from Scrum to Waterfall and perfect in situati- tionary approach to be extraordinarily helpful in a gradual transition to Agile ons where organizational structures inhibit radical change. Remember the product development. foundational principle: “Respect the current process, roles, responsibilities & titles” Kanban Myths In Lean terms, this means that Kanban is primarily built on the concept of • Myth: : Kanban is only suitable for teams working with small Kaizen (continuous improvement), and Kaikaku (dramatic change) is only uniform tasks, like those seen in operation and maintenance. used in special situations where structural change is needed or where seri- • Fact: Kanban is heavily inspired by Don Reinertsen’s work with ous performance leverage needs to be identified. Lean Product Development and has proven to be as good a fit to software development as it has been for operation and maintenance. • Myth: Kanban and Scrum are opposites. • Fact: None of the principles in Kanban restrict you from doing Scrum. Kanban acts as a change agent and the principles in Scrum should therefore only be used in cases where they help to optimize flow. Nothing is keeping you from starting with Scrum and using Kanban to drive further change – many projects have been incredibly successful with this strategy. Some might even argue that it was the original intention with Scrum as well; however, it somehow got lost in the focus on ceremonies, roles and artifacts. • Myth: By not insisting on planned committed iterations, Kanban falls prey to Parkinson’s Law that “Work expands so as to fill the time available for its completion”. Fig. 2 Kanban Takes an Evolutionary Approach to Process Optimization • Fact: Though being a valid concern, Kanban projects rarely display this behaviour, since fixed cadences, extreme visualization, 16 Priming Kanban | Introduction Introduction | Priming Kanban 17 cycle time measurement and tighter feedback loops with business Lean principles to optimize existing processes in an evolutionary way, and keep focus tight and work items flowing. therefore cannot and should not be compared to Scrum, XP, Crystal, FDD or whatever method you are using. • Myth: Kanban teams do not use timeboxes. • Fact: Timeboxes are not mandatory, but should be used when they The second reason is arguably that the word “Kanban” might carry too much help optimize flow, feedback and quality. Most Kanban teams use baggage from its origins in Lean production systems to be an adequate word fixed but decoupled cadences of planning, review and releases, to describe a change method for software development and IT operations. and thereby dispense with the traditional iteration model, while Though kanban pull systems, as they are used in production systems, do keeping the value intact. drive change, Kanban in software builds on a much broader set of Lean principles, and that creates a difficult mental gap for those having worked • Myth: Kanban teams do not estimate. extensively with Lean in the past. You will find that a lot of the strong reacti- • Fact: Estimates are not mandatory, but should be used when ons against Kanban, from parts of the Agile community, actually build on this appropriate. Most Kanban development projects use some degree misunderstanding. of initial sizing to ensure optimal portfolio management, prioritiza- tion and alignment, or use estimates for work that is more sensitive The good news is that most projects, Agile or non-Agile, can benefit hugely to cost/benefit analysis or due date performance. from using the principles of Kanban to drive change and continuous improve- ment, which I hope to demonstrate in this book. • Myth:Kanban is better than Scrum/XP/Crystal/FDD…. • Fact: Kanban is first and foremost a catalyst for driving change and The observant reader might have noticed that the title of this book is not therefore needs a starting point. exactly in line with the Kanban principles. As David Anderson wrote in a tweet on June 30, 2011 “… Kanban system design is a thinking process, not a copying or template implementing process”. However, those familiar with Therefore, while most projects will benefit from using Kanban, it is not a sub- the “Dreyfus Model of Skill Acquisition” will recognize that whenever stitute for e.g. Scrum. Scrum is in most cases a perfect starting point when acquiring a new skill, you need prescriptions at first; my hope is that this adopting Kanban. “primer” will help you transition quicker and more painlessly. The impor- tant thing is to know that prescriptions only serve as a way for you to gain Though the Kanban community is constantly fighting these and other myths, knowledge to move forward and not as an endpoint or a checklist to be fol- Kanban still remains one of the most misunderstood concepts in the Agile lowed blindly. The templates and practices suggested in the 10 steps in this community to this date for two main reasons: book are emergent behaviours experienced in Kanban projects, and not the Kanban change method itself. A lot of the noise and confusion revolves around the fact that Kanban is a change method and therefore has very few descriptive parts telling you Now that we have got the general picture, let’s go on to how we can apply how to work, which roles to fill, etc. Since the concept of a change method these things in practice. Each step consists of a short explanation on “why” is poorly understood, people have tried to compare it to more prescriptive followed by “how”. methods, such as Scrum and XP. Local examples and emergent behaviours of Kanban, in real world projects, have come to represent a “Kanban method” to some people. It is easy to see why people misunderstand, since many Kanban projects show the same emergent practices. Reality, however, is that Kanban is about using 18 Priming Kanban | Introduction Introduction | Priming Kanban 19