Kanban in Action

Marcus Hammarberg is a software developer and kanban coach. He is experienced with numerous modern methodologies including BDD and TDD, Specification By Example, Scrum, and XP.

Joakim Sunden has been a kanban practitioner and coach since 2008. He co-founded two of the first kanban user groups in Europe and now speaks regularly at conferences worldwide.

foreword
preface
about this book
about the authors
about the cover illustration
acknowledgments
Part1 Learning kanban

1 Team Kanbaneros gets started
1.1 Introductions
1.2 The board
1.3 Mapping the workflow
1.4 Work items
1.5 Pass the Pennies
1.6 Work in process
1.7 Expedite items
1.8 Metrics 38
1.9 The sendoff
1.10 Summary

Part 2 Understanding kanban

2 Kanban principles
2.1 The principles of kanban
2.2 Get started right away
2.3 Summary
3 Visualizing your work
3.1 Making policies explicit
3.2 The kanban board
3.3 Queues
3.4 Summary
4 Work items
4.1 Design principles for creating your cards
4.2 Work-item cards
4.3 Types of work
4.4 Progress indicators
4.5 Work-item size
4.6 Gathering workflow data
4.7 Creating your own work-item cards
4.8 Summary
5 Work in process
5.1 Understanding work in process
5.2 Effects of too much WIP
5.3 Summary
6 Limiting work in process
6.1 The search for WIP limits
6.2 Principles for setting limits
6.3 Whole board, whole team approach
6.4 Limiting WIP based on columns
6.5 Limiting WIP based on people
6.6 Frequently asked questions
6.7 Exercise: WIP it, WIP it real good
6.8 Summary
7 Managing flow
7.1 Why flow?
7.2 Helping the work to flow
7.3 Daily standup
7.4 What should I be doing next?
7.5 Managing bottlenecks
7.6 Summary

Part 3 Advanced kanban

8 Classes of service
8.1 The urgent case
8.2 What is a class of service?
8.3 Managing classes of services
8.4 Exercise: classify this!
8.5 Summary
9 Planning and estimating
9.1 Planning scheduling: when should you plan?
9.2 Estimating work—relatively speaking
9.3 Estimation techniques
9.4 Cadence
9.5 Planning the kanban way: less pain, more gain
9.6 Summary
10 Process improvement
10.1 Retrospectives
10.2 Root-cause analysis
10.3 Kanban Kata
10.4 Summary
11 Using metrics to guide improvements
11.1 Common metrics
11.2 Two powerful visualizations
11.3 Metrics as improvement guides
11.4 Exercise: measure up!
11.5 Summary
12 Kanban pitfalls
12.1 All work and no play makes Jack a dull boy
12.2 Timeboxing is good for you
12.3 The necessary revolution
12.4 Don’t allow kanban to become an excuse to be lazy
12.5 Summary
13 Teaching kanban through games
13.1 Pass the Pennies
13.2 The Number Multitasking Game
13.3 The Dot Game
13.4 The Bottleneck Game
13.5 getKanban
13.6 The Kanban Pizza Game
13.7 Summary
appendix A Recommended reading and other resources
appendix B Kanban tools
index

A great deal of your brain’s capacity is devoted to absorbing, processing, acting on, and storing visual information. What we see inspires us to act now and instills patterns for future action. If we have nothing to look at, we have little to act on. See and understand Visual systems like kanban draw their power from our preference for visual information. Take a look, for example, at the following simple map. You see the water, the buildings, the roads, and a host of other information. You recognize this immediately. Within the blink of an eye, you understand context, form, and substance. Here is a list of everything I cared to write down from that map. This is a partial list. And it’s in a font size necessary not to fill pages with text: Salmon Bay Marine Center Lake Washington Ship Canal W. Commodore Way 20th Ave W Gilman Place W W Elmore Street 21st Ave W Gilman Ave W Shilshole Ave NW W Fort Street 26th Ave W 24th Ave W You can quickly see that long lists of things provide less context and take more time to process than a map. Our goal with visual systems like kanban is to build a map of our work. We want the form and substance of our work. We want to understand the system, immediately and intuitively. We want our kanban board to be explicit about roles, responsibilities, work in progress, rate of completion, the structure of our processes, impediments, and more. That’s a lot of information. What we’ve found since launching kanban as a software design tool nearly a decade ago is this: Seeing the work and the process creates understanding. Once we see our work, we build a shared understanding of it. Then we can do away with messy process conventions that have plagued software development for years. The kanban board can become a simple single point that lets anyone come and understand the current state of the project. This means software teams can finally speak the same language as the business! The division between IT and the rest of the company can dissolve. A translator has arrived. Seeing is half the battle In this book, Marcus and Joakim list three elements of a project using kanban: Visualize Limit work in process Manage flow I like this list. For Personal Kanban, we use the first two (visualize your work and limit work in process) and see the third as following naturally. But I like the list of three because it drives this point home: Work does not fit—it flows. Smashing work into arbitrary amounts of time has profound negative impacts on rate of completion, escaped defects, and morale. The stress of unnecessary deadlines or overenthusiastic feature sets deprecates both people and product. The focus becomes making work fit into the deadline period, rather than completion with quality. Completion of work with quality is possible only if work is flowing at a truly sustainable pace. Finding and maintaining that pace is possible only if active work in process (WIP) is less than the capacity of those doing the work. Cramming things in before deadlines will almost always result in breaking your WIP limit. Too much WIP destroys flow With a reasonable WIP limit, we encourage the flow of work. Tasks are completed in a measured fashion with an eye on quality. Overhead from managing too much WIP disappears. And, not surprisingly, productivity skyrockets. This is the short form of what Marcus and Joakim have given you in this book. They provide fantastic and patient detail. If this is your entrée into kanban, welcome. You couldn’t have asked for better guides. Jim Benson Author of the 2013 Shingo Award-winning Personal Kanban

