(Just to understand that lean programming is not the same as compact programming.)

From www.poppendieck.com :

Mary and Tom Poppendieck

Implementing Lean Software Development

From Concept to Cash

(Abstracts)

The Sequel

Lean was an idea borrowed from the 1990's when we wrote the book Lean Software Development: An Agile Toolkit in 2003. We had observed that breakthrough ideas from manufacturing and logistics often take a decade or two before 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 the 1980's and 1990's to help us explain why agile methods are a very effective approach to software development.

The strategy worked. Lean Software Development presents a set of thinking tools based on lean thinking that leaders continue to find useful for understanding agile software development. The book has been purchased by many a developer who gave it to his or her manager to read, and many managers have distributed multiple copies of the book to colleagues in support of a transition to lean/agile software development. Meanwhile, something unexpected happened to lean. In the last couple of years lean initiatives have experienced a resurgence in popularity. The word lean was originally popularized in the early1990's to characterize the Japanese approach to automobile manufacturing.1 In recent years, Honda and Toyota have been doing increasingly well in the North American auto market, while Detroit automakers are restructuring. For example, Toyota's profits rose from over $8 billion in the fiscal year ending March 31, 2003 to over $10 billion in 2004, $11 billion in 2005, and $12 billion in 2006. Many companies have taken a second look at lean to try to understand what's behind such steady and sustained success. Lean initiatives seldom start in the software development or product development part of a company, but over time, successful lean initiatives make their way from manufacturing or logistics to development departments. However, lean practices from manufacturing and other operational areas do not adapt easily to a development environment, so lean initiatives have a tendency to stall when the reach software development. While the underlying lean principles remain valid, it is usually inappropriate to apply operational practices and measurements to a development environment. When lean initiatives stall in software development areas, many companies have discovered that Lean Software Development gives them a good foundation for thinking about how to modify their approach and adapt lean ideas to a development organization.

The benefits of lean and agile software development have become widely known and appreciated in the last couple of years, and many organizations are changing the way they develop software. We have traveled around the world visiting organizations as they implement these new approaches, and we have learned a lot from our interaction with people working hard to change the way they develop software. As our knowledge has grown, so has the demand for more information on implementing lean software development. We realized that a book would allow us to share what we've learned with many more people than we can contact personally. Therefore we have summarized our experiences in this book: Implementing Lean Software Development: From Concept 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 adapting lean principles to your world. We start this book where the last book left off and go deeper into the issues and problems that people encounter when trying to implement lean and agile software development. You might consider this book a sequel to Lean Software Development; instead of repeating what is in that book, we take a different perspective. We assume the reader is convinced that lean/agile software development is a good idea, and focus on the essential elements of a successful implementation. We look at key aspects of implementation and discuss what is important, what isn't, and why. Our objective is to help organizations get started down the path toward more effective software development.

The first chapter of this book reviews the history of lean, and the second chapter reviews the seven principles of lean software development presented in Lean Software Development. These are followed by chapters on value, waste, speed, people, knowledge, quality, partners, and the journey ahead. Each of these eight chapters begins with a story that illustrates how one organization dealt with the issue at hand. This is followed by a discussion of key topics we have 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 of exercises that helps you explore the topics more deeply.

May the wind be always at your back.
Mary and Tom Poppendieck May, 2006

Copyright 2006 Poppendieck. LLC

From www.poppendieck.com :

Introduction to Lean Software Development

1 Day Seminar

Practical approaches for applying lean principles to software development.

As global competitiveness comes to the software development industry, the search is on for a better way to create first-class software rapidly, repeatedly, and reliably. Lean initiatives in manufacturing, logistics, and services have led to dramatic improvements in cost, quality and delivery time; can they do the same for software development? The short answer is "Absolutely!"

Of the many methods that have arisen to improve software development, Lean is emerging as one that is grounded in decades of work understanding how to make processes better. Lean thinking focuses on giving customers what they want, when and where the want it, without a wasted motion or wasted minute.

This one day seminar provides an introduction to applying lean principles such as Rapid Response, Constant Learning, Built-in Quality, Local Responsibility and Global Optimization to software development.

You will learn how to:

1. Develop a value stream map for your current software development organization, and then create a new map for the future.
2. Reorganize the software development process around iteration cycles and simplify project management.
3. Assess the state of your basic disciplines which determine your software development process capability.
4. Understand how to drive software quality by moving testing to the front and center of the development process.
5. Organize a visual workplace so that everyone knows the most important thing to do next without being told.

This seminar is mainly lecture with some small group work on case studies. The seminar covers strategies for applying the seven lean principles of:

1. Eliminate Waste
2. Build Integrity In
3. Create Learning
4. Defer Commitment
5. Deliver Fast
6. Respect Workers
7. Optimize the Whole

From www.poppendieck.com :

Mary Poppendieck

Lean Development Thinking Tools for Agile Software Development Leaders

Introduction

This is a book of thinking tools for software development leaders. It is a toolkit for translating widely accepted lean principles into effective agile practices that fit your unique environment. Lean thinking has long history of generating dramatic improvements in fields as diverse as manufacturing, health care and construction. Can it do the same for software development? One thing is clear, the field of software development has plenty of opportunity for improvement. Jim Johnson, chairman of the Standish Group, told an attentive audience1 the story of Florida vs. Minnesota as each developed their Statewide Automated Child Welfare Information System (SACWIS). In Florida, system development started in 1990, and was estimated to take 8 years and to cost $32 million. As Johnson spoke in the year 2002, Florida had spent $170 million and the system was estimated to be completed in 2005 at the cost of $230 million. Meanwhile, Minnesota began developing essentially the same system in 1999 and completed it in early 2000, at the cost of $1.1 million. That's a productivity difference of over 200:1. Johnson credited Minnesota's success to a standardized infrastructure, minimized requirements, and a team of eight capable people.

This is but one example of dramatic performance differences between organizations doing essentially the same thing. Such differences can be found not only in software development, but in many other fields as well. Differences between companies are rooted in their organizational history and culture, their approach to the market, and their ability to capitalize on opportunities. The difference between high performance companies and their average competitors has been studied for a long time, and much is known about what makes some companies more successful than others. Just as in software development, there is no magic formula, no silver bullet2. There are, however, some solid theories about which approaches foster high performance and which are likely to get in the way. Areas such as manufacturing, logistics, and new product development have developed a body of knowledge of how to provide the best environment for superior performance.

We observe that some methods still considered standard practice for developing software have long since been abandoned by other disciplines. Meanwhile approaches considered standard in product development, such as concurrent engineering, are not yet generally considered for software development.

Perhaps some of the reluctance to use approaches from product development comes from unfortunate uses of metaphors in the past. Software development has tried to model its practices after manufacturing and civil engineering with decidedly mixed results. This has been due in part to a naive understanding of the true nature of these disciplines and a failure to recognize the limits of the metaphor.

While recognizing the hazards of misapplied metaphors, we believe that software development is similar to product development, and that the software development industry can learn much from examining how changes in product development approaches have brought improvements to the product development process. Organizations that develop custom software will recognize that their work consists largely of development activities. Companies that develop software as a product or part of a product should find the lessons from product development particularly germane.

The story of the Florida and Minnesota SACWIS is reminiscent of the story of The General Motors GM-10 development, which began in 1982.3 The first model, a Buick Regal, hit the streets seven years later in 1989, two years late. Four years after the GM-10 program began, Honda started developing a new model Accord aimed at the same market. It was on the market by the end of 1989, about the same time the GM-10 Cutlass and Grand Prix appeared. What about quality? Our son was still driving our 1990 Accord twelve years and 175,000 mostly trouble-free miles later.

Studies at the time showed that across multiple automotive companies, the product development approaches typical of Japanese automakers resulted in a 2:1 reduction in engineering effort and shortened development time by one third, when compared to traditional approaches. These results contradicted the conventional wisdom at the time, which held that the cost of change during final production was 1000 times greater than the cost of a change made during design. It was widely held that rapid development meant hasty decision-making, so shortening the development cycle would result in many late changes, driving up development cost.

