David J. Anderson - Kanban: Successful Evolutionary Change for Your Technology Business

Successful Evolutionary Change
for Your Technology Business

David J. Anderson

Sequim, Washington

Blue Hole Press

72 Buckhorn Road

Sequim, WA 98382

www.blueholepress.com

Copyright 2010 by David J. Anderson

All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage or retrieval system, without permission in writing from the publisher.

Published in the United States of America.

Library of Congress Cataloging-in-Publication Data

applied for; available at www.loc.gov

ISBN: 978-0-9845214-2-9 (e-pub)

Cover art copyright 2010 by Pujan Roka

Cover photo copyright 2010 by Laurence Cohen

Cover and interior design by Vicki L. Rowland

Photos on page 12 used with permission, Thomas Blomseth

10 9 8 7 6 5 4 3 2

For Nicola and Natalie

I always pay attention to David Andersons work. My first contact with him was in October 2003, when he sent me a copy of his book, Agile Management for Software Engineering: Applying Theory of Constraints for Business Results. As its title implies, this book was heavily influenced by Eli Goldratts Theory of Constraints (TOC). Later, in March 2005, I visited him at Microsoft; by this time he was doing impressive work with cumulative flow diagrams. Later still, in April 2007, I had a chance to observe the breakthrough kanban system that he had implemented at Corbis.

I trace this chronology to give you a sense of the relentless pace at which Davids management thinking has advanced. He does not get stuck on a single idea and try to force the world to fit it. Instead, he pays careful attention to the overall problem he is trying to solve, stays open to different possible solutions, tests them in action, and reflects on why they work. You will see the results of this approach throughout this new book.

Of course, speed is most useful if it is in the correct direction; I am confident David is headed in the right direction. I am particularly excited by this latest work with kanban systems. I have always found the ideas of lean manufacturing more directly useful in product development than those of TOC. In fact, in October 2003 I wrote to David, saying, One of the great weaknesses of TOC is its underemphasis of the importance of batch size. If your first priority is to find and reduce the constraint you are often solving the wrong problem. I still believe this is true.

In our 2005 meeting I again encouraged David to look beyond the bottleneck focus of TOC. I explained to him that the dramatic success of the Toyota Production System (TPS) had nothing to do with finding and eliminating bottlenecks. Toyotas performance gains came from using batch-size reduction and variability reduction to reduce work-in-process inventory. It was the reduction in inventory that unlocked the economic benefits, and it was WIP-constraining systems like kanban that made this possible.

By the time I visited Corbis in 2007 I saw an impressive implementation of a kanban system. I pointed out to David that he had progressed far beyond the kanban approach used by Toyota. Why did I say this? The Toyota Production System is elegantly optimized to deal with repetitive and predictable tasks: tasks with homogeneous task durations and homogeneous delay costs. Under such conditions it is correct to use approaches like first-in-first-out (FIFO) prioritization. It is also correct to block the entry of work when the WIP limit is reached. However, these approaches are not optimal when we must deal with non-repetitive, unpredictable jobs; with different delay costs; and different task durationsexactly what we must deal with in product development. We need more advanced systems, and this book is the first to describe these systems in practical detail.

Id like to offer a few brief warnings to readers. First, if you think you already understand how kanban systems work, you are probably thinking of the kanban systems used in lean manufacturing. The ideas in this book go far beyond such simple systems that use static WIP limits, FIFO scheduling, and a single class of service. Pay careful attention to these differences.

Second, dont just think of this approach as a visual control system. The way kanban boards make WIP visible is striking, but it is only one small aspect of this approach. If you read this book carefully you will find much more going on. The real insights lie in aspects like the design of arrival and departure processes, the management of non-fungible resources, and the use of classes of service. Dont be distracted by the visual part and miss the subtleties.

Third, dont discount these methods because they appear easy to use. This ease of use is a direct result of Davids insight into what produces the maximum benefit with the minimum effort. He is keenly aware of the needs of practitioners and has paid careful attention to what actually works. Simple methods create the least disruption and almost always produce the largest sustained benefits.

This is an exciting and important book that deserves careful reading. What you will get from it will depend on how seriously you read it. No other book will give you a better exposure to these advanced ideas. I hope will you enjoy it as much as I have.

Don Reinertsen, Author of The Principles of Product Development Flow

February 7, 2010

Redondo Beach, California

In 2002, I was an embattled development manager in a remote outpost of Motorolas PCS (cell phone) division based in Seattle, Washington. My department had been part of a startup company Motorola had acquired a year earlier. We developed network server software for wireless data services such as over-the-air download and over-the-air device management. These server applications were part of integrated systems that worked hand-in-hand with client code on the cell phones, as well as with other elements within the telecom carriers networks and back-office infrastructure, such as billing. Our deadlines were set by managers without regard to engineering complexity, risk, or project size. Our code base had evolved from the original startup company, where many corners had been cut. One senior developer insisted on referring to our product as a prototype. We were in desperate need of greater productivity and higher quality in order to meet business demands.