Lean Software Development

The term Lean Software Development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck The book presents the traditional Lean principles in a modified form, as well as a set of 22 tools and compares the tools to agile practices. Mary and Tom's involvement in the Agile software development community, including talks at several Agile conferences has resulted in such concepts being more widely accepted within the Agile community. Examples of this would be the use of the term "Lean-Agile" by consulting firms such as NetObjectives and C.C. Pace, as well as the inclusion of some of these concepts

Lean Principles
Lean development could be summarized by seven principles, very close in concept to lean manufacturing principles.

Eliminate waste
The principle to eliminate waste (or muda, which is a specific kind of waste in Toyota's lexicon) has been borrowed from the ideas of Taiichi Ohno – the father of the Toyota Production System. He has distinguished the following activities as waste:
.an automobile part stored and waiting for use
.producing anything not immediately needed
.unneeded motion of components
.waiting for other parts to be produced
.extra processing steps in manufacturing
.defects (lower quality)
In other words, applied to lean thinking, everything not adding value to the Customer is considered to be waste. This includes:
.unnecessary code and functionality
.delay in the software development process
.unclear requirements
.bureaucracy
.slow internal communication
In order to be able to eliminate waste, one should be able to recognize and see it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra processes and features not often used by Customers are waste. Waiting for other activities, teams, processes is waste. Defects and lower quality are waste. Managerial overhead not producing real value is waste. A value-stream mapping technique is used to distinguish and recognize waste. The second step is to point out sources of waste and eliminate them. The same should be done iteratively until even essential-seeming processes and procedures are liquidated.

Amplify learning
Software development is a continuous learning process with the additional challenge of development teams and end product sizes. The best approach for improving a software development environment is to amplify learning. The defects accumulation should be prevented by running tests as soon as the code is written. Instead of adding more documentation or detailed planning different ideas could be tried by writing code and building. The process of user requirements gathering could be simplified by presenting to the end-users user screens and getting their input.
The learning process is speeded up by usage of short iteration cycles – each one coupled with refactoring and integration testing. Increasing feedback and short feedback sessions with Customer help in realizing the current phase of the development and adjusting the efforts for future improvements. During those short sessions both Customer representatives and the development team learn more about the domain problem and figure out possible solutions for further development. Thus the Customers realize better their needs, based on the working so far result of the development and the developers learn better how to satisfy those needs. Another idea in the communication and learning process with Customer is the set-based development – it concentrates on the communication of constraints of the future solution and not the possible solutions, thus promoting the birth of the solution via the dialog with the Customer.

Decide as late as possible
As software development is always associated with definite level of uncertainty, better results could be achieved with an options-based approach, thus delaying decisions as much as possible until they could be made based on facts and not uncertain future prediction and assumptions. The more complex a system is, the more capacity for change should be built into it, thus enabling delayed important and crucial commitments. The iterative approach promotes this principle – the ability to adapt to changes, correct mistakes, which might be very costly if discovered after the release of the System.
An agile software development could be considered as advancing in the time building of options for the Customers, thus delaying the crucial decisions until they have realized their needs better. This allows also the later adapting to the changes in the technology environment and the prevention of costly earlier technology bounded decisions. This does not mean that no planning should be involved – on the contrary, the planning activities should be concentrated on planning the different options and adapting to the current situation, as well as clarifying confusing situations with establishing patterns for rapid action. Evaluating different options is effective as soon as it is realized that they are not free, but provide the needed flexibility for late decision making.

Deliver as fast as possible
In the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better the learning and communication within the team. Without speed, decisions cannot be delayed. Speed assures the fulfilling of the Customer's present needs and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require until they gain better knowledge. Customers value rapid delivery.
The Just-in-Time production ideology could be applied to software development, recognizing its specific requirements and environment. This is achieved by presenting the needed result and letting the team organize itself and divide the tasks for accomplishing the needed result for a specific iteration. At the beginning, the Customer provides the needed input. This could be simply presented in small cards or stories – the developers estimate the time needed for the implementation of each card. Thus the work organization changes into self-pulling system – each morning during a stand-up meeting, each member of the team reviews what has been done yesterday, what is to be done today and tomorrow, and prompts for any inputs needed from colleagues or the Customer. This requires transparency of the process, which is also beneficial for team communication. "Another key idea in Toyota's Product Development System is set-based design. If a new brake system is needed for a car, for example, three teams may design solutions to the same problem. Each team learns about the problem space and designs a potential solution. As a solution is deemed unreasonable, it is cut. At the end of a period, the surviving designs are compared and one is chosen, perhaps with some modifications based on learning from the others - a great example of deferring commitment until the last possible moment. Software decisions could also benefit from this practice to minimize the risk brought on by big up-front design.

Empower the team
There has been a traditional belief in most businesses about the decision-making in the organisation – the managers tell the workers how to do their own job. In a Work-Out technique, the roles are turned – the managers are taught how to listen to the developers, so they can explain better what actions might be taken, as well as provide suggestions for improvements. Most experienced project managers[who?] have simply stated the key for a successful project – "Find good people and let them do their own job."
Another mistaken belief has been the consideration of people as resources. People might be resources from the point of view of a statistical data sheet, but in software development, as well as any organisational business, people do need something more than just the list of tasks and the assurance that they will not be disturbed during the completion of the tasks. People need motivation and a higher purpose to work for – purpose within the reachable reality, with the assurance that the team might choose its own commitments. The developers should be given access to Customer; the team leader should provide support and help in difficult situations, as well as make sure that skepticism does not ruin the team’s spirit.

Build integrity in
The ever demanding Customer needs to have an overall experience of the System – this is the so called perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive its use is, price and how well it solves problems.
Conceptual integrity means that the system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency, and responsiveness. This could be achieved by understanding the problem domain and solving it at the same time, not sequentially. The needed information is received in small batch pieces – not in one vast chunk with preferable face-to-face communication and not any written documentation. The information flow should be constant in both directions – from Customer to developers and back, thus avoiding the large stressful amount of information after long development in isolation.
One of the healthy ways towards integral architecture is refactoring. The more features are added to the System, the more loose the starting code base for further improvements. As described above in the XP agile method refactoring is about keeping simplicity, clarity, minimum amount of features in the code. Repetitions in the code are signs for bad code designs and should be avoided. The complete and automated building process should be accompanied by a complete and automated suite of developer and customer tests, having the same versioning, synchronization and semantics as the current state of the System. At the end the integrity should be verified with throughout testing, thus ensuring the System does what the Customer expects it to.

See the whole
Software systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend to accumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages of development, the root causes of defects should be found and eliminated. The larger the system, the more organisations that are involved in its development and the more parts are developed by different teams, the greater the importance of having well defined relationships between different vendors, in order to produce a system with smoothly interacting components. During a longer period of development, a stronger sub- contractor network is far more beneficial than short-term profit optimizing, which does not enable win-win relationships.
Lean thinking has to be understood well by all members of a project, before implementing in a concrete, real-life situation. “Think big, act small, fail fast; learn rapidly” – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles along the whole software development process. Only when all of the lean principles are implemented together, combined with strong “common sense” with respect to the working environment, is there a basis for success in software development.

Lean Software Practices
Lean software development practices, or what the Poppendiecks call "tools" are expressed slightly differently from their equivalents in agile software development, but there are parallels. Examples of such practices include:
.Seeing waste
.Value Stream Mapping
.Set-Based Development
.Pull Systems
.Queuing Theory
.Motivation
.Measurements
Some of the tools map quick easily to agile methods. Workcells, for example, are a main tenet of lean. These are expressed in agile methods as cross-functional teams.