Lean Software Development: An Agile Toolkit / Edition 1

by Mary Poppendieck

Overview

Lean Software Development: An Agile Toolkit

• Adapting agile practices to your development organization
• Uncovering and eradicating waste throughout the software development lifecycle
• Practical techniques for every development manager, project manager, and technical leader

Lean software development: applying agile principles to your organization

In Lean Software Development, Mary and Tom Poppendieck identify seven fundamental "lean" principles, adapt them for the world of software development, and show how they can serve as the foundation for agile development approaches that work. Along the way, they introduce 22 "thinking tools" that can help you customize the right agile practices for any environment.

Better, cheaper, faster software development. You can have all three–if you adopt the same lean principles that have already revolutionized manufacturing, logistics and product development.

• Iterating towards excellence: software development as an exercise in discovery
• Managing uncertainty: "decide as late as possible" by building change into the system.
• Compressing the value stream: rapid development, feedback, and improvement
• Empowering teams and individuals without compromising coordination
• Software with integrity: promoting coherence, usability, fitness, maintainability, and adaptability
• How to "see the whole"–even when your developers are scattered across multiple locations and contractors

Simply put, Lean Software Development helps you refocus development on value, flow, and people–so you can achieve breakthrough quality, savings, speed, and business alignment.

Product Details

ISBN-13:	2900321150782
Publisher:	Pearson Education
Publication date:	05/08/2003
Series:	Agile Software Development Series
Edition description:	New Edition
Pages:	240
Product dimensions:	6.90(w) x 9.00(h) x 0.60(d)

About the Author

MARY POPPENDIECK, Managing Director of the Agile Alliance (a leading non profit organization promoting agile software development), is a seasoned leader in both operations and new product development with more than 25 years of IT experience. She has led teams implementing solutions ranging from enterprise supply chain management to digital media, and built one of 3M's first Just-in-Time lean production systems. Mary is currently the President of Poppendieck LLC, a consulting firm specializing in bringing lean production techniques to software development.

TOM POPPENDIECK was creating systems to support concurrent development of commercial airliner navigation devices as early as 1985. Even then, the aerospace industry recognized that sequential development of product design, manufacturing process design and product support was costly and non-competitive. His subsequent experience in software product development, COTS implementation, and most recently as a coach, mentor, and enterprise architect support the same conclusion for software development. He currently assists organizations that need to improve their software development capabilities apply the lean principles and tools described in this book.

Table of Contents

Foreword by Jim Highsmith.


Foreword by Ken Schwaber.


Preface.


Introduction.


1. Eliminate Waste.

The Origins of Lean Thinking. Tool 1: Seeing Waste. Partially Done Work. Extra Processes. Extra Features. Task Switching. Waiting. Motion. Defects. Management Activities. Tool 2: Value Stream Mapping. Map Your Value Stream. An Agile Value Stream Map. Try This.

2. Amplify Learning.

The Nature of Software Development. Perspectives on Quality. The Service View of Quality. Quality in Software Development. Variability. Design Cycles. Do It Right the First Time? Learning Cycles. Tool 3: Feedback. Software Development Feedback Loops. Tool 4: Iterations. Iteration Planning. Team Commitment. Convergence. Negotiable Scope. Tool 5: Synchronization. Synch and Stabilize. Spanning Application. Matrix. Tool 6: Set-Based Development. Set-Based Versus Point-Based. Set-Based Software Development. Develop Multiple Options. Communicate Constraints. Let the Solution Emerge. Try This.

3. Decide as Late as Possible.

Concurrent Development. Concurrent Software Development. Cost Escalation. Tool 7: Options Thinking. Delaying Decisions. Options. Microsoft Strategy, circa 1988. Options Thinking in Software Development. Tool 8: The Last Responsible Moment. Tool 9: Making Decisions. Depth-First Versus Breadth-First Problem Solving. Intuitive Decision Making. The Marines. Simple Rules. Simple Rules for Software Development. Try This.

4. Deliver as Fast as Possible.

Why Deliver Fast? Tool 10: Pull Systems. Manufacturing Schedules. Software Development Schedules. Software Pull Systems. Information Radiators. Tool 11: Queuing Theory. Reducing Cycle Time. Steady Rate of Arrival. Steady Rate of Service. Slack. How Queues Work. Tool 12: Cost of Delay. Product Model. Application Model. Tradeoff Decisions. Try This.

5. Empower the Team.

Beyond Scientific Management. CMM. CMMI. Tool 13: Self-Determination. The NUMMI Mystery. A Management Improvement Process. Tool 14: Motivation. Magic at 3M. Purpose. The Building Blocks of Motivation. Belonging. Safety. Competence. Progress. Long Days and Late Nights. Tool 15: Leadership. Leadership. Respected Leaders. Master Developers. The Fuzzy Front End. Where Do Master Developers Come From? Project Management. Tool 16: Expertise. Nucor. Xerox. Communities of Expertise. Standards. Try This.

