Lean software development (LSD) is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the Agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices derived from the experience, that supports agile organizations.

Lean principles for software development are: 1. Eliminate waste – anything which doesn’t add value to the end product 2. Increase feedback – iterate so you can get early feedback 3. Delay commitment – so you can decide with the best knowledge 4. Deliver fast – so you can afford to delay commitment 5. Empower the team – they’re the ones closest to the information 6. Build integrity in – have an integrated product team, use refactoring to keep the code clean, and use test-driven development to make sure it’s all tested and you have a reason for doing everything. 

Lean = continuous improvement
XEROX :Obviously a bigger name. They have applied lean to manufacturing operations, and are now apparently applying it to software development for their high end document systems. Not much info. (www.xerox.com)
Their CTO, Jeff Sutherland, is one of the creators of Scrum. From which we can see, and from what we have heard , this is one of the most advanced and successful applications of lean to software development.. (www.patientkeeper.com)
HELPHIRE:They use Lean in “Learning About Lean” we can’t get idea how far they are or what exactly they are doing with lean. (www.helphire.com)
Kanban is a lean method to manage and improve work across human systems. This approach aims to manage work by balancing the demands with available capacity, and improving the handling of system level bottlenecks.

Work items are visualized to give participants a view of progress and process, from start to finish usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into the process when requested.

In knowledge work and software development, this provides a visual process management system which aids decision-making about what, when and how much to produce. Although the underlying  HYPERLINK “https://en.wikipedia.org/wiki/Kanban” o “Kanban” Kanban method originated in lean manufacturing (inspired by the Toyota Production System) it is used mainly for software development and technology related work. However Kanban can be applied to any area of work, and it can even be combined with other methods or frameworks such as Scrum.

The basic principles of Kanban for software engineering
Limit Work in Process (WIP)
Pull value through (with WIP limit)
Make it visible (Visual Control)
Increase throughput
Fixed Kanban Backlog
Quality is embedded in (not inspected in)

Flexibility in Planning:
Kanban provides improvements in the workflow. With visual representation of the
workflow, speed of moving from one task to another is reduced. This is accomplished
through the creation of clearly marked flow lanes, Kanban cards and clearly marked
columns to indicate where each item is in the workflow. If a task needs longer duration, it
is allowed to execute without hindrance, and at the same time, the tasks that are
completed will flow to the next state.

This allows –
Sufficient duration for longer tasks that cannot be broken down logically.

Preservation of value of such longer tasks.

Effort required by each role to be expended.

Continuous flow of the tasks that are completed without wait time.

Hence, planning is flexible and not time-boxed

Limits Work-In-Progress(WIP):
Explicit limits are assigned to number of items that can be in progress at each workflow
state, indicated by a column.

This allows –
Reducing wait time.

Avoiding stress on resources at a workflow state.

Identifying bottlenecks causing an item to be in a workflow state than the
anticipated time (usually average cycle time) immediately.

Resolving bottlenecks with collaboration of the entire team.

Decreasing dependencies in completing a task by splitting it into sub-tasks, so that
the sub-task is tracked independently.

Pull Approach:
When you have two teams and the first one is performing better than the second one, it
is likely that it pushes more work than the other can actually handle. This often creates
friction between the teams. A solution to this is the Pull approach.

In Pull Approach, the next team pulls work only when it is ready for it. Pull Approach is
implemented by adding a buffer with limited capacity between the two teams.

The benefits of Pull Approach are –
Avoids piling-up of work.

Reduces wait time.

Facilitates a team to maintain constant pace and focus on quality.

Provides resource balancing.

Minimize Cycle Time:
The cycle time for each task is measured and the process is optimized to reduce the cycle

The bottlenecks are identified immediately and resolved collaboratively by the
entire team.

The correction loops are considered to reduce rework.

Continuous Delivery:
Benefits of continuous delivery are –
Short release cycles result in continuous delivery of growing product at regular

Continuous interactions with the customer.

To understand what customer wants.

Not to produce anything that the customer does not need.

Feedback on delivered modules.

Limited requirements in each release cycle.

Developers are not overloaded with requests. This enables them to focus on the

There is no partially completed work.

Focus is on finishing work than on starting work.

This enables focus on sustaining pace and quality of the product.

Deliver before the customer changes mind.

Optimize flow of Work from beginning to end.

Helps in incremental process improvements.

Value Stream:
The Value Stream consists of all actions required to bring a project from creation to completion.

The actions can –
Add Value to the project
Add no Value, but unavoidable
Add no Value, avoidable (termed as waste)