Principles of Lean Software Development

Eliminate WasteThe three biggest wastes in software development are:

Extra FeaturesWe need a process that allows us to develop just those 20 percent of the features that give 80 percent of the value.

ChurnIf you have requirements churn, you are specifying too early. If you have test and fix cycles, you are testing too late.

Crossing BoundariesOrganizational boundaries can increase costs by 25 percent or more. They create buffers that slow down response time and interfere with communication.

Build Quality In If you routinely find defects in your verification process, your process is defective.

Mistake-Proof Code with Test-Driven DevelopmentWrite executable specifications instead of requirements.

Stop Building Legacy CodeLegacy code is code that lacks automated unit and acceptance tests.

The Big Bang Is ObsoleteUse continuous integration and nested synchronization.

Create KnowledgePlanning is useful. Learning is essential.

Use the Scientific MethodTeach teams to establish hypotheses, conduct many rapid experiments, create concise docu-mentation, and implement the best alternative.

Standards Exist to Be Challenged and ImprovedEmbody the current best known practices in standards that are always followed while actively encouraging everyone to challenge and change the standards.

Predictable Performance Is Driven by FeedbackA predictable organization does not guess about the future and call it a plan; it develops the capacity to rapidly respond to the future as it unfolds.

Defer CommitmentAbolish the idea that it is a good idea to start development with a complete specification.

Break DependenciesSystem architecture should support the addition of any feature at any time.

Maintain OptionsThink of code as an experiment—make it change-tolerant.

Schedule Irreversible Decisions at the Last Responsible MomentLearn as much as possible before making irreversible decisions.

Deliver FastLists and queues are buffers between organizations that slow things down.

Rapid Delivery, High Quality, and Low Cost Are Fully CompatibleCompanies that compete on the basis of speed have a significant cost advantage, deliver superior quality, and are more attuned to their customers’ needs.

Queuing Theory Applies to Development, Not Just ServersFocusing on utilization creates traffic jams that actually reduce utilization. Drive down cycle time with small batches and fewer things-in-process.

Limit Work to CapacityEstablish a reliable, repeatable velocity with iterative development. Aggressively limit the size of lists and queues to your capacity to deliver.

Respect PeopleEngaged, thinking people provide the most sustainable competitive advantage.

Teams Thrive on Pride, Commitment, Trust, and ApplauseWhat makes a team? Members are mutually committed to achieve a common goal.

Provide Effective LeadershipEffective teams have effective leaders who bring out the best in the team.

Respect PartnersAllegiance to the joint venture must never create a conflict of interest.

Optimize the WholeBrilliant products emerge from a unique combination of opportunity and technology.

Focus on the Entire Value Stream—from concept to cash.—from customer request to deployed software.

Deliver a Complete ProductDevelop a complete product, not just software.Complete products are built by complete teams.

Measure UPMeasure process capability with cycle time.Measure team performance with delivered business value.Measure customer satisfaction with a net promoter score.

Praise for Implementing Lean Software Development

“This book offers a wealth of advice for any organization that wishes to succeed at thesoftware development game. It will help you to realize the value of adopting a productmindset to software development to recognize the inherent wastage and risk in tradi-tional software development practices. Mary has hit another one out of the park.”

—Scott Ambler, practice leader, Agile modeling

“This remarkable book combines practical advice, ready-to-use techniques, and a deepunderstanding of why this is the right way to develop software. I have seen softwareteams transformed by the ideas in this book.”

—Mike Cohn, author of Agile Estimating and Planning

“As a lean practitioner myself, I have loved and used their first book for years. Whenthis second book came out, I was delighted that it was even better. If you are interestedin how lean principles can be useful for software development organizations, this is thebook you are looking for. The Poppendiecks offer a beautiful blend of history, theory,and practice.”

—Alan Shalloway, coauthor of Design Patterns Explained

“I’ve enjoyed reading the book very much. I feel it might even be better than the firstlean book by Tom and Mary, while that one was already exceptionally good! Mary espe-cially has a lot of knowledge related to lean techniques in product development andmanufacturing. It’s rare that these techniques are actually translated to software. This issomething no other book does well (except their first book).”

—Bas Vodde

“The new book by Mary and Tom Poppendieck provides a well-written and comprehen-sive introduction to lean principles and selected practices for software managers andengineers. It illustrates the application of the values and practices with well-suited suc-cess stories. I enjoyed reading it.”

—Roman Pichler

“In Implementing Lean Software Development, the Poppendiecks explore more deeplythe themes they introduced in Lean Software Development. They begin with a compel-ling history of lean thinking, then move to key areas such as value, waste, and people.Each chapter includes exercises to help you apply key points. If you want a better under-standing of how lean ideas can work with software, this book is for you.”

—Bill Wake, independent consultant

This page intentionally left blank

Implementing Lean Software Development

The Addison-Wesley Signature Series provides readers with

practical and authoritative information on the latest trends in modern

technology for computer professionals. The series is based on one simple

premise: Great books come from great authors. Books in the series are

personally chosen by expert advisors, world-class authors in their own

right. These experts are proud to put their signatures on the covers, and

their signatures ensure that these thought leaders have worked closely

with authors to define topic coverage, book scope, critical content, and

overall uniqueness. The expert signatures also symbolize a promise to

our readers: You are reading a future classic.

Visit informit.com/awss for a complete list of available products.

The Addison-Wesley

Signature SeriesKent Beck, Mike Cohn, and Martin Fowler, Consulting Editors

Implementing LeanSoftware DevelopmentFrom Concept to Cash

Mary and Tom Poppendieck

Upper Saddle River, NJ • Boston • Indianapolis • San Francisco

New York • Toronto • Montreal • London • Munich • Paris • Madrid

Capetown • Sydney • Tokyo • Singapore • Mexico City

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trade-marks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

Screen Beans art is used with permission of A Bit Better Corporation. Screen Beans is a registered trademark of A Bit Better Corporation.

The authors and publisher have taken care in the preparation of this book, but make no expressed or implied war-ranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or conse-quential damages in connection with or arising out of the use of the information or programs contained herein.

The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:

U.S. Corporate and Government Sales(800) 382-3419corpsales@pearsontechgroup.com

For sales outside of the U.S., please contact:

International Salesinternational@pearsoned.com

This Book Is Safari Enabled

The Safari® Enabled icon on the cover of your favorite technology book means the book is avail-able through Safari Bookshelf. When you buy this book, you get free access to the online edition for 45 days.

Safari Bookshelf is an electronic reference library that lets you easily search thousands of technical books, find code samples, download chapters, and access technical information whenever and wherever you need it.

To gain 45-day Safari Enabled access to this book:

• Go to http://www.awprofessional.com/safarienabled• Complete the brief registration form• Enter the coupon code EDGG-GUQI-A1FM-GZI1-K7E3

If you have difficulty registering on Safari Bookshelf or accessing the online edition, please e-mail customer-service@safaribooksonline.com.

Visit us on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication DataPoppendieck, Mary.Implementing lean software development : from concept to cash / Mary Poppendieck, Tom Poppendieck.

p. cm. Includes bibliographical references and index. ISBN 0-321-43738-1 (pbk. : alk. paper) 1. Computer software—Development. 2. Production management. I. Poppendieck, Thomas David. II. Title.

QA76.76.D47P674 2006 005.1—dc22

2006019698

Copyright © 2007 Poppendieck LLC

All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permis-sion must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For infor-mation regarding permissions, write to:

Pearson Education, Inc.Rights and Contracts Department75 Arlington Street, Suite 300Boston, MA 02116Fax: (617) 848-7047

ISBN 0-321-43738-1Text printed in the United States on recycled paper at Courier in Stoughton, Massachusetts.Second printing, December 2006

To our parents:John and Marge Brust

andElmer and Ruth Poppendieck

This page intentionally left blank

ix

Contents

Foreword by Jeff Sutherland . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Foreword by Kent Beck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Chapter 1: History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Interchangeable Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Interchangeable People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2The Toyodas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3The Toyota Production System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Taiichi Ohno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Just-in-Time Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Autonomation (Jidoka) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Shigeo Shingo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Nonstock Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Zero Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Just-in-Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Lean Manufacturing / Lean Operations . . . . . . . . . . . . . . . . . . . 11Lean Supply Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Lean Product Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Lean Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Chapter 2: Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Principles and Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

x CONTENTS

Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

The Seven Principles of Lean Software Development . . . . . . . . . . . 23Principle 1: Eliminate Waste . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Myth: Early Specification Reduces Waste . . . . . . . . . . . . . . . 24Principle 2: Build Quality In . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Myth: The Job of Testing Is to Find Defects . . . . . . . . . . . . . 28Principle 3: Create Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Myth: Predictions Create Predictability . . . . . . . . . . . . . . . . . 31Principle 4: Defer Commitment . . . . . . . . . . . . . . . . . . . . . . . . . 32

Myth: Planning Is Commitment . . . . . . . . . . . . . . . . . . . . . . 33Principle 5: Deliver Fast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Myth: Haste Makes Waste . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Principle 6: Respect People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Myth: There Is One Best Way . . . . . . . . . . . . . . . . . . . . . . . . 37Principle 7: Optimize the Whole . . . . . . . . . . . . . . . . . . . . . . . . 38

Myth: Optimize By Decomposition . . . . . . . . . . . . . . . . . . . . 40Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Chapter 3: Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Lean Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Google . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43From Concept to Cash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Pilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Cash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Delighted Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Deep Customer Understanding . . . . . . . . . . . . . . . . . . . . . . . . . 50Focus on the Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

The Customer-Focused Organization . . . . . . . . . . . . . . . . . . . . . . . 52Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

The Chief Engineer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Leadership Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Shared Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Who’s Responsible? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Complete Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

CONTENTS xi

Design for Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Custom Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

From Projects to Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60IT—Business Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Chapter 4: Waste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Write Less Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Zara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Justify Every Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Minimum Useful Feature Sets . . . . . . . . . . . . . . . . . . . . . . . . 71Don’t Automate Complexity . . . . . . . . . . . . . . . . . . . . . . . . . 72

The Seven Wastes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Partially Done Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Extra Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Relearning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Handoffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Task Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Defects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Mapping the Value Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Choose a Value Stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Choose When to Start and Stop the Timeline . . . . . . . . . . . . 84Identify the Value Stream Owner . . . . . . . . . . . . . . . . . . . . . 84Keep It Simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Future Value Stream Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

xii CONTENTS

Chapter 5: Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Deliver Fast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95PatientKeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Time: The Universal Currency . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Queuing Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Little’s Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Variation and Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Reducing Cycle Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Even Out the Arrival of Work . . . . . . . . . . . . . . . . . . . . . . . 103Minimize the Number of Things in Process . . . . . . . . . . . . . 105Minimize the Size of Things in Process . . . . . . . . . . . . . . . . 107Establish a Regular Cadence . . . . . . . . . . . . . . . . . . . . . . . . 108Limit Work to Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Use Pull Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Chapter 6: People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A System of Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117The Boeing 777 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117W. Edwards Deming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Why Good Programs Fail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126What Makes a Team? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Expertise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Responsibility-Based Planning and Control . . . . . . . . . . . . . . . 133

The Visual Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Self-Directing Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Andon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Incentives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Performance Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Guideline No. 1: Make Sure the Promotion System Is Unassailable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

CONTENTS xiii

Guideline No. 2: De-emphasize Annual Raises . . . . . . . . . . 144Guideline No. 3: Reward Based on Span of Influence, Not Span of Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Guideline No. 4: Find Better Motivators Than Money . . . . 145

Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Chapter 7: Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Creating Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Rally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149What, Exactly, Is Your Problem? . . . . . . . . . . . . . . . . . . . . . . . 152A Scientific Way of Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . 154Keeping Track of What You Know . . . . . . . . . . . . . . . . . . . . . 155

The A3 report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157The Internet Age . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Just-in-Time Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Set-Based Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Example 1: Medical Device Interface Design . . . . . . . . . . . . 162Example 2: Red-Eye Reduction . . . . . . . . . . . . . . . . . . . . . . 162Example 3: Pluggable Interfaces . . . . . . . . . . . . . . . . . . . . . 163Why Isn’t This Waste? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Legacy Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Problem Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168A Disciplined Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

1. Define the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692. Analyze the Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1693. Create a Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714. Perform Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1715. Verify Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726. Follow Up/Standardize . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Kaizen Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Large Group Improvement Events . . . . . . . . . . . . . . . . . . . 173

Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Chapter 8: Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177The Polaris Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Release Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

xiv CONTENTS

Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Iterations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188Variation: User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Discipline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190The Five S’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Code Reviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Mistake-Proofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Test-Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Unit Tests (Also Called Programmer Tests) . . . . . . . . . . . . . 200Story Tests (Also Called Acceptance Tests) . . . . . . . . . . . . . 200Usability and Exploratory Testing . . . . . . . . . . . . . . . . . . . . 201Property Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Nested Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Chapter 9: Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Synergy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Emergency! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209Global Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217The T5 Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217The PS 2000 Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218Relational Contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

CONTENTS xv

Chapter 10: Journey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Where Do You Want to Go? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223A Computer on Wheels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224A Long-Term Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Centered on People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

