Lean development is the application of Lean principles to software development. Lean got its 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, and relies on the collaboration of a group of specialized workers in order to get done.
7 Lean Development Principles
The seven principles of Lean development are:
- Eliminate Waste
- Build Quality In
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Respect People
- Optimize the Whole.
Eliminate Waste (muda)
- 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
Build 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
- Pair Programming
- Code reviews
- Wiki – to let the knowledge base build up incrementally
- Thoroughly commented code
- Knowledge sharing sessions
- Use tools to manage requirements or user stories
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, to not commit to ideas or projects without a full understanding of the business requirements, and to constantly be collecting and analyzing information regarding any important decisions.
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.
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, and 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. Two vicious cycles that Lean development teams often fall into.
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.