精益软件开发(Lean Software Development)

Introducing Lean Software Development 

Introduction

As software systems grow more complex and more people become involved, managing software development becomes increasingly difficult. For years, enterprises have been told that to cope with the increased complexity, they need to add more measurements, more controls, more checks and balances, more rigor. To ensure that people do as they are told, many enterprises expend significant resources on process compliance audits. The result should not be surprising: organizational cultures with an increasing emphasis on forecasting and administration, and a decreasing focus on learning and innovation.

Somehow the customer has been neglected in our eagerness to predict and control software development. Many organizations have evolved a mentality that views developers as commodity resources with predictable performance rates, much like pieces of machinery. But developing software-intensive products and services is anything but mechanical in nature. It is an exercise in learning and problem solving, albeit often on a huge scale. What we need is a way of thinking about software development that emphasizes rapid organizational learning and directs all our efforts towards generating customer value. That is precisely what Lean Software Development seeks to do.

The notion of the "Lean Enterprise" originated at Toyota after the Second World War. Over the years it evolved into an industry-independent management philosophy focusing on delivering more customer value while at the same time improving growth and profitability. There are five core Lean principles:

• Value: understand what adds value for the customer
• Value Stream: understand how the organization generates customer value
• Flow: maximize speed and minimize cost by achieving continuous flow
• Pull: deliver value on a just-in-time basis based on actual customer demand
• Perfection: continuously improve the performance of your value streams

These principles form the basis for a large number of enabling practices - powerful tools and techniques that help enterprises maximize customer value and avoid waste. Companies implementing Lean have experienced up to 50% cost reductions and 95% lead time reductions. In this article we will discuss how Lean principles can be applied to managing software development.

Lean Principle #1: Value is defined by the customer

Many product managers do not really understand how the customer's business makes a profit. The justification for a product feature should be that it adds value by helping the customer perform better in some quantifiable way, such as improving profits or sales, or saving time or money.

Anything that does not directly contribute value to the customer is waste. Perhaps the single biggest source of waste in software development is unused functionality. Only 20% of features in enterprise software applications are used on a frequent basis, 45% are never used, and 19% are rarely used, according to the Standish Group Other common sources of waste in software development include: include defects (rework and testing), unnecessary paperwork, waiting, task switching, waste of human talent, unused metrics, and improper use of software tools.

By analyzing your customers' marketplaces and determining profit and growth bottlenecks, you are in a much better position to understand where and how you can add real value. If possible, do your research in a way that involves your customers - visit with them, form joint analysis teams, write joint reports, etc. It is not enough to purchase market study reports from reputable analyst firms. There is no substitute for doing your own homework, and doing it thoroughly.

Lean Principle #2: Learn to see your Value Stream

A value stream is the set of activities required to develop and deliver a product or service. It usually involves multiple processes, teams, and departments. Because the value stream involves everything the organization does to develop products, we avoid looking at individual functional departments such as Engineering and Marketing in isolation. In contrast with traditional approaches to performance improvement, Value Streams allow us to see product development as an integrated whole.

   

Figure 1: A company can be viewed as a portfolio of value streams

If we look at each of the processes in a value stream and ask who is responsible for day-to-day performance as well as process improvement, the answer is usually that no single person has overall responsibility. Instead the responsibility is distributed across several functional managers, who may have conflicting interests. This is why process improvement efforts often get "out of synch" with day-to-day execution. By appointing a Value Stream Manager as responsible for both day-to-day results and for coordinating process improvement efforts for each value stream, we get clear accountability for execution excellence. In commercial product development, the product manager role is the most natural job to expand in this manner. In an IT organization, it might be a project manager In a defense/aerospace company, each program usually has multiple value streams, so a value stream manager is likely to be a mid-level manager reporting directly to the program manager.

Lean Principle #3: Flow - Maximize speed and minimize cost by achieving Continuous Flow

Once we have discovered what our value streams actually look like, we can begin to look at how efficiently they generate customer value. The concept of flow requires us to rethink how we utilize elapsed time. How much of the time elapsed is actually spent on activities that add value to the customer?

Flow implies a significant change of perspective. We are no longer so interested in how busy we are keeping our people, or how "efficiently" they perform individual tasks. Instead, our primary focus is on making efficient use of elapsed time. Flow is what occurs when we utilize elapsed time while adding value to the customer. Continuous flow means that individual units of customer value (a product function, for example) move through the value stream with no time spent on non-value-added activity.

In a typical organization, only 1/3 of the 24-hour day is spent on working, the rest is downtime. During downtime, there is no flow, because no one is working. But what about the time when we are actually working? Many companies still organize their product development processes as a sequence of distinct stages, such as concept development, requirements definition, architecture design, etc. Each of these stages results in a big batch of partially completed work. Partially complete work constitutes in-process inventory, which is a form of waste. Inventory clogs up the development pipeline, ties up resources, and increases the time it takes to respond to customer needs.

Figure 2: Lead time for an individual software feature

Smaller batches of work lead to less inventory, which means that less time is lost due to waiting. This is why iterative development is faster than the traditional waterfall approach. But iterative development is not a panacea. Aside from waiting stemming from big batches, inhibitors to flow in software development include:

• Poor or missing specifications - lack of information brings work to a standstill
• Inflexible architectures - these can make it awkward to progress incrementally
• Defects - they make us waste time on non-value-added rework and retesting
• Unbalanced resources - these cause inventory pile-ups and waiting
• Poor configuration management - not being able to access artifacts causes delays
• Unreliable builds - not being able to reliably build releases can halt progress
• Task switching - individuals waste time trying to juggle multiple activities

In software development, as much as 95% of lead time and 80% of the development effort are NOT value-added from the customer's perspective. Even in organizations using "Agile" methods with smaller iterations, there are significant opportunities for improving flow. By improving flow, we not only improve speed, we also achieve substantial cost savings. This is because non-value-added activities, including downtime and waiting, consume valuable cash.

Lean Principle #4: Pull - synchronize development with the actual demand rate

Even with continuous flow, if we cannot deliver functionality on time, the result is that the customer is left waiting, as is our financial reward. If we deliver functionality that is not (yet) needed, we are also wasting time and money. To avoid both types of waste, we need actual customer demand to explicitly drive the content, volume, and tempo of our work in real time.

nstead of "pushing" work through the value stream based on forecasted demand and up-front-planning, Pull means that we only build something when it is actually needed by a customer. In other words, we want customer(s) to "pull" new product releases from the value stream. Traditional plan-driven work is replaced by demand-based work, reducing inventory and improving our ability to react very quickly to customer needs.

In many cases customers cannot take deliver of new product releases as quickly as we are capable of releasing them. To avoid big batches of work, this requires us to establish "artificial pull", where internal releases are produced based on feedback from a representative subset of our customers. Even if releases are not deployed by all of our customers, frequent releases with customer feedback substantially reduce the risk of developing irrelevant functionality or design solutions that turn out not to work well practice.

Figure 3: Artificial pull

If we want customer feedback to drive our development efforts, we must address a number of practical issues, including the selection, composition and priority of customers providing feedback. Unless we are developing software for a single customer, we may be dealing with very large numbers of customers. In such a situation we must carefully choose a representative group of customers, and carefully weight the relative priority of their feedback. Another practical issue is infrastructure - if we are going to deliver and deploy new versions frequently, we must deploy the necessary infrastructure to make this work smoothly. Frequency of feedback is also a key issue - the more often we can get customer feedback the better, but this means the participating customers must be convinced of the necessity to stay involved throughout the effort.

Frequent customer feedback requires trust. One way to establish such trust is to visibly invest in an effort to understand the customers' business problems and opportunities. We must also explain how the feedback will be used to add real value to customers. To retain and enhance the trust that has been built, we must show again and again that we act promptly on the feedback we receive. In some situations it also makes sense to contractually formalize the understanding that has been reached. This is especially true for custom software development. Such a contract may also tie continued funding to actual customer value delivered.

Pull has significant implications for the way we approach software design. In areas where there is uncertainty about the feasibility of design solutions or where customer needs can change rapidly, we must keep our designs open-ended. Sometimes we may even pursue multiple strategies concurrently as a way of dealing with design risk. Holding multiple options open and narrowing down our choices as we reduce uncertainty is referred to as Set-Based Concurrent Engineering, and it is a powerful approach to designing complex products in a very short time.

Lean Principle #5: Perfection - Continuously improve the performance of your value streams

Companies implementing Lean provide teams with skills and incentives to relentlessly identify and remove waste. Because the focus of improvement is on entire value streams, we avoid addressing local bottlenecks that may not have much impact on overall economic performance. A typical improvement process used by a cross-functional change team to improve a value stream's performance might look as follows:

1. (Re-)Define Customer Value 2. Map the value stream 3. Identify sources of waste 4. Design "future state" of value stream (what we want it to look like) 5. Implement the future state 6. Present results

Open-book metrics tied to financial performance show how teams and their value streams are performing. To encourage a higher rate of improvement, teams can be engaged in friendly competition, but they should be required to share their innovations on a regular basis.

For continued performance improvement, an organization has to improve its ability to harvest, create, and share knowledge. This can be done on several levels. Within teams, try cross-training team members and occasionally switching roles. Rotating people between product teams can also be helpful. Advanced practitioners such as Toyota and Nokia organize groups around areas of domain expertise. Each domain group encodes its expertise in the form of continuously improving iterations of reusable components

For additional learning across teams, consider establishing Communities of Practice in strategic areas such as Customer Relationship Management, Software Design, Usability, Finance, Strategy, Lean Thinking, and Team Leadership. Such groups should combine ideas from other companies with lessons learned from past and current projects.

Conclusion

Lean Software Development provides a management philosophy together with a set of practical tools for designing and delivering software-intensive products and services. These tools enable us to select design solutions, methods, design tools, and organizational structures based on fitness for purpose. That purpose is to produce value for the customer with minimum waste for us.

There is a wonderful supermarket of tools, methods, and techniques from decades of progress in software engineering management. Lean does not invalidate or validate any of these. Instead, it gives us the wisdom to shop wisely and employ just the right combination of remedies needed to maximize customer value, minimize waste, and produce real top-line and bottom-line results.