To protect against the exponentially increasing cost of change, traditional product development processes in US automotive manufacturers were sequential, and relationships with suppliers were arm's length. The effect of this approach was to lengthen the development cycle significantly, while making adaptation to current market trends impossible at the later stages of development. In contrast, companies such as Honda and Toyota put a premium on rapid, concurrent development and the ability to make changes late in the development cycle. Why weren't these companies paying the huge penalty for making changes later in development? One way to avoid the large penalty for a change during final production is to make the right design decision in the first place, and avoid the need to change later. That was the Detroit approach. Toyota and Honda had discovered a different way to avoid the penalty of incorrect design decisions: Don't make irreversible decisions in the first place; delay design decisions as long as possible, and when they are made, make them with the best available information to make them correctly. This thinking is very similar to the thinking behind Just-in- Time manufacturing, pioneered by Toyota: Don't decide what to manufacture until you have a customer order; then make it as fast as possible. Delaying decisions is not the whole story; it is an example of how thinking differently can lead to a new paradigm for product development. There were many other differences between GM and Honda in the 1980's. GM tended to push critical decisions up to a few high-level authorities, while Honda's decision to design a new engine for the Accord emerged from detailed, engineering-level discussions over millimeters of hood slope and layout real estate. GM developed products using sequential processes, while Honda used concurrent processes, involving those making, testing, and maintaining the car in the design of the car. GM's designs were subject to modification by both marketing and strong functional managers, while Honda had a single leader who envisioned what the car be and continually kept the vision in front of the engineers doing the work.

The approach to product development exemplified by Honda and Toyota in the 1980's, typically called 'lean development', was adapted by many automobile companies in the 1990's. Today the product development performance gap among automakers has significantly narrowed. Lean development principles have been tried and proven in the automotive industry, which has a design environment arguably as complex as most software development environments. Moreover, the theory behind lean development borrows heavily from the theory of lean manufacturing, so lean principles in general are both understood and proven by managers in many disciplines outside of software development.

Lean Principles -> Thinking Tools -> Agile Practices

This book is about the application of lean principles to software development. Much is known about lean principles, and we caution that organizations have not been uniformly successful in applying them, because lean thinking requires a change in culture and organizational habits that is beyond the capability of some companies. On the other hand, companies that have understood and adopted the essence of lean thinking have realized significant, sustainable performance improvements.

Principles are guiding ideas and insights about a discipline, while practices are what you actually do to carry out principles.8 Principles are universal, but it is not always easy to see how they apply to particular environments. Practices, on the other hand, give specific guidance on what to do, but they need to be adapted to the domain. We believe that there is no such thing as a 'best' practice; practices must take context into account. In fact, the problems that arise when applying metaphors from other disciplines to software development are often the result of trying to transfer the practices, rather than principles, of the other discipline.

Software development is a broad discipline - it deals with web design and with sending a satellite into orbit. Practices for one domain will not necessarily apply to other domains. Principles, however, are broadly applicable across domains, as long as the guiding principles are translated into appropriate practices for each domain. This book focuses on the process of translating lean principles to agile practices tailored to individual software development domains. At the core of this book are twenty two thinking tools to aid software development leaders as they develop the agile practices that work best in their particular domain. This is not a cookbook of agile practices; it is a book for chefs who are setting out to design agile practices that will work in their domain. There are two prerequisites for a new idea to take hold in an organization:

• The idea must be proven to work operationally, and
• People who are considering adopting the change must understand why it works.

Agile software development practices have been shown to work in some organizations, and in Adaptive Software Development10 Jim Highsmith develops a theoretical basis for why these practices work. Lean Development further expands the theoretical foundations of agile software development by applying well-known and accepted lean principles to software development. But it goes further by providing thinking tools to help translate lean principles into agile practices that are appropriate for individual domains. It is our hope that this book will lead to wider acceptance of agile development approaches.

Guided Tour

This book contains seven chapters devoted to seven lean principles, and thinking tools for translating each principle into agile practices. A brief introduction to the seven lean principles concludes this introduction.

1. Eliminate Waste

Waste is anything that does not add value to a product, value as perceived by the customer. In lean thinking, the concept of waste is a high hurdle. If a component is sitting on a shelf gathering dust, that is waste. If a development cycle has collected requirements in a book gathering dust, that is waste. If a manufacturing plant makes more stuff than is immediately needed, that is waste. If developers code more features than are immediately needed, that is waste. In manufacturing, moving product around is waste. In product development, handing off development from one group to another is waste. The ideal is to find out what a customer wants, and then make or develop it and deliver exactly what they want, virtually immediately. Whatever gets in the way of rapidly satisfying a customer need is waste.