What Have We Learned? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Six Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Process Leaders—Natural Work Team Leaders . . . . . . . . . 229Tools—Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Theory of Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230Critical Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Accommodations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234Thinking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Cycle Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Financial Return . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240Customer Satisfaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242Try This . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Optimize the Whole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Respect People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243Deliver Fast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Defer Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Create Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Build Quality In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245Eliminate Waste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

This page intentionally left blank

xvii

ForewordJeff Sutherland

I created the first Scrum in 1993 at Easel Corporation in Burlington, Massachu-setts,1 in cooperation with our CEO, who bet his company on the team thatmade the first Scrum work. In 1995, I began working with Ken Schwaber, whoformalized the process for worldwide deployment.2 In four companies sinceEasel, I have used the self-organizing nature of Scrum to move from a Type AScrum (winning teams) to a Type B Scrum (winning product portfolios) to aType C Scrum (winning companies).

In 2000, I introduced Scrum to PatientKeeper, and this has proven to be anexcellent vehicle for lean development. Over the years we have shortened cycletimes to exactly what customers need: one week for critical items, one monthfor minor enhancements, and three months for significant new products. Thethree-month releases are accumulations of one-month Sprints, and every Sprintis a release.

At PatientKeeper the entire company runs as a Scrum and inspects, adapts,self-organizes, and changes every Monday when we have our MetaScrum meet-ing.3 The Product Owner runs this meeting, and all company stakeholders arepresent, including the CEO. Lean concepts are carefully examined here, andSprints are started, stopped, or changed only in this meeting. The whole com-pany, including affected customers, can be reset in one afternoon with decisionsmade during the weekly MetaScrum.

1. Sutherland, J., “Agile Development: Lessons Learned from the First Scrum,” Cutter Agile Project Management Advisory Service: Executive Update, 2004, 5(20): pp. 1–4.

2. Schwaber, K., “Scrum Development Process,” in OOPSLA Business Object Design and Implementation Workshop, J. Sutherland, et al., editors. 1997, Springer: London.

3. Sutherland, J., “Future of Scrum: Parallel Pipelining of Sprints in Complex Projects,” in AGILE 2005 Conference. 2005. Denver, Colorado: IEEE.

xviii FOREWORD

We have a chief Product Owner with a team that gets the Product Backlog“ready.” We have a chief ScrumMaster, who runs a 15-minute daily Scrum ofScrums. What did teams do yesterday, what will they do today, and what arethe impediments to delivery? We manage 45 releases of software per year intolarge, mission-critical enterprises using these short meetings and using an auto-mated system that tracks the state of concurrent Sprint backlogs. Dates arecommitted to customers before the start of a Sprint, and thousands of Webusers and hundreds of physicians with PDAs go live at the end of every Sprint.For PatientKeeper, concept (Product Backlog) to cash (product in production)occurs in one-month intervals. We have had to eliminate waste everywhere—before, during, and after the implementation process.

In 1993, lean product development was not well understood in any industry.Scrum was the first concrete implementation of lean thinking to software devel-opment that allowed organizations of all types and sizes to start up lean teamsin a couple of days using a standard pattern that was easily understood. Whatwas hard was explaining why and how to implement the pattern to generatecontinuous quality and productivity improvement.

Today, the writing and courses from Mary and Tom Poppendieck provide aproven set of principles that organizations can use to adapt tools, techniques,and methods to their own specific unique contexts and capabilities. Now wecan explain how to use Scrum to lean out software development. In addition tomy company, PatientKeeper, I use the procedures and processes outlined in thisbook to teach practitioners worldwide how to optimize Scrum.

Lean software development views all agile methods as valid, proven applica-tions of lean thinking to software. It also goes beyond agile, providing abroader perspective that enables agile methods to thrive. First, it looks alongthe whole value chain, from concept to cash and tries to address all the wasteand delays that happen before and after the coders contribute their part. Sec-ond, it establishes a management context to extend, nourish, and leverage agilesoftware practices. Third, it provides a proven set of principles that each orga-nization can use to adapt tools, techniques, and methods to their own specificunique contexts and capabilities.

Every chapter in this book illustrates a set of principles that can be imple-mented to build more productive teams. If you want to be like Toyota, whereproductivity is consistently four times that of its competitors and quality istwelve times better, these practices are essential. If you execute well on the prin-ciples in this book, resistance by your competition is futile, and winning in yourmarket is certain. The return on investment in practices outlined in this bookcan be very high.

FOREWORD xix

To create the lean “secret sauce” for your company, we have found you mustsystematically implement this accumulated lean wisdom. In short, you mustdeeply understand the Japanese concepts of Muri, Mura, and Muda. Mary andTom unfold them as the seven lean principles and the seven wastes of softwaredevelopment to help you easily understand how they work and know what todo.

Muri relates to properly loading a system and Mura relates to never stressinga person, system, or process. Yet many managers want to load developers at110 percent. They desperately want to create a greater sense of “urgency” sodevelopers will “work harder.” They want to micromanage teams, which stiflesself-organization. These ill-conceived notions often introduce wait time, churn,death marches, burnout, and failed projects.

When I ask technical managers whether they load the CPU on their laptop to110 percent they laugh and say, “Of course not. My computer would stop run-ning!” Yet by overloading teams, projects are often late, software is brittle andhard to maintain, and things gradually get worse, not better. One needs tounderstand that Toyota and Scrum use a pull system that avoids stress (Mura)and eliminates bottlenecks (Muri). The developers take what they need off theProduct Backlog just in time. They choose only Product Backlog that is ready totake into a Sprint, and they never take more than they can get done in a Sprint.They go faster by surfacing impediments and working with management toeliminate waste (Muda). By removing waste, they have less work to do. Produc-tivity goes up, and they have time to deliver quality software and focus onexactly what the customers need.

So by understanding loading (Muri) and avoiding stress (Mura) you shortencycle time. This leans out the environment causing impediments that createwaste (Muda) to be highly visible. When you eliminate these impediments, yourteams move faster, do more with less, increase quality, and move the productright into the sweet spot for the customer.

I recommend you keep the Poppendiecks’ books on your desk and use themregularly to help with systematic and continuous implementation of lean princi-ples. Practice hard, and you will rapidly double productivity by using leandevelopment to do less by avoiding waste, and then double it again by workingsmarter by eliminating impediments. By going four times faster in the right way,your quality will improve by a factor of twelve like Toyota.

—Jeff Sutherland, Ph.D.Chief Technology Officer, PatientKeeper

Certified ScrumMaster TrainerInventor of the Scrum Development Process

July 2006

xx

ForewordKent Beck

Software development is a chain with many links, and improving overall effec-tiveness requires looking at the whole chain. This book is for people involved insoftware development—not just programmers, but also managers, sponsors,customers, testers, and designers. The principles presented here eventuallyaffect everyone connected to the development of software. This book speaks tothose of you who are ready to look at the big picture of development.

For ideas to have impact, they must be grounded in both theory and experi-ence. By translating well-proven ideas from lean manufacturing, this book pre-sents theory and practice and applies them to software development. Many ofthe fundamental problems with manufacturing are also problems with softwaredevelopment: dealing with uncertainty and change, continuously improvingprocesses, and delivering value to customers.

What does this book offer you? First, a wide variety of theories that providealternative ways of thinking about how software development can beimproved. Second, a set of stories about the application of these theories to realprojects. Third, provocative questions to help you apply the theories and thelessons in the stories to your unique situation.

Mary is uniquely qualified to present this material. She experienced leanmanufacturing firsthand, helping rescue a plant from being shut down by trans-forming its operations. She’s also experienced software development as a pro-grammer and a manager. I once shared a seminar with Mary, and it was a treatto see the force and confidence with which she presents her material. I can hearthat same direct voice in her writing here.

If you’ve read the Poppendiecks’ precursor book, Lean Software Develop-ment, this book offers new guidance towards its implementation. It reiteratesthe theory in the previous volume, but always with an eye towards applying theideas in real situations. The result is a readable and practical guide to ideas thathave the potential to help you transform your development.

FOREWORD xxi

This is a book for doers, doers who want their actions aligned with wherethey can do the most good. If you are such a person, I recommend this book toyou as a source of ideas and energy for positive change.

—Kent BeckThree Rivers Institute

July 2006

This page intentionally left blank

xxiii

Preface

The Sequel

Lean was an idea borrowed from the 1990s when we wrote the book LeanSoftware Development: An Agile Toolkit in 2003. We had observed that break-through ideas from manufacturing and logistics often take a decade or twobefore they are adapted to provide suitable guidance for development efforts.So we decided it was not too late to use well-proven lean concepts from the1980s and 1990s to help us explain why agile methods are a very effectiveapproach to software development.

The strategy worked. The book Lean Software Development presents a setof thinking tools based on lean thinking that leaders continue to find useful forunderstanding agile software development. The book has been purchased bymany a developer who gave it to his or her manager to read, and many manag-ers have distributed multiple copies of the book to colleagues in support of atransition to lean/agile software development.

Meanwhile, something unexpected happened to lean. In the last couple ofyears lean initiatives have experienced a resurgence in popularity. The wordlean was originally popularized in the early 1990s to characterize the Japaneseapproach to automobile manufacturing.1 In recent years, Honda and Toyotahave been doing increasingly well in the North American auto market, whileDetroit automakers are restructuring. For example, Toyota’s profits rose frommore than $8 billion in the fiscal year ending March 31, 2003, to more than$10 billion in 2004, $11 billion in 2005, and $12 billion in 2006. Many com-

1. James Womack, Daniel Jones, and Daniel Roos, The Machine That Changed the World, Rawson Associates, 1990.

xxiv PREFACE

panies have taken a second look at lean to try to understand what’s behind suchsteady and sustained success.

Lean initiatives seldom start in the software development or product devel-opment area of a company, but over time, successful lean initiatives make theirway from manufacturing or logistics to development departments. However,lean practices from manufacturing and other operational areas do not adapteasily to a development environment, so lean initiatives have a tendency to stallwhen they reach software development. While the underlying lean principlesremain valid, it is usually inappropriate to apply operational practices and mea-surements to a development environment. When lean initiatives stall in soft-ware development areas, many companies have discovered that the book LeanSoftware Development gives them a good foundation for thinking about howto modify their approach and adapt lean ideas to a development organization.

The benefits of lean and agile software development have become widelyknown and appreciated in the last few years, and many organizations arechanging the way they develop software. We have traveled around the worldvisiting organizations as they implement these new approaches, and we havelearned a lot from our interaction with people working hard to change the waythey develop software. As our knowledge has grown, so has the demand formore information on implementing lean software development. We realizedthat a new book would allow us to share what we’ve learned with many morepeople than we can contact personally. Therefore we have summarized ourexperiences in this book, Implementing Lean Software Development: FromConcept to Cash.

This book is not a cookbook for implementing lean software development.Like our last book, it is a set of thinking tools about how to go about adaptinglean principles to your world. We start this book where the last book left offand go deeper into the issues and problems that people encounter when tryingto implement lean and agile software development. You might consider thisbook a sequel to Lean Software Development. Instead of repeating what is inthat book, we take a different perspective. We assume the reader is convincedthat lean software development is a good idea, and focus on the essential ele-ments of a successful implementation. We look at key aspects of implementa-tion and discuss what is important, what isn’t, and why. Our objective is to helporganizations get started down the path toward more effective software devel-opment.

The first chapter of this book reviews the history of lean, and the secondchapter reviews the seven principles of lean software development presented inLean Software Development. These are followed by chapters on value, waste,speed, people, knowledge, quality, partners, and the journey ahead. Each of

ACKNOWLEDGMENTS xxv

these eight chapters begins with a story that illustrates how one organizationdealt with the issue at hand. This is followed by a discussion of key topics wehave found to be important, along with short stories that illustrate the topic,and answers to typical questions we often hear. Each chapter ends with a set ofexercises that helps you explore the topics more deeply.

Acknowledgments

We would like to thank everyone who has attended our talks and classes andinvited us into their companies, especially those who have shared experiencesand asked penetrating questions. In this book we share the knowledge that wehave gained from all of you.

Many thanks to Jeff Sutherland and Kent Beck for their kind forewords, andthanks to our editor, Greg Doench, project editor, Tyrrell Albaugh, and espe-cially our copy editor, Nancy Hendryx. Particular thanks goes to those whohave contributed ideas and stories to the book: Jill Aden, Brad Appleton, RalphBohnet, Mike Cohn, Bent Jensen, Brian Marick, Clare Crawford-Mason, RyanMartens, Gerard Meszaros, Lynn Miller, Kent Schnaith, Ian Shimmings, JoelSpolsky, Jeff Sutherland, Nancy Van Schooenderwoert, Bill Wake, Werner Wild,and our friend and operations manager, who prefers to remain anonymous.

We thank everyone who read the first draft and contributed suggestions, par-ticularly Glen Alleman, Brad Appleton, Daniel Brolund, Bob Corrick, AllanKelly, Kent Schnaith, Dave Simpson, Alan Shalloway, and Willem van denEnde. We thank reviewers Yi Lv, Roman Pichler, Bill Wake, and especially BasVodde for his extensive and insightful comments. A particularly heartfeltthanks goes to Mike Cohn, who reviewed both drafts of the book, keeping upwith us under a tight deadline while he was very busy. His comments and sug-gestions have truly helped make this a better book.

