Lean Software Development: An Agile Toolkit (The Agile Software Development Series)

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $17.09
Usually ships in 1-2 business days
(Save 68%)
Other sellers (Paperback)
  • All (13) from $17.09   
  • New (8) from $28.69   
  • Used (5) from $17.09   

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.

Read More Show Less

Product Details

  • ISBN-13: 9780321150783
  • Publisher: Addison-Wesley
  • Publication date: 5/8/2003
  • Series: Agile Software Development Series
  • Edition description: New Edition
  • Pages: 203
  • Sales rank: 670,393
  • Product dimensions: 7.00 (w) x 9.25 (h) x 0.50 (d)

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

Read More Show Less

Read an Excerpt

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

Read More Show Less

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.

Read More Show Less

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

Read More Show Less

Introduction

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 brainpowerof 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

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)