2. Amplify Learning

Development is an exercise in discovery, while production is an exercise in reducing variation, and for this reason, a lean approach to development results in practices that are quite different than lean production practices. Development is like creating a recipe, while production is like making the dish. Recipes are designed by experienced chefs who have developed an instinct for what works and the capability to adapt available ingredients to suit the occasion. Yet even great chefs produce several variations of a new dish as they iterate toward a recipe which will taste great and be easy to reproduce. Chefs are not expected to get a recipe perfect on the first attempt; they are expected to produce several variations on a theme as part of the learning process. 12 Software development is best conceived of as a similar learning process, with the added challenge that development teams are large and the results are far more complex than a recipe. The best approach to improving a software development environment is to amplify learning.

3. Decide as Late as Possible

Development practices that provide for late decision-making are effective in domains that involve uncertainty, because they provide an options-based approach. In the face of uncertainty, most economic markets develop options to provide a way for investors to avoid locking in decisions until the future is closer and easier to predict. Delaying decisions is valuable because better decisions can be made when they are based on fact, not speculation. In an evolving market, keeping design options open is more valuable than committing early. A key strategy for delaying commitments when developing a complex system is to build a capacity for change into the system.

4. Deliver as Fast as Possible

Until recently, rapid software development has not been valued; taking a careful, don't-make-any-mistakes approach has seemed to be more important. But it is time for 'speed costs more' to join 'quality costs more' on the list of debunked myths.13 Rapid development has many advantages. Without speed you cannot delay decisions. Without speed you do not have reliable feedback. In development, the discovery cycle is critical for learning: Design, implement, feedback, improve. The shorter these cycles are the more that can be learned. Speed assures that the customer gets what they need now, not what they needed yesterday. It also allows them to delay making up their mind about what they really want until they know more. Compressing the value stream to as short a service time as possible is a fundamental lean strategy for eliminating waste.

5. Empower the Team

Top-notch execution lies in getting the details right, and no one understands the details better than the people who actually do the work. Involving programmers in the details of technical decisions is fundamental to achieving excellence. The people on the front line combine the knowledge of the minute details with the power of many minds. When equipped with necessary expertise and guided by a leader, they will make better technical decisions and better process decisions than anyone can make for them. Because decisions are made late and execution is fast, it is not possible for a central authority to orchestrate activities of workers. Thus, lean practices use pull techniques to schedule work, and contain local signaling mechanisms so workers can let each other know what needs to be done. In lean software development, the pull mechanism is an agreement to deliver increasingly refined versions of working software at regular intervals. Local signaling occurs through visible charts, daily meetings, frequent integration and comprehensive testing.

6. Build Integrity In

A system is perceived to have integrity when a user thinks - "YES! That is exactly what I want. Somebody got inside my mind!" Market share is a rough measure of perceived integrity for products, because it measures customer perception over time.14 Conceptual integrity means that the system's central concepts work together as a smooth, cohesive whole, and it is a critical factor in creating perceived integrity.15 Software needs an additional level of integrity - it must maintain its usefulness over time. Software is usually expected to evolve gracefully as it adapts to the future. Software with integrity has a coherent architecture, scores high on usability and fitness for purpose, is maintainable, adaptable and extensible. Research has shown that integrity comes from wise leadership, relevant expertise, effective communication and healthy discipline; processes, procedures, and measurements are not adequate substitutes.

7. See The Whole

Integrity in complex systems requires a deep expertise in many diverse areas. One of the most intractable problems with product development is that experts in any area (e.g. database or GUI) have a tendency to maximize the performance of the part of the product representing their own specialty, rather than focusing on overall system performance. Quite often, the common good suffers if people attend first of all to their own specialized interests. When individuals or organizations are measured on their specialized contribution, rather than overall performance, sub-optimization is likely to result. This problem is even more pronounced when two organizations contract with each other, because people will naturally want to maximize the performance of their own company. It is challenging to implement practices that avoid sub-optimization in a large organization, and an order of magnitude more difficult when contracts are involved.