—Mary and Tom PoppendieckJuly 2006

This page intentionally left blank

1

Chapter 1

History

Interchangeable Parts

Paris, France, July 1785. It was 18 months after the end of the RevolutionaryWar in America, and four years before the start of the French Revolution. Theneed for weapons was on everyone’s mind when Honoré Blanc invited high-ranking military men and diplomats to his gunsmith shop in Paris. He hadtaken apart 50 firing mechanisms (called “locks”) and placed the pieces inboxes. The astonished visitors took random parts from the bins, assembledthem into locks, and added them to muskets. They found that the parts fittogether perfectly. For the first time it seemed possible to make guns out ofinterchangeable parts.

Thomas Jefferson, a diplomat in Paris at the time, was at the demonstration.The future United States president saw a way to address a big problem in hisfledgling country. The United States was facing a shortage of weapons to defenditself and expand its boundaries. If interchangeable parts could be easily pro-duced, then relatively unskilled workers could assemble a lot of guns at lowcost, a real boon to the start-up country that had neither the money to buy gunsnor the craftsmen to make them.

The challenge of creating a manufacturing process precise enough to makeinterchangeable parts for guns was taken up by Eli Whitney, who had recentlypatented the cotton gin. In 1798 Whitney was awarded a government contractto make 10,000 guns in two years. Ten years and several cost overruns later hefinally delivered the guns, and even then the parts were not fully interchange-able. Nevertheless, Whitney is considered a central figure in developing the“American system of manufacture,” a manufacturing system in which semi-skilled workers use machine tools and precise jigs to make standardized partsthat are then assembled into products.

During the 1800s the United States grew dramatically as an industrial power,with much of the credit given to the new manufacturing system. Meanwhile inEurope there was strong resistance to replacing craft production. In France,

2 CHAPTER 1 HISTORY

Honoré Blanc’s work was terminated by a government that feared losing itscontrol over manufacturing if unregulated workers could assemble a musket. InEngland, the inventors of machines that automated both spinning and weavingwere attacked by angry crowds who feared losing their jobs. But in America,labor was scarce and there were few craft traditions, so the new industrialmodel of interchangeable parts took root and flourished.

Interchangeable People

Detroit, USA, January 1914. Henry Ford raised wages of workers from $2.40for a nine-hour day to $5 for an eight-hour day as he began assembly line pro-duction of the Model T. The press suggested that he was crazy, but it was ashrewd move. Ford had taken more than 85 percent of the labor out of a car, sohe could well afford to double wages. He had already dropped the price of thecar dramatically. Now he drove up wages and shortened work hours to helpcreate a middle class with the time and money to buy automobiles.

It used to take more than 12 hours to assemble an automobile; now it tookabout 90 minutes. What happened to all of the time? Ford managers appliedthe ideas of efficiency expert Frederick Winslow Taylor as they designed theproduction line jobs. Taylor believed that most fixed wage workers spent theirtime trying to figure out how to work slowly, since being efficient brought noextra pay and could threaten jobs. His approach was to divide the assembly linework into very small steps, and time the workers to uncover the “one best way”to do each step.

Work on the assembly line was boring, repetitive, and tightly controlled. Theworkers were shown exactly how to do their job and told how much time theyhad to complete it. They could be trained in ten minutes, and they could bereplaced in ten minutes. Like the interchangeable parts of a century earlier,interchangeable workers were at the center of a new industrial model: massproduction.

High wages were supposed to make up for the lack of variety and autonomy,and for a while they did. And for a while, things went very well for Ford. Salessoared, and Ford owned the market. But after a while the Model T grew oldand an increasingly prosperous middle class wanted to trade in their old carsfor more stylish sedans. Ford was slow to respond, because his production sys-tem was most efficient when making only one kind of car. Meanwhile at Gen-eral Motors, Alfred P. Sloan had created an organization structured to producemultiple models aimed at segmented markets. As the demand for variety andcomplexity grew, Ford’s production system grew unwieldy.

THE TOYODAS 3

Also as time passed workers began to feel trapped in untenable working con-ditions. They had become accustomed to a high standard of living and wereunable to find comparable salaries elsewhere. The widespread labor unrest inthe United States in the 1930s is often attributed to a system which held littlerespect for workers and regarded them as interchangeable.

The Toyodas

Kariya, Japan, February 1927. Toyoda Automatic Loom Works held a work-shop for textile engineers to showcase the company’s new loom. First the visi-tors saw how Toyoda looms were manufactured with high precision tools, andthen they were taken on a tour of the experimental spinning and weaving facil-ity where 520 of the Toyoda looms were in operation. The looms were a won-der to behold; they ran at a blazingly fast 240 picks per minute and wereoperated by only 20 weavers. Anticipating a law abolishing nighttime labor, themachines were fully automatic and could run unattended all night. When ashuttle flying across the loom was just about out of thread, a new shuttlereplaced it in a smooth, reliable exchange. If even one of the hundreds of warpthreads broke or the weft thread ran out, the loom immediately stopped andsignaled a weaver to fix the problem.

If you want to understand the Toyota1 Production System, it is important toappreciate just how difficult it was to develop and manufacture the “perfectloom.” Sakichi Toyoda built his first power loom in 1896 and invented an auto-mated shuttle changing device in 1903. A test was set up to compare 50 Toyodashuttle changing looms with a similar number of simple power looms fromEurope. The results were disappointing. These early Toyoda looms were com-plex, low precision machines that were balky and difficult to maintain.

Sakichi Toyoda recruited technically competent employees and hired an Ameri-can engineer, Charles A. Francis, to bring the American system of manufacture tohis company. Francis redesigned the manufacturing equipment and built amachine tool shop to produce it. He developed standard specifications, producedstandardized gauges and jigs, and reorganized the manufacturing line. At the sametime, Sakichi Toyoda designed wider all-iron looms, and by 1909 he had patenteda superior automated shuttle-change mechanism. Over the next decade, as wardistracted Europe and America, looms designed by Sakichi Toyoda sold very well.

1. The “d” in the Toyoda family name was changed to a “t” when the Toyota Motor Company was established. The Japanese characters are similar, but Toyota takes two less brush strokes than Toyoda.

4 CHAPTER 1 HISTORY

Although Sakichi Toyoda readily adopted high precision interchangeableparts, the loom manufacturing business had no room for interchangeable peo-ple. Automatic looms are complex, high precision machines, very sensitive tochanges in materials and a challenge to keep running smoothly. Thus, highlyskilled weavers were needed to set up and keep 25 or 30 machines running atonce. If running a loom required skill, the design and manufacture of auto-mated looms was even more demanding. Sakichi Toyoda had a reputation forhiring some of the most capable engineers being trained at Japanese universi-ties. He kept his development team intact even as he started new companies,and he depended on them to carry on research in loom design and manufacture.

In 1921 Sakichi Toyoda’s son Kiichiro joined his father’s company andfocused on advancing loom automation. In 1924 they jointly filed a patent foran improved automatic shuttle-change mechanism. The research team alsodeveloped methods to detect problems and stop the loom, so that looms couldrun unattended at night. Kiichiro Toyoda oversaw the building and start-up ofa factory to produce the new looms, and set up 520 of them in the Toyodaexperimental weaving factory. After he proudly showed off these “perfectlooms,” orders for the automated looms poured in. Kiichiro used the profits tostart up an automotive business. He toured Detroit and spent years learninghow to build engines. Toyota’s first production car hit the market in 1936, butmanufacturing was soon interrupted by war.

The Toyota Production System

Koromo, Japan, October 1949. Passenger car production restrictions werelifted in post-war Japan. In 1945, Kiichiro Toyoda had challenged his companyto “catch up with America,” but it was clear that Toyota could not catch up byadopting America’s mass production model. Mass production meant makingthousands of identical parts to gain economies of scale, but materials werescarce, orders were spotty, and variety was in demand. Economies of scale weresimply not available.

Kiichiro Toyoda’s vision was that all parts for assembly should arrive at theassembly line “Just-in-Time” for their use. This was not to be accomplished bywarehousing parts; parts should be made just before they are needed. It tooktime to make this vision a reality, but in 1962, a decade after Kiichiro Toyoda’sdeath, his company adopted the Toyota Production System companywide.

THE TOYOTA PRODUCTION SYSTEM 5

Taiichi Ohno

Taiichi Ohno was a machine shop manager who responded to Kiichiro Toyoda’schallenge and vision by developing what came to be known as the Toyota Pro-duction System. He studied Ford’s production system and gained insight from theway American supermarkets handled inventory. To this he added his knowledgeof spinning and weaving and the insights of the workers he supervised. It tookyears of experimentation to gradually develop the Toyota Production System, aprocess that Ohno considered never-ending. He spread the ideas across the com-pany as he was given increasingly broad areas of responsibility.

In his book, Toyota Production System, 2 Ohno calls the Toyota ProductionSystem “a system for the absolute elimination of waste.” He explains that the sys-tem rests on two pillars: Just-in-Time flow and autonomation (also called Jidoka).

Just-in-Time Flow

It is important to note that Just-in-Time flow went completely against all con-ventional wisdom of the time. Resistance to Ohno’s efforts was tremendous,and he succeeded because he was backed by Eiji Toyoda, who held varioussenior management positions in the company after his cousin Kiichiro left in1950. Both Toyodas had brilliantly perceived that the game to be played wasnot economies of scale, but conquering complexity. Economies of scale willreduce costs about 15 percent to 25 percent per unit when volume doubles. Butcosts go up by 20 percent to 35 percent every time variety doubles.3 Just-in-Time flow drives out major contributors to the cost of variety. In fact, it is theonly industrial model we have that effectively manages complexity. 4

Autonomation (Jidoka)

Toyoda automated looms could operate without weavers present because thelooms detected when anything went wrong and shut down automatically.Autonomation, or its Japanese name Jidoka, means that work is organized sothat the slightest abnormality is immediately detected, work stops, and thecause of the problem is remedied before work resumes. Another name for thiscritical concept, and one that is perhaps easier to remember, is “stop-the-line.”

2. This section is based on Taiichi Ohno’s book, Toyota Production System: Beyond Large-Scale Production, Productivity Press, written in Japanese in 1978 and trans-lated into English in 1988. It is an excellent book, very readable and highly recom-mended even today.

3. George Stalk, “Time—The Next Source of Competitive Advantage,” Harvard Busi-ness Review, July 1988.

4. See “Lean or Six Sigma,” by Freddy Balle and Michael Balle, available at www.lean.org/library/leanorsigma.pdf.

6 CHAPTER 1 HISTORY

Ohno called autonomation “automation with a human touch.” He pointedout how the related word “autonomic” brings to mind another way to look atthis concept. Our bodies have an autonomic nervous system that governsreflexes such as breathing, heartbeat, and digestion. If we touch something hot,our autonomic nerves cause us to withdraw our hand without waiting for thebrain to send a message. Autonomation means the organization has reflexes inplace that will respond instantly and correctly to events without having to go tothe brain for instructions.5

Shigeo Shingo

Shigeo Shingo was a consultant who helped Ohno implement the Toyota Pro-duction System at Toyota, and later helped companies around the world under-stand and implement the system. Those of us who implemented Just-in-Timemanufacturing in the early ’80s fondly remember the “Green Book,”6 the firstbook on Just-in-Time published in English. It was not a good translation, andthe material is heavy and technical, but it is a stunningly insightful book.

Shingo covers two major themes in the book: nonstock production and zeroinspection. A careful look shows that these are actually the engineering equiva-lent of Ohno’s pillars of the Toyota Production System.

Nonstock Production

Just-in-Time flow means eliminating the stockpiles of in-process inventory thatused to be made in the name of economies of scale. The focus is on makingeverything in small batches, and in order to do this, it is necessary to be able tochangeover a machine from making one part to making a different part veryquickly. In software development, one way to look at set-up time is to considerthe time it takes to deploy software. Some organizations take weeks andmonths to deploy new software, and because of this they put as many featuresinto a release as possible. This gives them a large batch of testing, training, andintegration work to do for each release. On the other hand, I expect the antivi-rus software on my computer to be updated with a well-tested release withinhours after a new threat is discovered. The change will be small, so integrationand training are generally not a concern.

Zero Inspection

The idea behind autonomation is that a system must be designed to be mistake-proof. There should not be someone looking for a machine to break or testing

5. Taiichi Ohno, Ibid., p. 46.6. Shigeo Shingo, Study of ‘Toyota’ Production System, Productivity Press, 1981.

JUST-IN-TIME 7

product to see if it is good. A properly mistake-proofed system will not needinspection. My video cable is an example of mistake-proofing. I can’t plug amonitor cable into a computer or video projector upside down because thecable and plug are keyed. So I don’t need someone to inspect that I plugged thecable in correctly, because it’s impossible to get it wrong. Mistake-proofingassumes that any mistake that can be made will eventually be made, so take thetime at the start to make the mistake impossible.

Just-in-Time

