Marcus Hammarberg - Kanban in Action

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact

Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 261 Shelter Island, NY 11964 Email: orders@manning.com

2014 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps.

Recognizing the importance of preserving what has been written, it is Mannings policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without elemental chlorine.

Manning Publications Co.20 Baldwin RoadPO Box 261Shelter Island, NY 11964

Development editors: Beth Lexleigh, Cynthia KaneCopyeditor: Melinda RankinProofreader: Tiffany TaylorTypesetter: Marija TudorCover designer: Marija Tudor

ISBN: 9781617291050

Printed in the United States of America

1 2 3 4 5 6 7 8 9 10 MAL 19 18 17 16 15 14

A great deal of your brains 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.

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 its 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.

Thats a lot of information.

What weve 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.

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 fitit 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.

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 entre into kanban, welcome. You couldnt have asked for better guides.

J IM B ENSON
A UTHOR OF THE 2013 S HINGO A WARD-WINNING
PERSONALKANBAN

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 didnt feel right, because the work processes for many teams werent a good fit with the start-stop nature of Scrum. Also, most teams didnt 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.

In 2008, I was consulting as a Scrum Master in a three-team software development project in a large Swedish companys IT department. To deepen my understanding of agile software development, I was reading up on Lean software developmentwhich 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 drawthat 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.