Overview

Lean Software Development

The Lean Imperative

The gold standard of productivity is set by lean organizations: Toyota, Wal-Mart, Dell. Lean organizations concentrate on the rapid flow of value because they have discovered the fundamental principle of Lean Six Sigma: quality, speed, and low cost are tightly linked; in fact, they work together to provide world class performance.

High Productivity
80% of the value of most systems is delivered by 20% of the features, and up to two-thirds of the features of most systems are rarely, if ever, used. The easiest way to develop better software faster is to Write Less Code. If we would stop spending time specifying, designing, developing, testing, documenting and maintaining features that are not going to prove particularly useful to our customers, we could focus on providing them with a significant competitive advantage.

Rapid Response
The maturity of an organization is measured by the speed with which it can repeatedly and reliably execute its core processes. Rapid response is a primary driver of competitive advantage. How fast does your organization routinely respond to a customer need? Are your competitors faster?

Superior Quality
The fundamental discipline of lean software development is testing. Tests define the requirements, drive the design, and document the system. Software should be built, integrated, and checked out with a test harness every day. Best-in-class organizations write the tests first, and deliver the test harness as a part of the code base.

Lasting Value
80% of the code in any system is developed after first release to production. Some of the best software products have been evolving for a decade. Robust, responsive software that stands the test of time is created by developers who have a deep understanding of the domain.

The Lean Agenda

The inventory of software development is partially done work: requirements that are not proven, analysis that is not reduced to code, code that is not tested, sub-systems that are not integrated, systems that are not released to production. Hidden in this inventory are most of the risks of a software development effort. Inventory reduces cash flow, grows obsolete, and worst of all, inventory hides problems. Lean Thinking for Software Development is all about driving down this risky inventory and putting it to work providing customer value as quickly as possible.

Customer Focus
Waste is anything that does not provide timely customer value. Have you identified who your customers are? Do you know what these customers really want? Do you know how long it takes to deliver that value? To find out how well your organization delivers customer value, start by analyzing the value stream.

Process Flow
An agile software development team can add features in any order and can release a working version of the software at the end of any iteration.¹ When manufacturing plants learned how to make any product in any order, Just-in-Time manufacturing became practical. Now that software developers have learned to add any feature in any order, and deliver working software in two-weeks or thereabouts, Just-in-Time software development is possible.

Local Responsibility
In really efficient organizations, the job of management is to organize things so that people can figure out what to do without being told. Effective workflow, visual controls and regular training build expertise in the workforce, allowing responsibility to be moved to the point where wisdom lies: the place where work is being done. The best software is designed by developers and domain experts who jointly develop a deep understanding of the domain.

Data-Based Decisions
When the goal is to hit a moving target, learning-based software development is the approach to use. Experienced development teams can implement individual features in any order and deliver deployable code in less than a month. Learning-based software development deploys small feature sets in priority order, providing both rapid feedback and immediate business value. Successful software product companies have used have used this approach for many years.

Lean Implementation

The road to success does not lie in copying the practices of successful organizations; it lies in developing a profound understanding of customers, contributors and the competitive context of the business.

	The Value Stream Start a clock when a customer recognizes a critical need. Measure the average time it takes to put this problem on the top of a priority list, develop a solution, make sure it works, deploy the solution, and actually solve the problem. Is your solution delivery cycle time measured in days, weeks, months, or years? Where are the time sinks? Recognize that these time sinks decrease value, increase costs and lower quality.
	Building Block Disciplines 1. A clean work environment, organized computer files, solid backup and upgrade procedures 2. Standards for naming, coding, GUI interfaces, etc. 3. An effective version control system 4. A rapid build process 5. Daily integration of all new code 6. Tests written at the time of coding, automated for daily testing, and maintained for the life of the system
	Change-Tolerant Software Things are simple for a start-up company developing its first product; there are no interfaces or compatibility issues to deal with. But as products and features are added, complexity grows exponentially. Complexity calcifies code; complex software becomes brittle and breaks easily. The way to deal with complexity is to build change tolerance into the development process - use a process that keeps code simple and subtle. The first step is to build test harnesses as part of the development process, so code can be changed regularly and safely. The next step is to continually simplify the code as development proceeds: the minute duplication appears, the code should be refractored using standard design patterns. Finally, all new code should be integrated into the code base daily, if not more often.

Managing The Pipeline
We've seen quite a few ideas for managing a software development portfolio - but few that work very well. The problem is that most multi-project scheduling systems seem to be founded on an attempt to increase 'resource' utilization. First of all, people aren't fungible resources; they develop expertise in specific areas, they care about following their work to a successful outcome, and they work a lot better when they tell the computer what they are going to do next rather than the other way around. Secondly, we know from simple queuing theory that trying to maximize utilization will slows things down - you know this if you've ever been stuck in traffic. Third, complex scheduling systems don't work in manufacturing and they don't work in construction because they cannot take variability into account. Rather than wishfully thinking that variability can be conquered, effective manufacturing and construction sites use pull systems to schedule work. Since software is a development process, variability is fundamental to its success, complex scheduling systems are never going to work very well.

The Software Workcell & The Visual Workplace
In Lean manufacturing, complexity is dealt with by simplifying the problem first, and automating second. The first step in simplification is to move manufacturing equipment into workcells, so that a product can flow from the start of the workcell to the end without any transportation or delay. In software development, we use cross-functional teams to realize the same result. A single, preferably co-located team with all the capabilities to design, develop, and deploy the software is the basic software workcell. This team should know what to do without being told, it should be obvious from the visual clues in the workplace.

Metrics
Having the right performance measures is the key to leveraging a strategy throughout the organization. All too often, the goals of one department are not aligned with the goals of a neighboring department, and decreasing the organization's ability to deliver value effectively. Don't add new measurements to solve this problem - instead, decrease the number of measurements and raise them up one level. When people are measured based on their span of influence, rather than their span of control, they have an incentive to collaborate for to overall good of the organization.