The Toyota Production System was largely ignored, even in Japan, until the oilcrisis of 1973, because companies were growing quickly and they could selleverything they made. But the economic slowdown triggered by the oil crisissorted out excellent companies from mediocre ones, and Toyota emerged fromthe crisis quickly. The Toyota Production System was studied by other Japanesecompanies and many of its features were adopted. Within a decade Americaand Europe began to feel serious competition from Japan. For example, I(Mary) was working in a video cassette plant in the early ’80s when Japanesecompetitors entered the market with dramatically low pricing. Investigationshowed that the Japanese companies were using a new approach called Just-in-Time, so my plant studied and adopted Just-in-Time to remain competitive.

The picture that we used at our plant to depict Just-in-Time manufacturing isshown in Figure 1.1.

Figure 1.1 Lower inventory to surface problems

8 CHAPTER 1 HISTORY

Inventory is the water level in a stream, and when the water level is high, alot of big rocks lurking under the water are hidden. If you lower the water level,the big rocks begin to surface. At that point, you have to clear the rock out ofthe way, or your boat will crash into them. As the big rocks are removed, youcan lower inventory level some more, find more rocks, clear them out of thestream, and keep on going until there are just pebbles left.

Why not just keep the inventory high and ignore the rocks? Well, the rocksare things like defects that creep into the product without being detected, pro-cesses that drift out of control, finished goods that people aren’t going to buybefore the shelf life expires, an inventory tracking system that keeps on losingtrack of inventory—things like that. The rocks are hidden waste that is costingyou a lot of money—you just don’t know it unless you lower the inventorylevel.

A key lesson from our Just-in-Time initiative was that we had to stop tryingto maximize local efficiencies. We had a lot of expensive machines, so wethought we should run them each at maximum productivity. But that onlyincreased our inventory, because a pile of inventory built up at the input to eachmachine to keep it running, and at the output from each machine as it merrilyproduced product that had nowhere to go. When we implemented Just-in-Time,the piles of inventory disappeared, and we were surprised to discover that theoverall performance of the plant actually increased when we did not try to runour machines at maximum utilization (see Figure 1.2).

Figure 1.2 Stop trying to maximize local efficiencies.

JUST-IN-TIME 9

Stop-the-Line and Safety Consciousness One Just-in-Time practice that was easy to adopt was a stop-the-line culture.Our video tape plant made tape out of some rather volatile materials, so we hadan aggressive safety program in place. Through our safety program we alreadyknew that it was important to investigate even the smallest accident, becausesmall accidents will eventually turn into big accidents if they are ignored.

The book Managing the Unexpected 7 by Weick and Sutcliffe shows thatorganizations like our plant create an environment where people payattention to safety by maintaining a state of mindfulness. According to theauthors, mindfulness has five characteristics:

1. Preoccupation with FailureWe spent a lot of time thinking about what could go wrong and beingprepared.

2. Reluctance to SimplifyWe had a large, complex plant, so safety was a large, complex issue.

3. Sensitivity to OperationsEvery manager in the plant was expected to spend time working on theline.

4. Commitment to Learn from MistakesEven the smallest incident was investigated to determine how to prevent itfrom ever happening again.

5. Deference to ExpertiseEvery manager knew that the people doing the work were the ones whoreally understood how the plant worked.

It was a small step to turn our safety culture into a stop-the-line culture. Weadded to our preoccupation with accidents a preoccupation with defects.Every step of every operation was mistake-proofed as we focused oneliminating the need for after-the-fact inspection. Whenever a defectoccurred, the work team stopped producing product and looked for the rootcause of the problem. If defective material made it through a processundetected, we studied the process to find out how to keep that fromhappening again. When I say “we” I refer to our production workers, becausethey were the ones who designed the process in the first place.

—Mary Poppendieck

7. Karl E. Weick and Kathleen M. Sutcliffe, Managing the Unexpected: Assuring High Performance in an Age of Complexity, Jossey-Bass, 2001.

10 CHAPTER 1 HISTORY

Figure 1.3 Coffee cups simulating inventory carts with kanban cards

When we decided to move our plant to Just-in-Time, there were few consult-ants around to tell us what to do, so we had to figure it out ourselves. We cre-ated a simulation by covering a huge conference table with a big sheet of brownpaper, then drawing the plant processes on the paper. We made “kanban cards”by writing various inventory types on strips cut from index cards. We put aninventory strip into a coffee cup and—viola!—that cup became a cart full of theindicated inventory. (See Figure 1.3.) Then we printed a week’s packing ordersand simulated a pull system by attempting to fill the orders, using the cups andthe big sheet of paper like a game board. When a cup of inventory was packed,the inventory strip (kanban card) was moved to the previous process, whichused it as a signal to make more of that material.8

With this manual simulation we showed the concept of a pull system to theproduction managers, then the general supervisors, then the shift supervisors.Finally, the shift supervisors ran through the simulation with every worker intheir area. Each work area was asked to figure out the details of how to makethis new pull system work in their environment. It took some months ofdetailed preparation, but finally everything was ready. We held our collectivebreath as we changed the whole plant over to a pull system in one weekend.Computerized scheduling was turned off, its place taken by manual scheduling

8. This scheduling approach is called Kanban, and the token showing what each pro-cess should make is called a kanban card.

Asd

lkjp

123

a

Asd

lkjp

123

a

qr3c

d 12

3a

Po

d63

123a

Asd

lkjp

123

a

Po

d63

123a

q r3 c

d 1 2

3 a

LEAN 11

via kanban cards. Our Just-in-Time system was an immediate and smashingsuccess, largely because the details were designed by the workers, who thereforeknew how to iron out the small glitches and continually improve the process.

Lean

In 1990 the book The Machine That Changed the World 9 gave a new name towhat had previously been called Just-in-Time or the Toyota Production System.From then on, Toyota’s approach to manufacturing would become known asLean Production. During the next few years, many companies attempted toadopt Lean Production, but it proved remarkably difficult. Like all new indus-trial models, resistance from those invested in the old model was fierce.

Many people found Lean counterintuitive and lacked a deep motivation tochange long established habits. Quite often companies implemented only partof the system, perhaps trying Just-in-Time without its partner, stop-the-line.They missed the point that, “The truly lean plant…transfers the maximumnumber of tasks and responsibilities to those workers actually adding value tothe car on the line, and it has in place a system for detecting defects that quicklytraces every problem, once discovered, to its ultimate source.”10

Despite the challenges faced when implementing a counterintuitive new para-digm, many lean initiatives have been immensely successful, creating truly leanbusinesses, which have invariably flourished. Lean thinking has moved from man-ufacturing to other operational areas as diverse as order processing, retail sales,and aircraft maintenance. Lean principles have also been extended to the supplychain, to product development, and to software development. See Figure 1.4.

Lean Manufacturing/Lean Operations

Today lean manufacturing sets the standard for discipline, efficiency, and effec-tiveness. In fact, using lean principles in manufacturing often creates a signifi-cant competitive advantage that can be surprisingly difficult to copy. Forexample, Dell Computer’s make-to-order system routinely delivers a “custom-built” computer in a few days, a feat which is not easily copied by competitorsunwilling to give up their distribution systems. Lean has moved into nonmanu-facturing operations as well. Southwest Airlines focuses on transporting custom-

9. James Womack, Daniel Jones, and Daniel Roos, The Machine That Changed the World, Rawson Associates, 1990.

10. Ibid., p. 99. Italics are from original text.

12 CHAPTER 1 HISTORY

ers directly from point A to point B in relatively small planes, while competitorscan’t easily abandon their large-batch oriented hub-and-spoke systems. A fewindustries, such as rapid package delivery, have been structured based on leanprinciples, and in those industries, only companies with lean operations cansurvive.

Lean Supply Chain

When lean production practices reach the plant walls, they have to be extendedto suppliers, because mass production and lean manufacturing do not workwell together. Toyota realized this early, and helped its suppliers adopt the Toy-ota Production System. Peter Drucker estimated that Toyota’s supplier network,which Drucker calls a Keiretsu, gives it a 25 percent to 30 percent cost advan-tage relative to its peers.11 When Toyota moved to the United States in the late1980s, it established a similar supplier network. Remarkably, US automotivesuppliers often have lean sections of their plants dedicated to supplying Toyota,while the rest of the plant has to be run the “traditional” way because otherautomotive companies cannot deal with a lean supplier.12 A lean supply chain is

11. Peter Drucker, Management Challenges for the 21st Century, Harper Business, 2001, p. 33.

12. See Jeffrey Dyer, Collaborative Advantage: Winning Through Extended Enterprise Supplier Networks, Oxford University Press, 2000.

Lean

Manufacturing

ToyotaProduction

System

SupplyChain

(Virtual Integration)

Keiretsu

ProductDevelopment

SoftwareDevelopment

ToyotaProduct Development

System

Operations

Figure 1.4 The lean family tree

LEAN 13

also essential to Dell, since it assembles parts designed and manufactured byother companies. Through “virtual integration,” Dell treats its partners as ifthey are inside the company, exchanging information freely so that the entiresupply chain can remain lean.

In lean supply chains, companies have learned how to work across companyboundaries in a seamless manner, and individual companies understand thattheir best interests are aligned with the best interests of the entire supply chain.For organizations involved in developing software across company boundaries,supply chain management provides a well-tested model of how separate compa-nies might formulate and administer lean contractual relationships.

Lean Product Development

“The real differential between Toyota and other vehicle manufacturers is notthe Toyota Production System. It’s the Toyota Product Development System,”says Kosaku Yamada, chief engineer for the Lexus ES 300.13 Product develop-ment is quite different than operations, and techniques that are successful inoperations are often inappropriate for development work. Yet the landmarkbook Product Development Performance14 by Clark and Fujimoto shows thateffective product development has much in common with lean manufacturing.Table 1.1 summarizes the similarities described by Clark and Fujimoto.

If any company can extract the essence of the Toyota Production System andproperly apply it to product development, Toyota would be the top candidate. Sothere was no surprise when it became apparent in the late 1990s that Toyota hasa unique and highly successful approach to product development. Toyota’sapproach is both counterintuitive and insightful. There is little attempt to use themanufacturing-specific practices of the Toyota Production System in productdevelopment, but the underlying principles clearly come from the same heritage.

The product coming out of a development process can be brilliant or mun-dane. It might have an elegant design and hit the market exactly right, or itmight fall short of both customer and revenue expectations. Toyota productstend to routinely fall in the first category. Observers attribute this to the leader-ship of a chief engineer, responsible for the business success of the product, whohas both a keen grasp of what the market will value and the technical capability

13. Gary S. Vasilash, “Engaging the ES 300,” Automotive Design and Production, Sep-tember, 2001.

14. Kim B. Clark and Takahiro Fujimoto, Product Development Performance: Strategy, Organization, and Management in the World Auto Industry, Harvard Business School Press, 1991.

14 CHAPTER 1 HISTORY

Table 1.1 Similarities between Lean Manufacturing and Effective Product Development15

to oversee the systems design. In the book The Toyota Way,16 Jeffrey Likerrecounts the stories of the development of the Lexus and the Prius, emphasizinghow these breakthrough designs were brought to market in record time underthe leadership of two brilliant chief engineers.

Product development is a knowledge creation process. Toyota’s ProductDevelopment System creates knowledge through broad exploration of designspaces, hands-on experimentation with multiple prototypes, and regular inte-

Lean Manufacturing Lean Development

Frequent set-up changes Frequent product changes (software releases)

Short manufacturing throughput time

Short development time

Reduced work-in-process inventory between manufacturing steps

Reduced information inventory between development steps

Frequent transfer of small batches of parts between manufacturing steps

Frequent transfer of preliminary infor-mation between development steps

Reduced inventory requires slack resources and more information flow between steps

Reduced development time requires slack resources and information flow between stages

Adaptability to changes in volume, product mix, and product design

Adaptability to changes in product design, schedule, and cost targets

Broad task assignments for produc-tion workers gives higher productivity

Broad task assignments for engineers (developers) gives higher productivity

Focus on quick problem solving and continuous process improvement

Focus on frequent incremental innova-tion and continuous product and pro-cess improvement

Simultaneous improvement in qual-ity, delivery time, and manufacturing productivity

Simultaneous improvement in quality, development time, and development productivity

15. Adapted from Kim B. Clark and Takahiro Fujimoto, Product Development Perfor-mance, p. 172.

16. Jeffrey Liker, The Toyota Way: 14 Management Principles from the World’s Great-est Manufacturer, McGraw Hill, 2004.

LEAN 15

gration meetings at which the emerging design is evaluated and decisions aremade based on as much detailed information as possible. The tacit knowledgegained during both development and production is condensed into concise anduseful one-page summaries that effectively make the knowledge explicit. Gener-ating and preserving knowledge for future use is the hallmark of the ToyotaProduct Development System.

The National Center for Manufacturing Sciences (NCMS) conducted a multi-year study of the Toyota Product Development System, and the findings aresummarized by Michael Kennedy in the book Product Development for theLean Enterprise.17 In this book Kennedy identifies four cornerstone elements ofthe Toyota Product Development System (see Figure 1.5).