Marcus’s journey I was introduced to agile via Scrum and started to use it, guerilla-style, at a large insurance company in Sweden. Before long, it spread; and within a few years the company had more than 50 Scrum teams. But it still didn’t feel right, because the work processes for many teams weren’t a good fit with the start-stop nature of Scrum. Also, most teams didn’t span the entire process; the teams mostly consisted of developers who were handed requirements and who then delivered to a separate testing phase. I felt the itch to try to incorporate more of the complete process that the work went through. This itch led me to start investigating other practices in the agile community. Before long, and through some helpful pointers from Joakim, I found and started to read up on kanban. In 2010 and 2011, I attended trainings on kanban and kanban coaching given by David J. Anderson. These further confirmed my feeling that kanban and Lean were what I had been looking for. Joakim’s journey In 2008, I was consulting as a Scrum Master in a three-team software development project in a large Swedish company’s IT department. To deepen my understanding of agile software development, I was reading up on Lean software development—which led me to the amazing story of Toyota and a lot of literature about Lean thinking and the Toyota Way. The studying reached a climax of sorts when I went on a study tour to Toyota HQ in Japan together with Mary and Tom Poppendieck, authors of Lean software development books, in the spring of 2009. In late 2008, my client came to the conclusion that most, if not all, clients paying for software development eventually draw—that things are moving too slowly. They wanted more development done more quickly, but without cutting scope or quality. Inspired by the Lean thinking around one-piece contiguous flow, I suggested that we should stop planning batches of work in Scrum sprint-planning meetings every two or three weeks (a cadence that felt more and more arbitrary to us) and instead try to focus on one or a few work items and collaboratively get them done as quickly as possible, in a continuous flow of value. The dozen or so team members agreed to not have more than two work items in development and two in testing at any time, and that only when something was finished would we pull new work items from the backlog to plan them just-in-time. I soon learned about something called kanban that seemed similar to what we were doing, first through Corey Ladas’s blog and then through the work of David J. Anderson. In 2009, I connected with the community through the first Lean Kanban conference in the UK. I was immediately attracted by the pragmatic approach of looking at what had actually worked for different teams and companies in their respective contexts, at a time when I felt that a lot of the agile community focus was on faith-based approaches like “How is Scrum telling us how to solve this?” The next year, I participated in David J. Anderson’s first kanban coaching workshop ever (now called Advanced Master Class) in London, together with, among others, experienced practitioners like Rachel Davies, David P. Joyce, and Martine Devos. I cofounded Stockholm Lean Coffee in 2010, where kanban enthusiasts have kept meeting every week since. In 2011, I was invited to attend the first Kanban Leadership Retreat hosted by David J. Anderson, during which I became one of the first “David J. Anderson approved” kanban trainers. The common journey Together with our colleague at Avega Group at the time, Christophe Achouiantz, we started developing a practical introduction to kanban in 2010. It was an immediate success and the starting point for a long series of conference talks in both Europe and the US, including in-client trainings, tutorials, and workshops, sometimes conducted individually, sometimes by the two of us together. The practical approach of our work resonated well with many people who attended our talks and tutorials, and we received a lot of positive feedback. It was after a conference tutorial at JFokus (a great conference organized by Mattias Karlsson, another Avega Group colleague) that Marcus got a call from Manning Publications, asking him if he was interested in writing a book. He immediately felt that he should do it together with Joakim. We decided to write the book in the same manner as the presentation we had created, using a practical approach and a lighthearted style.