What is Lean Software Development?
The Lean Software Development methodology was adapted from the Toyota Production System which was introduced by Toyota way back in the 1980s. The aim of the Toyota Production System was to identify and remove inefficiencies in processes, systems or services and to eliminate waste wherever possible.
It was popularized by Mary and Tom Poppendieck, who looked at how Lean could be adapted to software development in their influential book “Lean Software Development: An Agile Toolkit” which was published in 2003.
Upfront Disclaimer: If you click on the link and buy the book, then I will make a small commission through Amazon’s Affiliate program which helps to pay for the running of this site – I just want to be open and honest about it. 🙂
The Poppendiecks took the 7 core principles of Lean and adapted them specifically for software development; the basic notion being to preserve value with less work where value reflects something that the customer would be willing to pay for.
Any other costs or expenditures are considered to be “waste” and should be removed wherever possible in order to optimise workflow, improve efficiency and effectiveness.
Importantly, the results of any improvements should be measurable and observable.
The Seven Principles of Lean Software Development
The principles are based around the central idea that less is more, and they aim to simplify and streamline every part of the software development process.
The approach is to find efficiencies that can be applied and to eliminate waste at every level, including each individual, every department, interdepartmental operations, the organization as a whole, and the relationships of the organization with customers and suppliers.
The 7 Principles of Lean Software Development may be summarized as follows:
- Eliminate Waste
- Create Knowledge
- Decide as Late as Possible
- Deliver as Fast as Possible
- Empower the Team
- Build Integrity In
- See the Whole
Let’s look at each of these principles in more detail.
Principle 1: Eliminate Waste
- Waste is anything which doesn’t contribute to customer value. Some examples of this could be:
- Ambiguous requirements
- Discarded work
- Repeated work
- Excess features
- Extra/unneeded documentation
- Slow communication
- Effective Agile teams seek out and eliminate waste
- Lightweight work management systems
- Value Stream Mapping
Principle 2: Create Knowledge
- Understand what the service is for, not just what the service is and how it works!
- Solve the Problem
- Search, Discover, Share, Improve
- Feedback Mechanisms drive improvements to
- Needs understanding
- Coding (refactoring )
- Iterative Development drives ongoing discovery and “evolution” of requirements.
- Whole “vertical slices” of solutions
- Continuous integration and testing
The Lean development principle of Create Knowledge is seems simple, but requires discipline and commitment to implement. Lean teams need to provide the tools and capabilities to properly document and retain valuable learning, so that it can be used to improve subsequent development cycles.
This can be done in a variety of ways, for example you could choose some of the following tools:
- Pair Programming
- Code reviews
- Documentation such as user guides and quick guides as well as formal design documents
- Wiki – a great tool to build the knowledge base incrementally made up of contributions from all participants
- Thoroughly commented code
- Knowledge sharing sessions such as breakfast meetings and open project forums as well as specific knowledge transfer presentations
- Tools and software used to manage requirements or user stories
Principle 3: Decide as Late as Possible
- High value features first
- Adaptation as changes and risks are identified
- Avoid nasty surprises late in the project life-cycle
- Use iterative planning to decide on “what to build” just in time to plan and execute a sprint/iteration
- Less Detail (because we don’t really know what we think we know)
- Flexibility drives options later that increase value
- Decide at “The Last Responsible Moment” (Poppendieck, 2003)
- Means deciding with the best available information
Principle 4: Deliver as Fast as Possible
- Get high value solutions in customer hands quickly to drive benefits realization
- Work-in-progress may have unknown defects (aka, we never actually know if we’re 70% done)
- Faster iterations allows for more time for key decisions (we can wait later!)
- Pull systems allow for just-in-time decision making, and self-organization allows the teams to figure out what actually needs to be done
- Use queuing theory to “keep things moving”; smaller units of work are completed more quickly
- Demonstrate improved “time to value” and cost/value balance (Agile models usually are cheaper anyway in the medium term)
Principle 5: Empower the Team
- Focus on the whole solution, not just the components
- Enable the team to lead
- Design working activities and processes
- Identify and drive improvements to products and processes
- Management’s job is to coach, assist, and empower the team
- Self-directed teams are generally more motivated
- Clear purpose, goals, and objectives
- Engagement with all key stakeholders
- “See the value”- what is the bigger purpose?
- Safety and openness combined with skills and results
- Manager vs Leader (Poppendieck, 2003)
- To lead we must
- Cope with Change
- Set Direction
- Align People
- Enable Motivation
- Project Managers must become Project Leaders
- To lead we must
Principle 6: Build Integrity In
Integrity takes two forms:
- Perceived Integrity: affected by the customer’s experience of the system
- Conceptual Integrity: the system’s central concepts work together as a smooth, cohesive whole
|How intuitive is the system?
|Does it have an effective balance between flexibility, maintainability, efficiency, and responsiveness?|
|How does it keep up with changes in the domain?||Can the system evolve and mature?
|How well does it solve problems?||Does it have a consistent set of design principles?|
|How much market share does it have?||Is usability consistent?|
|How much mind share does it have?||A prerequisite for perceived utility|
Principle 7: See the Whole
- Systems thinking means maintaining the flexibility and interactions among its components
- Avoid sequential rules that may fix one problem but create many others
- Sequential rules act as blockers
- Limit growth and use
- Drive constraints to other areas of the system
- Tend to “cure” symptoms and ignore the underlying problem
- Tend to produce less optimal results (lose/lose negotiating)
- Measures and metrics drive behaviour, so be careful!