Figure 1.5 Cornerstone elements of the Toyota Product Development System18

17. Michael Kennedy, Product Development for the Lean Enterprise: Why Toyota’s System Is Four Times More Productive and How You Can Implement It, Oaklea Press, 2003.

18. This figure is from Michael Kennedy, Ibid., p. 120. Used with permission.

Knowledge-Based Engineering(The Lean Development System)

OperationalValue Streamto Customer

ExpertEngineeringWorkforce

Responsibility-Based Planning &

Control

System DesignerEntrepreneurial

Leadership

Set-BasedConcurrentEngineering

An operational value stream emerges from theinteraction of four cornerstone elements.

16 CHAPTER 1 HISTORY

19. For more on set-based engineering, see Chapter 7.

The Toyota Product Development System

The Toyota Product Development System has four cornerstone elements:

1. System Design by an Entrepreneurial LeaderThe chief engineer at Toyota owns responsibility for the business success ofthe product. He is a very experienced engineer, fully capable of creating thesystem-level design of the vehicle. But he is also responsible for developinga deep understanding of the target market and creating a vehicle that willdelight the customers. The chief engineer creates a vision of the new prod-uct which he transmits to the development team and refreshes frequently bytalking to the engineers making day-to-day decisions. He defends the visionwhen necessary and arbitrates tradeoffs if disagreements arise. He sets theschedule and modifies the process so everything is pulled together on time.

2. Expert Engineering WorkforceFrom the days of Sakichi Toyoda, the Toyoda and Toyota companies havealways had top notch technical people designing their technically sophisticatedproducts. It takes years for an engineer to really become an expert in a partic-ular area, and at Toyota, engineers are not moved around or motivated tomove into management before they truly master their field. Managers areteachers who have become masters in the area they supervise; they train newengineers and move them from apprentice to journeyman to master engineer.

3. Responsibility-Based Planning and ControlThe chief engineer sets the vehicle development schedule, which consistsof key synchronization points about two or three months apart. Engineersknow what is expected at the next synchronization point, and they deliverthe expected results without being tracked. If engineers need information todo their job, they are expected to “pull” it from its source. Recently, Toyotachief engineers have pioneered the practice of an “Oobeya” or large roomwhere team members may work, and the whole team meets regularly. TheOobeya contains big visible charts to show issues and status.

4. Set-Based Concurrent EngineeringSet-based engineering means exploring multiple design spaces and con-verging on an optimal solution by gradually narrowing options. What doesthis mean in practice? It means being very careful not to make decisionsuntil they absolutely must be made and working hard to maintain options sothat decisions can be made as late as possible with the most amount ofinformation possible. The paradox of set-based design is that this approachto creating knowledge builds redundancy into the development approach,which might appear to be a waste. However, when looking at the whole sys-tem, set-based design allows the development team to arrive at a more opti-mal solution much faster than an approach that closes off options quickly forthe sake of being “decisive.”19

TRY THIS 17

Lean Software Development

Software development is a form of product development. In fact, much of thesoftware you use was probably purchased as a product. Software that is notdeveloped as a standalone product may be embedded in hardware, or it may bethe essence of a game or a search capability. Some software, including muchcustom software, is developed as part of a business process. Customers don’tbuy the software we develop. They buy games or word processors or searchcapability or a hardware device or a business process. In this sense, most usefulsoftware is embedded in something larger than its code base.

It is the product, the activity, or the process in which software is embeddedthat is the real product under development. The software development is just asubset of the overall product development process. So in a very real sense, wecan call software development a subset of product development. And thus, ifwe want to understand lean software development, we would do well to dis-cover what constitutes excellent product development.

The Toyota Production System and the Toyota Product Development Systemstem from the same underlying principles. The first step in implementing leansoftware development is to understand these underlying principles, which willbe discussed in the next chapter.

Try This19

1. Go to the Toyota Web site, and view the videos on Jidoka (www.toy-ota.co.jp/en/vision/production_system/video.html20). The videos on Just-in-Time and the Toyota Production System are also worth viewing.

2. Do you have a tendency to work in batches? If you had to mail 100 letters,how would you go about folding the letters, stuffing the envelopes, addingaddress labels and stamps? Would you process one envelope at a time, orwould you perform each step in a batch? Why? Try timing both ways andsee which is faster. If you have children, ask them how they wouldapproach the problem.

19.

20. This was a newly published Web site as of April, 2006. The page can also be reached by going to www.toyota.co.jp/en/ and following this sequence: Top Page > Company > Vision & Philosophy > Toyota Production System > Video Introducing the Toyota Production System.

18 CHAPTER 1 HISTORY

3. Table 1.1 lists similarities between manufacturing and product develop-ment. Discuss this table with your team, one line at a time. Does it makesense in your world to think of partially done work as inventory? Do theother analogies make sense? Analogies are a double-edged sword. Wheremight the analogies between manufacturing and product development leadyou astray?

4. Work-arounds: You have an organization of intelligent people. Do thesepeople make it their job to work around problems, or are problems consid-ered a trigger to stop-the-line and find the root cause? Make a list of theTop 10 problems that occurred in your group in the last week. List aftereach problem the way it was resolved. Rank each problem on a scale of 0–5. The rank of 5 means that you are confident that the cause of the problemhas been identified and eliminated and it is unlikely to occur again. Therank of 0 means that there is no doubt the problem will crop up again.What is your total score?

5. If people in your organization instinctively work around problems, theyhave the wrong reflexes! Brainstorm what it will take to develop a culturethat does not tolerate abnormalities, whether it is a broken build or a mis-communication, a failed installation or code that is not robust enough tohold up in production. Have a “stop-the-line” committee investigate theideas and choose the best candidate to get started. In the one chosen area,switch from a work-around culture to a stop-the-line culture. Be surereflexive stop-the-line habits are developed! Repeat.

This page intentionally left blank

257

3D modeling, 1183M

example, 213–214feasibility stage, 47focus on the job, 52handspreads, 47samples of new products, 47

7 principles. See seven principles.7 wastes. See seven wastes.14 points of Deming, 122–12380/20 rule, 25–26

AA3 reports, 157–158acceptance tests, 150, 186. See also story

tests.accommodations, 233accountability, 64–65Aden, Jill, 195adopting new technologies, 230–231agile software development, tools for. See

Rally.Airline Information Management System,

119airport check-in desk example, 110airport delays, example, 136–137Aisin fire, 208–209, 211AJAX, 150Alias, 55alignment, 69allegiance, 214–216Allen, Charles, 234American auto industry, 2–3American System of Manufacture, 1analyzing the situation, 169andon, 139–140annual performance rating. See

performance evaluations.applause, 210Appleton, Brad, 202approval process, 84, 103architecture, software

definition, 20

divisible systems, 182feedback and quality, 182

assemble-to-order, 34assembly line. See mass production.assessment, 188–189asynchronous cadence, 109Austin, Rob, 40auto industry. See also specific industries.

America, 2–3Japan, 4–7used car sales, 41

Autodesk, 55automating complexity, 72–73automating routine tasks, 197–198, 227–

228, 231–232autonomation (Jidoka), 5–6availability of processes, 98

BBAA airport management, 217–218,

220–221backlog items, 185–186balanced scorecards, 144barriers

eliminating, 210interdepartmental, 122

batch and queue approach, 88Beck, Kent, xxBell, Gordon, 165bell curve, and individual performance,

130Bell Laboratories, 121Benneton, 67Beyond the Goal, 230big visible charts, 140billing system example, 167–168Black Belts, 229blame, 143Blanc, Honoré, 1–2Blenko, Marcia, 57BMI, 39BMI call center, outsourcing, 215Boehm, Barry, 33

Index

258 INDEX

Boeing777 project, 117–120, 140, 230787 Dreamliner, 210outsourcing, 216–217

Bohnet, Ralph, 167bonuses as incentives, 145, 146books and publications

Beyond the Goal, 230Cheaper by the Dozen, 37“Collaboration Rules,” 208Conquering Complexity in Your Business, 67“Do You Have Too Much IT?”, 69Estimating and Planning, 232–233Fit for Developing Software, 187Hidden Value, 146The Instructor, the Man and the Job, 234The Knowledge-Creating Company, 156Lean Software Development: An Agile

Toolkit, xxiiiLean Solutions, 43The Living Company, 141, 225The Machine That Changed the World, 11Managing the Unexpected, 9Product Development for the Lean

Enterprise, 15Product Development Performance, 13, 52“Quality With a Name,” 20Taxonomy of Problem Management

Activities, 20Toyota Production System, 5The Toyota Way, 14The Ultimate Question, 241“When IT’s Customers Are External,” 62–63Who has the D?, 57Working Effectively with Legacy Code, 167

bottleneck elimination, xixbottlenecks (Muri), xixboundaries, organizational

cascading queues, 113–114cost of crossing, 39–40, 243lean supply chains, 13relational contracts, 221teams, 214value streams, 84

boundaries, system, 201Brin, Sergey, 46building quality in, 25–29burn-down charts, 140business case, 240business intent, testing, 200business process, 17, 20, 181

business successconstraints, 153responsibility for, 13, 16, 53rewards for, 145

Ccadence

asynchronous, example, 109cycle time reduction, 108–109establishing, 108–109

Cagan, Martin, 53Canada, 231–232capable development process, 98capacity, limiting work to

cycle time reduction, 110–111teams, 134

cascading queues, 113–114cash stage, 49cause. See root causes.champions, 52–57, 133change

agents, 229management, 25scope bloat, 25scope control, 25tolerance, 182waste, 25

change for the better (Kaizen) events, 173–175change requests, 62chartering teams, 241charts, 140Cheaper by the Dozen, 37chief architect, 133chief engineer, 53–55Christensen, Clayton, 226Chrysler

NS minivan, 56QFD (quality function deployment) analysis,

56shared leadership, 56

churnrequirements, 24, 91test-and-fix, 24value streams, 91waste, 24

Clark, Kim B., 52Clark, Mike, 197ClearStream Consulting, 167–168Cleland-Huang, Jane, 182CMM, 124coaches, 133

INDEX 259

codecomplexity, 69source of waste, 74–75technical debt, 150undeployed, 75undocumented, 75unsynchronized, 74untested, 74

code reviews, 194–195coffee cup simulation, 10–11Cohn, Mike, 232collaboration. See partners; teams.“Collaboration Rules,” 208co-located teams, 211, 213commitment. See also Just-in-Time commitment.

to change, 151deferring, principle of, 32–33iterative development, 186planning as, 33

committers, 209–210companies

life expectancy, 225–227organizational boundaries

cascading queues, 113–114cost of crossing, 39–40, 243lean supply chains, 13relational contracts, 221teams, 214value streams, 84

purpose of, 123types of, 141

compensationalternatives to money, 145–146annual raises, 144balanced scorecards, 144bonuses, 145, 146promotion systems, 143–144reward basis, 144–145span of influence versus span of control, 144–

145competing on the basis of time, 34competitive advantage

complexity, 69customer satisfaction, 241development speed, 35expert workforce, 37feedback, 177lean principles, 11management innovation, 124outsourcing, 215–216Toyota, 224user interface, 189

complete teams, 57–60complexity

automating, 72–73competitive advantage, 69cost of, 69–70limiting features and functions, 70–71minimum useful feature sets, 71–72pricing structure, example, 72–73prioritizing features, 71–72root cause of waste, 67software code, 69

concept stage, 46concurrent development, 182concurrent engineering, 16condensing knowledge, 157configuration management, 201–202conflict of interest, 215conquering complexity, 5Conquering Complexity in Your Business, 67constraints, 230–233continuous improvement

cadence, 168complexity reduction, 166configuration management, 201Deming’s 14 points, 122development organization objectives, 239at PatientKeeper, 98principle of, 38waste elimination, 166

continuous integration, 202–203contractors, 218contracts

BAA airport management, 217–218, 220–221fixed price, 125Norwegian Computer Society, 218–219NTNU (Norwegian University of Science and

Technology), 218–219PS 2000, 218–219purpose of, 217relational, 219–221T5 Agreement, 217–218time and materials, 218

Cook, Scott, 51, 55costs

competing on the basis of time, 34complexity, 24–25, 69–70crossing organizational boundaries, 39–40,

243economies of scale, 5extra features, 24–25joint ventures, 220Keiretsu advantage, 12

260 INDEX

costs (continued):lifecycle, 20, 70–71refactoring, 166of software maintenance, 20–21standards, 193support and warranty, 164synergistic relationships, 221target, 180, 218–219, 221

counterintuitive conceptscontinuous integration, 202Lean, 11new paradigms, 11object orientation, 195set based development, 161seven principles, 23

Crawford-Mason, Clare, 125create knowledge, principle of, 29–32Critical Chain, 232–233cross-functional teams, 56, 64, 78, 122Cunningham, Ward, 187custom systems. See software development,

custom systems.customer-focused organizations

champions, 52–57chief engineer, 53–55complete teams, 57–60decision making, 57designing for manufacturability, 58–59designing for operations, 58–59development goal, 55facilitating information flow, 52–60leadership, 52–57leadership teams, 55Murphy’s Law, 59–60responsibility, 56–57shared leadership, 56What can go wrong, will go wrong, 59–60

