Lean development is the application of Lean principles to software development. Lean principles got their start in manufacturing, as a way to optimize the production line to minimize waste and maximize value to the customer. These two goals are also relevant to software development, which also:
- Follows a repeatable process
- Requires particular quality standards
- Relies on the collaboration of a group of specialized workers
Of course, there are some major differences between manufacturing and software development, as well; namely, that manufacturing deals with the production of physical goods, while the value being created in software development is created within the mind of the developer.
Applying Lean principles to knowledge work requires a shift in mindset in terms of how value, waste, and other key Lean concepts are defined. Learn how these 7 Lean principles apply to software development practices.
AgilePlace Free Trial: AgilePlace Online Kanban Software
Sign up for a 30-day free trial and you and your team can start building online Kanban boards today. Experience for yourself how AgilePlace supports continuous delivery initiatives, eliminates waste and improves your team’s delivery processes and speed.
Start your Free Trial • AgilePlace Free Trial7 Lean Development Principles
The seven Lean principles are:
- Eliminate waste
- Build quality in
- Create knowledge
- Defer commitment
- Deliver fast
- Respect people
- Optimize the whole
In their book, Lean Software Development: An Agile Toolkit, Mary and Tom Poppendieck outlined how these Lean principles can be applied to software development. Here is a brief summary of each of these principles, as well as practical tips on how to apply them in software development.
Eliminate waste
One of the key elements of practicing Lean is to eliminate anything that does not add value to the customer. There are seven wastes (or muda) defined in the Toyota school of Lean manufacturing. They are:
- Over-production: Manufacturing an item before it is required
- Unnecessary transportation: Moving inventory from place to place, which puts it at risk for damage without adding any value
- Inventory: Holding inventory adds cost without adding any value to the customer; excess inventory takes up valuable space, increases lead times, and delays innovation
- Motion: Literally refers to unnecessary movement of workers on the shop floor
- Defects: Quality issues result in rework or scrap and can add tremendous additional costs to organizations who don’t habitually find ways to eliminate sources of defects
- Over-processing: Using advanced, expensive tools to do what could be done with simpler tools
- Waiting: When inventory waits between value-adding steps
Tom and Mary Poppendieck translated those wastes to software development. Each of these wastes should be systematically eliminated in order to maximize customer value:
- Unnecessary code or functionality: Delays time to customer, slows down feedback loops
- Starting more than can be completed: Adds unnecessary complexity to the system, results in context-switching, handoff delays, and other impediments to flow
- Delay in the software development process: Delays time to customer, slows down feedback loops
- Unclear or constantly changing requirements: Results in rework, frustration, quality issues, lack of focus
- Bureaucracy: Delays speed
- Slow or ineffective communication: Results in delays, frustrations, and poor communication to stakeholders which can impact IT’s reputation in the organization
- Partially done work: Does not add value to the customer or allow team to learn from work
- Defects and quality issues: Results in rework, abandoned work, and poor customer satisfaction
- Task switching: Results in poor work quality, delays, communication breakdowns, and low team morale
Build quality in
It might seem self-evident; every team wants to build quality into their work. But unless this is part of a disciplined practice, it’s far easier said than done. In trying to ensure quality, many teams actually create waste – through excessive testing, for example, or an excessive logging of defects.
In recent decades, many Lean development teams have found success by applying the following Lean development tools to build quality into their work. In Lean development, quality is everyone’s job, not just that of the quality analyst.
These are some of the most popular Lean development tools for building quality in:
- Pair programming: Avoid quality issues by combining the skills and experience of two developers instead of one
- Test-driven development: Writing criteria for code before writing the code to ensure it meets business requirements
- Incremental development and constant feedback
- Minimize wait states: Reduce context switching, knowledge gaps, and lack of focus
- Automation: Automate any tedious, manual process or any process prone to human error
Create knowledge
The Lean development principle of Create Knowledge is another one that seems simple, but requires discipline and focus to implement. This principle encourages Lean teams to provide the infrastructure to properly document and retain valuable learning. This can be done by using any combination of the following tools:
- Pair programming
- Code reviews
- Documentation
- Wiki – to let the knowledge base build up incrementally
- Thoroughly commented code
- Knowledge sharing sessions
- Training
- Use tools to manage requirements or user stories
Defer commitment
This Lean development principle is easily misused. Defer Commitment does not mean that teams should be flaky or irresponsible about their decision making.
Rather, the opposite: This Lean principle encourages team to demonstrate responsibility by keeping their options open and continuously collecting information, rather than making decisions without the necessary data.
To defer commitment means to:
- Not plan (in excessive detail) for months in advance
- Not commit to ideas or projects without a full understanding of the business requirements
- Constantly be collecting and analyzing information regarding any important decisions
Deliver fast
Every team wants to deliver fast, to put value into the hands of the customer as quickly as possible. The question isn’t why teams want to deliver fast, but rather, what slows them down. Here are a few common culprits:
- Thinking too far in advance about future requirements
- Blockers that aren’t responded to with urgency
- Over-engineering solutions and business requirements
The Lean way of delivering quickly isn’t working longer hours and weekends, or working recklessly for the sake of speed.
Lean development is based on this concept: Build a simple solution, put it in front of customers, enhance incrementally based on customer feedback. This is important, especially in software, because speed to market is an incredible competitive advantage.
Respect for people
The Lean principle of Respect for People is often one of the most neglected, especially in the fast-paced, burnout-ridden world of software development. It applies to every aspect of the way Lean teams operate, from how they communicate, handle conflict, hire and onboard new team members, deal with process improvement, and more. Lean development teams can encourage respect for people by:
- Communicating proactively and effectively
- Encouraging healthy conflict
- Surfacing any work-related issues as a team
- Empowering each other to do their best work
Optimize the whole
Suboptimization is a serious issue in software development, and is often a self-fulfilling prophecy. In their book, Mary and Tom Poppendieck describe two vicious cycles into which Lean development teams often fall.
The first is releasing sloppy code for the sake of speed. When developers feel pressured to deliver at all costs, they release code that may or may not meet quality requirements. This increases the complexity of the code base, resulting in more defects. With more defects, there is more work to do, putting more pressure on developers to deliver quickly… so the cycle continues.
The second is an issue with testing. When testers are overloaded, it creates a long cycle time between when developers write code and when testers are able to give feedback on it. This means that developers continue writing code that may or may not be defective, resulting in more defects and therefore requiring more testing.
As the antidote to suboptimization, optimizing the whole is a Lean development principle that encourages Lean organizations to eliminate these sorts of vicious cycles by operating with a better understanding of capacity and the downstream impact of work.
It’s based on the idea that every business represents a value stream – the sequence of activities required to design, produce, and deliver a product or service to customers. If our goal is to deliver as much value to our customers as quickly as possible, then we have to optimize our value streams to be able to do just that. To understand how to optimize our value streams, first we have to properly identify them.
After identifying how value flows through their teams, many organizations decide to organize their software development teams to be complete, multi-disciplined, co-located product teams, which enables them to have everything they need to deliver a request from start to finish, without reference to other teams. This is an approach popularized by Spotify that has been adopted by many Lean organizations (including LeanKit) as a way to optimize the whole and increase the speed of value delivery.