6. Build Integrity In.

Integrity. Perceived Integrity. Conceptual Integrity. The Key to Integrity. Tool 17: Perceived Integrity. Model-Driven Design. Maintaining Perceived Integrity. Tool 18: Conceptual Integrity. Software Architecture Basics. Emerging Integrity. Tool 19: Refactoring. Keeping Architecture Healthy. Maintaining Conceptual Integrity. Isn't Refactoring Rework? Tool 20: Testing. Communication. Feedback. Scaffolding. As-Built. Maintenance. Try This.

7. See the Whole.

Systems Thinking. Tool 21: Measurements. Local Optimization. Why Do We Suboptimize? Superstition. Habit. Measuring Performance. Information Measurements. Tool 22: Contracts. Can There Be Trust Between Firms? But Software Is Different. The Purpose of Contracts. Fixed-Price Contracts. Time-and-Materials Contracts. Multistage Contracts. Target-Cost Contracts. Target-Schedule Contracts. Shared-Benefit Contracts. The Key: Optional Scope. Try This.

8. Instructions and Warranty.

Caution-Use Only as Directed. Instructions. Sphere of Influence. Large Company. Small Company. Special Work Environments. Troubleshooting Guide. Warranty.

Bibliography.


Index.

Preface

Preface

I used to be a really good programmer. My code controlled telephone switching systems, high energy physics research, concept vehicles, and the makers and coaters used to manufacture 3M tape. I was equally good at writing Fortran or assembly language, and I could specify and build a minicomputer control system as fast as anyone. After a dozen or so years of programming, I followed one of my systems to a manufacturing plant and took the leap into IT management. I learned about materials control and unit costs and production databases. Then the quality-is-free and just-intime movements hit our plant, and I learned how a few simple ideas and empowered people could change everything.

A few years later I landed in new product development, leading commercialization teams for embedded software, imaging systems, and eventually optical systems. I liked new product development so much that I joined a start-up company and later started my own company to work with product development teams, particularly those doing software development.

I had been out of the software development industry for a half dozen years, and I was appalled at what I found when I returned. Between PMI (Project Management Institute) and CMM (Capability Maturity Model) certification programs, a heavy emphasis on process definition and detailed, front-end planning seemed to dominate everyone's perception of best practices. Worse, the justification for these approaches was the lean manufacturing movement I knew so well. I was keenly aware that the success of lean manufacturing rested on a deep understanding of what creates value, why rapid flow is essential, and how to release the brainpower of the people doing the work. In the prevailing focus on process and planning I detected a devaluation of these key principles. I heard, for example, that detailed process definitions were needed so that 'anyone can program,' while lean manufacturing focused on building skill in frontline people and having them define their own processes.

I heard that spending a lot of time and getting the requirements right upfront was the way to do things 'right the first time.' I found this curious. I knew that the only way that my code would work the first time I tried to control a machine was to build a complete simulation program and test the code to death. I knew that every product that was delivered to our plant came with a complete set of tests, and 'right the first time' meant passing each test every step of the way. You could be sure that next month a new gizmo or tape length would be needed by marketing, so the idea of freezing a product configuration before manufacturing was simply unheard of. That's why we had serial numbers—so we could tell what the current manufacturing spec was the day a product was made. We would never expect to be making the exact same products this month that we were making last month.

Detailed front-end planning strikes me as diametrically opposed to lean manufacturing principles. Process definition by a staff group strikes me as diametrically opposed to the empowerment that is core to successful lean manufacturing. It seems to me that the manufacturing metaphor has been misapplied to software development. It seems to me that CMM, in its eagerness to standardize process, leaves out the heart of discovery and innovation that was the critical success factor in our move to total quality management. We knew in manufacturing that ISO9000 and even Malcolm Baldrige awards had little or nothing to do with a successful quality program. They were useful in documenting success, but generally got in the way of creating it. It seems to me that a PMI certification program teaches a new project manager several antipatterns for software project management. Work breakdown. Scope control.

Change control. Earned value. Requirements tracking. Time tracking. I learned all about these when I was a program manager for government contracts at 3M, and was keenly aware of the waste they added to a program. We certainly knew better than to use them on our internal product development programs, where learning and innovation were the essential ingredients of success.

This is not to say that CMM and PMI are bad, but only that for anyone who has lived through the lean revolution, they tend to give the wrong flavor to a software development program. In this book we hope to change the software development paradigm from process to people, from disaggregation to aggregation, from speculation to data-based decision making, from planning to learning, from traceability to testing, from cost-and-schedule control to delivering business value. If you think that better, cheaper, and faster can't coexist, you should know that we used to think the same way in the pre-lean days of manufacturing and product development. However, we learned that by focusing on value, flow, and people, you got better quality, lower cost, and faster delivery. We learned that from our competitors as they took away our markets. May you lead your industry in lean software development.

Mary Poppendieck