customersdelighting, 49–52. See also Google.focus on the job, 51–52Kano model, 49–52needs, 43satisfaction, 49–52satisfaction, as competitive advantage, 241satisfaction, measurements, 241service, example, 111–112understanding, 50

cycle timemeasurements, 238–240PatientKeeper, 97–98reducing

establishing a cadence, 108–109

evening out work arrival, 103–105limiting work to capacity, 110–111minimizing process elements, 105–107minimizing process size, 107–108pull scheduling, 112–114

speed, 98–99utilization and, 102

DDarwin Information Typing Architecture

(DITA), 131dashboards, 136, 140–141de Geus, Arie, 141, 225decisions. See also commitment.

irreversible, 160key, 162making, 57

decomposition, optimizing by, 40–41defects

discovering versus preventing, 27, 82. See also test-driven development.

inspecting for, 27, 82as management problems, 29queues, 25–26rates, 27, 34, 81, 85seven wastes, 81–82tracking systems, 27

defer commitment, principle of, 32–33delays

mapping in value streams, 91seven wastes, 80–81

delighters, 65delighting customers, 49–52deliver fast, principle of, 34–35. See also speed.Dell Computer, 11–13Deming, W. Edwards

14 pointsoverview, 122–123point 12, 210points 6 and 7, 210

causes of problems, 121, 123–124choosing suppliers, 122, 123Deming Cycle, 121dependence on inspection, 122fear, 122inherent system variation, 121interdepartmental barriers, 122introduction, 120leadership, 122numerical quotas, 123PDCA (plan, do, check, act), 121, 154–155pride of workmanship, 123

INDEX 261

psychology, 122purpose of a company, 123scientific method, 121slogans, exhortations, and targets, 123synergy, 121System of Profound Knowledge, 121theory of knowledge, 121training, 122, 123

Deming Cycle, 121democracy principle, Google, 45Denne, Mark, 182dependencies, teams, 135deployment

available to production, 87, 90average time, 6, 86concept-to-launch time, 99, 103cycle time, 170, 238–239delays, 91incremental, 178–179minimum useful feature sets, 71obsolescence, 91Polaris project, 178–179QFD (quality function deployment) analysis,

56undeployed code, 75

designof code. See software development.intent, testing, 200for manufacturability, 58–59for operations, 58–59of products. See Toyota Product Development

System; Toyota Production System.Design for Six Sigma (DFSS), 229design/build teams, 118, 123, 133deskilling, 228deterministic school, 21detractor, 65, 241Detroit, 2, 4, 117developing software. See software development.development teams

3M, 56–60capacity, 99champions, 132DFSS (Design for Six Sigma), 229error prevention, 82expertise, 129–130, 212goal of, 240incentives, 123interaction designers, 189joined at the hip, 55maintenance duties, 79measurements, 237

pride in workmanship, 210process improvement, 31pull scheduling, 112–114rewards, 145set-based concurrent engineering, 16size, and technical debt, 153

DFSS (Design for Six Sigma), 229differentiation, 50discipline

automating routine tasks, 197–198code reviews, 194–195configuration management, 201–202continuous integration, 202–203five S’s, 190–192merging subsystems, 203–204mistake-proofing, 196–198nested synchronization, 203–204Open Source reviews, 196organizing a workspace, 190–192pairing, 195–196shine (seiso), 191–192sort (seiri), 191–192standardize (seiketsu), 191–192standards for software development, 193–196sustain (shitsuke), 191–192systematize (seiton), 191–192test-driven development, 198–201

dispatching, 137–138DITA (Darwin Information Typing

Architecture), 131divisible systems architecture, 182Do It Right the First Time, 165do it right the first time, 29“Do You Have Too Much IT?”, 69doctor’s appointments, example, 104–105documentation, 74, 77domain, 82, 180, 183domain models, 185–186Drucker, Peter, 12–13, 220–221dual ladder, 143dysfunctional measurements, 238

EEasel Corporation, xviieconomic companies, 141economies of scale, 4, 68education. See training.80/20 rule, 25–26eliminate waste, principle of, 23–25eliminating barriers, 210embedded software, 20, 163empirical school, 21

262 INDEX

employees. See partners; people; teams.engaged thinking people, 35, 37, 117, 237enterprise software, 20entrepreneurial leaders, 16, 37, 54ERP (Enterprise Resource Planning), 231estimates

as commitments, 232granular level, 134implementation effort, 185stories, 183tasks, 97

Estimating and Planning, 232–233Evans, Eric, 186Evans, Phillip, 208Excel, 36excellence principle, Google, 45exchanging tests, 212exhortations, 123exhortations as incentives, 123expediting projects, 98experimentation, 171–172expert technical workforce, 37expertise, in teams, 129–131exploratory tests, 201extra features, as waste, 24–25, 75

FFAA (Federal Aviation Administration), 119face-to-face discussion, 78fail fast, 118–119fast delivery. See deliver fast; speed.fear as incentive, 122feasibility stage, 46–47Feathers, Michael, 167features

limiting, 70–71, 165minimum useful sets, 71–72prioritizing, 71–72wastes, 24–25, 75YAGNI (You Aren’t Going to Need It), 165

FedEx, 34feedback, and quality

architecture, 182competitive advantage, 177iterative development, 183–190Polaris program, 177–182release planning, 179–181

financial results. See return on investment.fire, Aisin plant, 208–209, 211FIT (Framework for Integrated Tests), 75, 150,

187Fit for Developing Software, 187

Fitnesse, 150five S’s, 190–192fixed price contracts, 125fixtures, 187focus on the job, 51–52Ford, Henry, 2–3Ford Motor Company, 2–314 points of Deming, 122–123Fowler, Martin, 167framework for integrated tests. See FIT

(Framework for Integrated Tests).France, 1–2Francis, Charles A., 3frequent integration, 212Fujimoto, Takahiro, 52Fujitsu, 39funding profiles, 61future blindness, 226

Ggames, 17, 48, 181Gap, 68Gates, Bill, 36GE Workout, 173–175genchi-genbutsu (go, see, confirm), 54General Motors, 2–3George, Michael, 67Gilbreth, Frank, 37–38Gilbreth, Lillian, 37–38global networks, 210–214global teams, 212global work groups, 212goal setting, 223Goldratt, Eliyahu, 230, 232Google

corporate philosophy, 44customer satisfaction, 50democracy principle, 45excellence principle, 45history of, 43–44Keyhole, 45maps, 45page rank system, 48product development principles, 44–45product development timeline

cash stage, 49concept stage, 46feasibility stage, 46–47pilot stage, 48systems design stage, 47

queuing theory, 101–102speed principle, 45

INDEX 263

startup, 46–47value principle, 44workforce utilization, 101–102

Google Earth, 45Google Local, 45Green Book, 6

Hhack-a-thon, 152hacking versus speed, 35Hamel, Gary, 117, 124–125handoffs, 77–78hangers, theft of, 125hardening software, 150–151haste makes waste, 35Heathrow, 217help desk, BMI, 39help each other, 35, 127, 129, 183Hidden Value, 146history of lean software development

See Just-in-TimeSee mass productionSee Toyota Product Development SystemSee Toyota Production System

H&M, 67Honda, xxiii, 55Honeywell, 119–120HTTPUnit, 150hypothesis development, 171, 234–241

IIBM AT cables, 196–198incentives

applause, 210blame, 143individual performance, 142performance evaluations, 141–143rankings, 142–143

incremental development, dangers of, 164incremental funding, 61Inditex, 67, 69individual performance as incentives, 142industrial model, 2, 5, 11infrastructure, outsourcing, 214–215innovation

management, 124, 218start of, 46Web inspired, 233

inspectionsdependence on, 122

discovering defects, 27, 82. See also test-driven development.

preventing defects, 27, 82. See also test-driven development.

purpose of, 27types of, 27

The Instructor, the Man and the Job, 234integration

continuous, 202–203frequent, 212

interaction designers, 55, 130, 189interchangeable parts, 1–2interchangeable people, 2–3interdepartmental barriers, 122Internet age, and knowledge creation, 159intrinsic rewards, 146Intuit

complete teams, 57–58founding of, 51leadership teams, 55limiting complexity, 70QuickBooks, 70Quicken

introduction of, 51leadership teams, 55

Quicken Rental Property Management, 57–58

inventory. See also Just-in-Time.coffee cup simulation, 10–11pull system, 10–11rocks-and-stream metaphor, 7–8as waste, 24

irreversible decisions, 160ISO 9000, 124–125IT departments

accountability, 64–65business collaboration, 62–65cost, 68external customers, 62–63fixing, 64guide to the use of technology, 69versus software companies, 62–65we-they model, 63workload example, 103–104

iterative developmentassessment, 188–189commitment, 186example, 184feedback and quality, 183–190FIT (Framework for Integrated Tests), 187implementation, 186–188introduction, 183–184

264 INDEX

iterative development (continued):overview, 183planning, 186preparation, 185–186stories, 183–186story-test driven development, 186user interface variation, 189–190

JJapan. See also Toyota; Toyota Product

Development System; Toyota Production System.

auto industry, 4–7textile industry, 3–4

Java, five S’s, 192Jefferson, Thomas, 1Jensen, Bent, 80Jidoka (autonomation), 5–6JIFFIE, 151job grades, 143–144Job Instruction (JI) module, 235–236Job Methods (JM) module, 235–236Job Relations (JR) module, 235–236Johnson, Jim, 24joined at the hip, 55joint ventures, 220–221Jones, Daniel, 43journey

accommodations, 233adopting new technologies, 230–231automating routine tasks, 227–228, 231–232centering on people, 227–228corporate life expectancy, 225–227Critical Chain, 232–233developing a hypothesis, 234–241ERP (Enterprise Resource Planning), 231future blindness, 226goal setting, 223measurement, 237–241push versus pull systems, 236–237right to think, 237road map, 242schedules, 228Six Sigma, 229–230Theory of Constraints, 230–233thinking, 236–237tools versus results, 229–230training, 234–236the use of technology, 227–228

JR (Job Relations) module, 235–236Jula, John, 54junior people, 130–131, 144

JUnit, 150Juran, J. M., 26Just-in-Time. See also inventory.

autonomation (Jidoka), 5–6definition, 4Green Book, 6Just-in-Time flow, 5maximizing local efficiencies, 8mistake-proof systems, 6–7nonstock production, 6rocks-and-stream metaphor, 7–8stop-the-line culture, 5–6zero inspection, 6–7

Just-in-Time commitment. See also commitment.dangers of incremental development, 164Do It Right the First Time, 165example, 167–168examples

medical device interface, 162pluggable interfaces, 163red-eye reduction, 162–163

introduction, 159–160irreversible decisions, 160key decisions, 162legacy systems, 166–168refactoring, 164–168and scientific method, 154set-based design, 160–164and waste, 164YAGNI (You Aren’t Going to Need It), 165

Just-in-Time manufacturing, 4–7

KKaizen (change for the better) events, 173–175Kanban, 10–11, 136, 138–139kanban cards, 10–11Kano, Noriaki, 49–52Kano model, 49–52Keiretsu, 12–13Kennedy, Michael, 15key decisions, 162Keyhole, 45knowledge

creationA3 reports, 157–158condensing knowledge, 157in the Internet age, 159keeping notebooks, 156–157lost knowledge, 155–159principle of, 29–32problem definition, 152–153at Rally Software Development, 149–152

INDEX 265

technical debt, 150tracking knowledge, 155–159

theory of, 121knowledge-based engineering, 15The Knowledge-Creating Company, 156

Llarge group improvement, 173–175large-batch software development, 71, 102last responsible moment, 32, 161, 185lava lamp, 140, 198leadership

customer-focused organizations, 52–57Deming’s points, 122entrepreneurial, 16, 37, 54Honda, 55Intuit, 55Open Source, 209–210process, 132–133Strong Project Leader, 54teams, 55, 132–133technical, 132–133traveling team leaders, 213

leandefinition, xxiiiinitiatives

first step, 153initiating. See journey.reasons for failure, 153

manufacturingversus development, 14overview, 11–12

principles, competitive advantage, 11. See also seven principles.

productionSee also lean, software developmentSee also mass productionSee also Toyota Product Development

SystemSee also Toyota Production SystemDell Computer, 11–13flowchart, 12Keiretsu, 12–13knowledge-based engineering, 15manufacturing, 11–12manufacturing versus development, 14operations, 11–12product development, 13–15Southwest Airlines, 11–12supply chain, 12–13Toyota versus other vehicle manufacturers,

13

software developmenthistory of

See lean, productionSee mass productionSee Toyota Product Development

SystemSee Toyota Production System

overview, 17Lean Solutions, 43learn-by-doing, 19learning. See training.legacy systems, 166–168Lexus, 13lifecycle costs, 20, 70–71Liker, Jeffrey, 14limiting work to capacity, 110–111, 134Linux security breach, example, 207–208, 211Little’s Law, 100–101The Living Company, 141, 225L.L. Bean, 34local efficiencies, 8looms, automated, 3–4lost knowledge, 155–159

MMacCormack, Alan, 30MacGibbon, Simon, 62The Machine That Changed the World, 11maintenance

cost of, 20–21staffing for, 79–80

managementfunctional, 133innovation as competitive advantage, 124people. See people, managing.project, 133. See also project managers.

Managing the Unexpected, 9manufacturing. See also Toyota Product

Development System; Toyota Production System.

versus development, 14Just-in-Time, 4–7lean, 14lean production, 11–12mass production, 12–13video cassettes, 59

mapping value streams. See value streams.maps, Google, 45Marick, Brian, 166, 199market research, 56, 62–63market share, 61, 241Martens, Ryan, 149

266 INDEX

mass productionSee also lean, productionSee also Toyota Product Development SystemSee also Toyota Production SystemAmerican auto industry, 2–3American System of Manufacture, 1Ford Motor Company, 2–3General Motors, 2–3interchangeable parts, 1–2interchangeable people, 2–3Japanese auto industry, 4–7Japanese textiles, 3–4Just-in-Time manufacturing, 4–7and lean manufacturing, 12–13

maximizing local efficiencies, 8McAfee, Andrew, 69McCabe Cyclomatic Complexity Index, 194–

195Measure UP, 40–41measurements

customer satisfaction, 241cycle time, 238–240decreasing number of, 40–41dysfunctional, 238improving the wrong ones, 237Measure UP, 40–41net promoter score, 241optimize by decomposition, 40–41raising levels, 40–41reducing the number of, 238ROI (return on investment), 240–241Sloan, Alfred P., 40–41Sloan’s metrics, 40–41statistical process control, 120–122

medical device interface example, 162Meszaros, Gerard, 167MetaScrum meeting, xviimetrics. See measurements.Microsoft, respect for people, 36Miller, Lynn, 55, 189mindfulness, 9mind-meld, 50minimum useful feature sets, 71–72Minoura, Teruyuki, 236mistake-proofing, 6–7, 196–198money, as incentive, 145–146Muda (waste), xixMugridge, Rick, 187Mulally, Alan, 118, 123, 140multitasking, causing waste, 78–80Mura (stress), xixMuri (bottlenecks), xix

Murphy’s Law, 59–60myths

finishing the code, 79haste makes waste, 35one best way, 37–38optimize by decomposition, 40–41planning is commitment, 33predictable outcomes, 31–32specifications reduce waste, 24–25testing to find defects, 28–29

NNational Center for Manufacturing Sciences

(NCMS), 13nested synchronization, 203–204net promoter score, 241New United Motor Manufacturing Incorporated

(NUMMI), 226newspaper, online subscription, 50no partial credit, 188no secrets, 118Nonaka, Ikujiro, 156nonfunctional requirements, testing, 201nonstock production, 6non-value-added waste, 23, 83Norwegian Computer Society, 218–219Norwegian University of Science and

Technology (NTNU), 218–219notebooks, keeping, 156–157NS minivan, 56numerical quotas, 123

OOhno, Taiichi

introduction, 5–6planning, 33value streams, 83waste, 23–25, 75

on the job training, 234–236one best way, 2, 37–38one click build, 198Oobeya, 213Open Source

chief engineer approach, 54leadership, 54reviews, 196software example, 209–210Strong Project Leader, 54

operations, lean, 11–12optimize by decomposition, 40–41optimize the whole, principle of, 38– 41

INDEX 267

options-based development, 135ordinary employees, 117, 227O’Reilly, Charles, 146organizational boundaries. See boundaries,

organizational.organizing a workspace, 190–192organizing work, 138–139outsourcing

basic principles, 216–217BMI call center, 215Boeing, 216–217competitive advantage, 215–216conflict of interest, 215development, 216–217infrastructure, 214–215introduction, 214Procter & Gamble, 216–217Toyota, 216–217transactions, 215

overproduction, 25, 75overtime, 110–111

PPage, Larry, 46page rank system, Google, 48pairing, 195–196Pareto analysis, 26partially done work, 74–75partners. See also teams.

committers, 209–210contracts

BAA airport management, 217–218, 220–221

Norwegian Computer Society, 218–219NTNU (Norwegian University of Science

and Technology), 218–219PS 2000, 218–219purpose of, 217relational, 219–221T5 Agreement, 217–218

Deming point 12, 210eliminating barriers, 210equality of, 213examples

3M, 213–214Boeing 787 Dreamliner, 210Linux security breach, 207–208, 211Open Source software, 209–210Procter & Gamble, 210

exchanging tests, 212frequent integration, 212global networks, 210–214

global teams, 212global work groups, 212joint ventures, 220–221leaders, 209–210Oobeya, 213outsourcing

basic principles, 216–217BMI call center, 215Boeing, 216–217development, 216–217infrastructure, 214–215introduction, 214Procter & Gamble, 216–217Toyota, 216–217transactions, 215

proxies, 213rotating people, 212synergy, 207–217traveling team leaders, 213war room, 213

PatientKeepercycle time, 97–98delivery speed, 95–98development teams, 97introduction of Scrum, xviilimiting complexity, 71limiting work to capacity, 134product managers, 97release schedules, 97

PBS documentary, 119PDCA (plan, do, check, act), 121, 154–155people, managing

andon, 139–140under the bell curve, 130Boeing 777 project, 117–120, 140causes of low quality and productivity, 121centering on people, 227–228choosing suppliers, 122compensation

alternatives to money, 145–146annual raises, 144balanced scorecards, 144bonuses, 145, 146promotion systems, 143–144reward basis, 144–145span of influence versus span of control,

144–145dashboards, 136, 140–141Deming Cycle, 121Deming on, 120–123dependence on inspection, 122fear, 122

268 INDEX

people, managing (continued):incentives

individual performance, 142performance evaluations, 141–143rankings, 142–143

inherent system variation, 121interdepartmental barriers, 122job grades, 143–144junior people, 130–131, 144kanban, 136, 138–139leadership, 122numerical quotas, 123ordinary employees, 117, 227organizing work, 138–139PBS documentary, 119PDCA (plan, do, check, act), 121, 154–155pride of workmanship, 123projects versus products, 62psychology, 122rotating assignments, 212scientific method, 121self-directing work, 137–141sharing early and often, 118slogans, exhortations, and targets, 123stop-the-line culture, 139–140synergy, 121System of Profound Knowledge, 121testing early, failing fast, 118–119theory of knowledge, 121training, 122, 123, 129trust, 125visible signals, 139–140visual workspace, 136–141wall charts, 140why programs fail, 124–125Working Together program, 118–120

performance evaluations as incentives, 141–143personnel. See partners; people; teams.PERT (Program Evaluation and Review

Technique), 179Pfeffer, Jeffrey, 146pilot stage, 48P&L (profit and loss) model, 240plan, do, check, act (PDCA), 121, 154–155plan-driven methods, 33planning

as commitment, 33iterative development, 186Taiichi Ohno on, 33

pluggable interfaces example, 163Polaris program, 177–182policies. See practices; principles.

Post-it Notes, 139practices. See also principles.

definition, 19for successful software development, 30

predictable outcomes, 31–32Price, Jerry, 125pricing structure, complexity example, 72–73pride of workmanship, 123principles. See also practices.

continuous improvement, 38definition, 19Google

democracy principle, 45excellence principle, 45product development principles, 44–45speed principle, 45value principle, 44

lean software development. See seven principles.

learn-by-doing, 19of outsourcing, 216–217software development, 20–21understand-before-doing, 19

prioritizing features, 71–72Prius, 21problem solving

analyzing the situation, 169defining the problem, 152–153, 169disciplined approach, 169–172experimentation, 171–172first rule, 168follow up, 172hypothesis generation, 171introduction, 168Kaizen (change for the better) events, 173–

175large group improvement, 173–175scientific method, 154, 169–172standardization, 172verifying results, 172

process cycle efficiency, 85–86, 90–92, 108process leadership, 132–133processes

availability, 98average time, calculating, 100–101capable, 98minimizing elements, 105–107minimizing size, 107–108quality measurement, 99robust, 177too big, 107–108too many things, 105–107

INDEX 269

Procter & Gamble, 51, 210, 216–217product development, lean, 13–15Product Development for the Lean Enterprise,

15Product Development Performance, 13, 52product managers, 133product owners, 133productivity, 28products

concept stage, 46development. See software development;

Toyota Product Development System; Toyota Production System.

versus projects, 60–63specifications

basis for acceptance tests, 150waste reduction, 24–25

profit, definition, 152profit and loss (P&L) model, 240profitability, 61, 122, 241–242Program Evaluation and Review Technique

(PERT), 179programmer tests. See unit tests.programmers. See partners; people; teams.project managers, 42, 127, 133, 237. See also

management.projects

average process time, calculating, 100–101average speed, 99–100cycle time, 98–99dividing work into stories, 99expediting, 98measuring, 99PatientKeeper delivery cycle, 95–98process availability, 98process capability, 98versus products, 60–63red flags, 98setting upper limits, 99setting upper size limits, 99time delays, 98–99

promotion systems as incentives, 143–144property tests, 201Proulx, Tom, 55proxies, 213PS 2000 contract, 218–219psychology, 122pull scheduling, example, 112–113pull systems, 10–11, 236–237push systems, 236–237

QQA (Quality Assurance), 89, 96QFD (quality function deployment) analysis, 56quality

building in, principle of, 25–29change tolerance, 182discipline

automating routine tasks, 197–198code reviews, 194–195configuration management, 201–202continuous integration, 202–203five S’s, 190–192merging subsystems, 203–204mistake-proofing, 196–198nested synchronization, 203–204Open Source reviews, 196organizing a workspace, 190–192pairing, 195–196shine (seiso), 191–192sort (seiri), 191–192standardize (seiketsu), 191–192standards for software development, 193–

196sustain (shitsuke), 191–192systematize (seiton), 191–192test-driven development, 198–201

divisible systems architecture, 182iterative development

assessment, 188–189commitment, 186example, 184FIT (Framework for Integrated Tests), 187implementation, 186–188introduction, 183–184overview, 183planning, 186preparation, 185–186stories, 183–186story-test driven development, 186user interface variation, 189–190

robust development processes, 177role of feedback

architecture, 182iterative development, 183–190Polaris program, 177–182release planning, 179–181

Quality Assurance (QA), 89, 96quality function deployment (QFD) analysis, 56“Quality With a Name,” 20queuing theory. See also speed.

average process time, calculating, 100–101cascading queues, 113–114

270 INDEX

queuing theory (continued):cycle time reduction

establishing a cadence, 108–109evening out work arrival, 103–105limiting work to capacity, 110–111minimizing process elements, 105–107minimizing process size, 107–108pull scheduling, 112–114

examplesairport check-in desk, 110asynchronous cadence, 109customer service, 111–112doctor’s appointments, 104–105IT workload, 103–104pull scheduling, 112–113release cycles, 107–108a seven year list, 106–107thrashing, 111–112

Google, 101–102Little’s Law, 100–101system stability, 101–102utilization, 101–102variation, 101–102

QuickBooks, 70Quicken Rental Property Management, 57–58

Rraises as incentives, 144Rally Software Development, 149–152ranking people, 128, 142–143Raymond, Eric, 54red-eye reduction example, 162–163refactoring, 164–168Reichheld, Fred, 241relational contracts, 219–221relearning, 76release cycles, example, 107–108release planning, 179–181remote teams, 212–213repeatable reliable cycle time, 238requirements

churn, 24, 91nonfunctional, 182, 201overloading, 25SRS (Software Requirements Specifications),

75stale, 74test specs, 82timing assumptions, 233too early, 24, 91

respect for people, 3, 36–38response time

by category, 84

at peak capacity, 101queue length, 172reliability, 98testing, 201

responsibility, 56–57responsibility-based planning and control, 133–

135retrospectives, 236return on investment (ROI), 41, 240–241reversible decisions, 32rewards. See also compensation; incentives.

basis for, 144–145intrinsic, 146

right to think, 237risk

contracting away, 218custom software development, 181partially done work, 24refactoring, 164

river companies, 141robust development processes, 177rocks-and-stream metaphor, 7–8Rogers, Paul, 57root causes

failure of lean initiatives, 153group improvement failure, 174low quality and productivity, 121, 123–124of problems, 121, 123–124technical debt, 150waste, 67

rotating people, 212

Ssafety considerations, stop-the-line culture, 9sales, engineering, development (SED) system,

55Sapolsky, Harvey, 179satisfaction, customer, 49–52, 241schedules

inventory. See Just-in-Time.Kanban, 10–11PatientKeeper releases, 97philosophy of, 228slipping dates, 133–134and teams, 134, 135

Schnaith, Kent, 192Schwaber, Ken, xviiscientific method

Deming Cycle, 121Just-in-Time commitment, 154managing people, 121problem solving, 154, 169–172steps of, 154

INDEX 271

stop-the-line culture, 154Toyoda, Kiichiro, 154Toyoda, Sakichi, 154Toyota Production System, 154

scope bloat, 25scope control, 25Scrum

bottleneck elimination, xixcreation of, xvii–xviiidefinition, 28quality improvement, 28stress avoidance, xixType A, xviiType B, xviiType C, xviiwaste elimination, xixwinning companies, xviiwinning product portfolio, xviiwinning teams, xvii

Scrum Product Owners, 133ScrumMasters, 133Sears, 34SED (sales, engineering, development) system,

55seiketsu (standardize), 191–192seiri (sort), 191–192seiso (shine), 191–192seiton (systematize), 191–192self-directing work, 137–141self-organization, 17, 19, 97set-based design, 160–164seven principles

building quality in, 25–29create knowledge, 29–32defer commitment, 32–33deliver fast, 34–35eliminate waste, 23–25myths

haste makes waste, 35one best way, 37–38optimize by decomposition, 40–41planning is commitment, 33predictable outcomes, 31–32specifications reduce waste, 24–25testing to find defects, 28–29

optimize the whole, 38– 41respect people, 36–38

seven wastes. See also waste.defects, 81–82delays, 80–81extra features, 75handoffs, 77–78

partially done work, 74–75relearning, 76task switching, 78–80

seven year list, example, 106–107shared leadership, 56sharing early and often, 118Shewhart Cycle, 121Shimmings, Ian, 41shine (seiso), 191–192Shingo, Shigeo

introduction, 6–7purpose of inspections, 82seven wastes, 73types of inspections, 27

ship builders, training, 234–236shitsuke (sustain), 191–192Shook, Jim, 35Shore, Jim, 20Sienna minivan, 53–55Silicon Valley Product Group, 53silos, 40, 131simulation, kanban cards, 10single point of responsibility, 65Six Sigma, 124, 229–230slack, 15, 88, 102, 112, 134slipping dates, 133–134Sloan, Alfred P., 2, 40–41slogans as incentives, 123small batches, 15, 74, 101–102, 196Smalley, Art, 153Smith, Levering, 178Sobek, Durwood, 53software

cost of maintenance, 20–21development timeline, 20difficult to change. See legacy systems.embedded, definition, 20enterprise, definition, 20legacy, 166–168structure of. See architecture, software.

software companies versus internal IT, 62–65software development

capable processes, 98concurrent, 182defect queues, 25–26detailed design, 29–30deterministic school, 21empirical school, 21handling changes. See change, management.large-batch approach, 71, 102outsourcing, 216–217plan-driven methods, 33

272 INDEX

software development (continued):principles of. See principles; seven principles.process quality measurement, 99speed, competitive advantage, 35speed versus hacking, 35systematic learning, 31waterfall model, 22, 29–30

software development, custom systemsaccountability, 64–65beginning/end criteria, 62change requests, 62funding profiles, 61IT departments

accountability, 64–65fixing, 64versus software companies, 62–65we-they model, 63

IT—business collaboration, 62–65products versus projects, 60–63software companies versus internal IT, 62–65staffing, 62we-they model, 63

Software Requirements Specifications (SRS), 75sort (seiri), 191–192Southwest Airlines, 11–12span of influence versus span of control, 144–

145specialists in teams, 130–131specification-by-example, 200specifications, 24–25, 150speed. See also deliver fast; queuing theory.

average projects, 99cycle time, 98–99dividing work into stories, 99expediting, 98versus hacking, 35measuring, 99PatientKeeper delivery cycle, 95–98principle of, 45process availability, 98process capability, 98red flags, 98setting upper limits, 99time delays, 98–99unique projects, 100

Spolsky, Joel, 36Spring, 150Sprints, at PatientKeeper, xviiSRS (Software Requirements Specifications), 75staffing. See partners; people; teams.Stalk, George, 5, 35standardization, problem solving, 172

standardize (seiketsu), 191–192standards for software development, 193–196statistical process control, 120–122stealing hangers, 125stop-the-line culture

andon, 139–140definition, 5–6safety considerations, 9and scientific method, 154

storiesdividing work into, 99iterative development, 183–186no partial credit, 188

story tests, 200. See also acceptance tests.story-test driven development, 186strangling legacy code, 167stress (Mura), xixstress avoidance, xixStrong Project Leader, 54suggestion systems, 236supervisors. See people, managing.suppliers, choosing, 122, 123supply chain, lean, 12–13sustain (shitsuke), 191–192Sutcliffe, Kathleen M., 9Sutherland, Jeff, 71, 96synchronization, nested, 203–204synergy, 121, 207–217System of Profound Knowledge, 121system stability and queuing theory, 101–102system variation, 121systematic learning, 31systematize (seiton), 191–192systems design stage, 47

TT5 Agreement, 217–218tacit knowledge, 14, 31, 77–78, 156–157Takeuchi, Hirotaka, 156target costs, 180, 218–219, 221targets as incentives, 123task switching, 78–80Taxonomy of Problem Management Activities,

20Taylor, Frederick Winslow, 2, 37, 227TDD (test-driven development). See test-driven

development.teachers. See training.teams. See also partners.

barriers to, 128champions, 133characteristics of, 126–127

INDEX 273

chartering, 241coaches, 133co-located, 211, 213complete, 57–60cross-functional, 56, 64, 78, 122dependencies, 135design/build, 118, 123, 133development

3M, 56–60capacity, 99champions, 132DFSS (Design for Six Sigma), 229error prevention, 82expertise, 129–130, 212goal of, 240incentives, 123interaction designers, 189joined at the hip, 55maintenance duties, 79measurements, 237pride in workmanship, 210process improvement, 31pull scheduling, 112–114rewards, 145set-based concurrent engineering, 16size, and technical debt, 153

expertise, 129–131global, 212Honda, 55versus individual efforts, 126Intuit, 55, 57–58leadership, 55, 132–133limiting work to capacity, 134organizational boundaries, 214product managers, 133Quicken, 55ranking systems, 128remote, 212–213responsibility-based planning and control,

133–135schedules, 134, 135Scrum Product Owners, 133ScrumMasters, 133silos, 131slipping dates, 133–134specialists, 130–131variation, 135winning, xviiwork breakdown structure, 135versus workgroups, 126–127, 212

Teamwork is the key..., 56–57technical debt, 150

technical leadership, 132–133technical success, 145technical writers, 75, 130–131test early, fail fast, 118–119test harness

acceptance tests, 202benefits of, 82legacy systems, 166–167schedule, 27unit tests, 200usability tests, 201user interface, 151

test-and-fix churn, 24test-driven development (TDD)

exploratory tests, 201productivity, 28property tests, 201purpose of, 199story tests, 200types of tests, 199unit tests, 200usability tests, 201

testing3D modeling, 118automating, 82Boeing 777, 118–120business intent, 200design intent, 200to find defects, 28–29. See also test-driven

development.nonfunctional requirements, 201testing early, failing fast, 118–119too late, 88, 91user interface, 150–151, 201verification, role of, 29

testing early, failing fast, 118–119tests

acceptance, 150, 186acceptance-test-driven development, 186exchanging, 212programmer. See unit tests.story-test driven development, 186unit, 200usability, 21

textile industry, Japan, 3–4Theory of Constraints, 230–233theory of knowledge, 121thinking, 236–237thinking tools, 21–22, 195thrashing, example, 111–112time, competing on the basis of, 34timebox, 32, 181

274 INDEX

timelines. See value streams.too many things in processes, 105–107too much work. See limiting work to capacity.tools versus results, 229–230towering technical competence...., 129Toyoda, Eiji, 5, 226Toyoda, Kiichiro

incentives, 141introduction, 4scientific method, 154tracking knowledge, 155

Toyoda, Sakichievolutionary thinking, 226–227incentives, 141introduction, 3scientific method, 154tracking knowledge, 155

Toyotachief engineer, 53–55competitive advantage, 224fire at Aisin plant, 208–209, 211genchi-genbutsu (go, see, confirm), 54versus other vehicle manufacturers, 13outsourcing, 216–217problem definition, 152–153product delivery deadlines, 161profits, xxiiiresponsibility, 56–57responsibility-based planning and control,

133–135set-based design, 161Sienna minivan, 53–55Smart Car initiative, 224–225Teamwork is the key..., 56–57towering technical competence...., 129training new engineers, 129

Toyota Product Development SystemSee also Just-in-Time manufacturingSee also mass productionSee also Toyota Production Systemcornerstone elements, 16entrepreneurial leadership, 16expert engineering workforce, 16respect for people, 36–37responsibility-based planning and control, 16set-based concurrent engineering, 16software development philosophy, 21study of, 15

Toyota Production SystemSee also Just-in-Time manufacturingSee also mass productionSee also Toyota Product Development System

automated looms, 3autonomation (Jidoka), 5–6detecting abnormalities. See autonomation

(Jidoka); stop-the-line culture.goals, 152–153Japanese auto industry, 4–7Just-in-Time flow, 4–5overview, 4–7push versus pull systems, 236–237scientific method, 154versus Six Sigma, 229–230thinking, 236–237value streams, 83

Toyota Production System, 5The Toyota Way, 14traceability, 75, 199tracking knowledge, 155–159tradeoffs, 41, 158, 241training

Allen’s steps, 234–236Deming’s points, 122, 123on the job, 234–236Job Instruction (JI) module, 235–236Job Methods (JM) module, 235–236Job Relations (JR) module, 235–236new engineers, 129ship builders, 234–236TWI (Training Within Industry), 235–236vocational education, 234–236

Training Within Industry (TWI), 235–236transactions, outsourcing, 215traveling team leaders, 213trust, 125Turner, Richard, 33Type A Scrum, xviiType B Scrum, xviiType C Scrum, xvii

UThe Ultimate Question, 241uncoded documentation, waste, 74undeployed code, waste, 75understand-before-doing, 19undocumented code, waste, 75unit tests, 200United Airlines, 117–118United Kingdom, 41, 193, 217United States

3M tour, 213Deming and, 121doctor’s appointments, 104invention of interchangeable parts, 1–3

INDEX 275

liens registry, 231Toyota manufacturing, 216, 226Toyota moves to, 12

unsynchronized code, waste, 74untested code, waste, 74unused documentation, waste, 77US War Production Board, 235usability tests, 201used car sales, 41user interface

competitive advantage, 189iterative design, 189–190testing, 150–151, 201variation, 189–190

utilizationand cycle time, 102, 244full, 88Google workforce, 101–102and queuing theory, 101–102and variation, 101–114

Vvalue

customer-focused organizationschampions, 52–57chief engineer, 53–55complete teams, 57–60decision making, 57designing for manufacturability, 58–59designing for operations, 58–59development goal, 55facilitating information flow, 52–60leadership, 52–57leadership teams, 55Murphy’s Law, 59–60responsibility, 56–57shared leadership, 56What can go wrong, will go wrong, 59–60

customersdelighting, 49–52. See also Google.focus on the job, 51–52Kano model, 49–52needs, 43satisfaction, 49–52understanding, 50

value principle, 44value streams

churn, 91delays, 91examples, 85–91for future processes, 92keeping it simple, 85

mapping, 83–84owner identification, 84–85preparation, 83–84start/stop points, 84waste diagnosis, 91

Van Schooenderwoert, Nancy, 27variation

inherent in the system, 121and queuing theory, 101–102and utilization, 101–114

variation in teams, 135verification, and long release cycles, 107–108verifying results of problem solving, 172video cassettes, manufacturing, 59visible signals, 139–140vision, 16visual workspace, 136–141“vital few and trivial many” rule, 26vocational education, 234–236voice of the customer, 53, 229volunteers, 54, 208–210

Wwaiting. See delays.Wake, Bill, 165wall charts, 140war room, 213waste. See also seven wastes.

80/20 rule, 25–26anticipating, 76biggest source of, 24–25churn, 24complexity and, 67, 69–73diagnosing. See value streams.elimination

principle of, 23–25reducing by specification, 24–25Taiichi Ohno on, 23–25

extra features, 24–25inventory as, 24Just-in-Time commitment, 164lost knowledge, 76Muda, xixmultitasking, 78–80non-value-added, 23, 83partially done software, 24recognizing, 23. See also value streams.requirements churn, 24root cause, 67test-and-fix churn, 24uncoded documentation, 74undeployed code, 75

276 INDEX

waste (continued):undocumented code, 75unsynchronized code, 74untested code, 74unused documentation, 77“vital few and trivial many” rule, 26

waste (Muda), xixwaterfall development model, 22, 29–30Weick, Karl E., 9Welch, Jack, 173we-they model, 63What can go wrong, will go wrong, 59–60“When IT’s Customers Are External,” 62–63Whitney, Eli, 1Who has the D?, 57Wild, Werner, 159winning companies, xviiwinning product portfolio, xviiwinning teams, xvii

Wolf, Bob, 208Womack, James, 43work breakdown structure, 135workers. See partners; people; teams.workgroups, 126–127, 212Working Effectively With Legacy Code, 167Working Together program, 118–120Workout, 173–175write less code, 29, 67–73

YYAGNI (You Aren’t Going to Need It), 165Yamada, Kosaku, 13Yokoya, Yuji, 53–55

ZZara, 67–68zero inspection, 6–7