Author
What is Lean software development? Among the commonly cited software development methodologies, Lean can be the hardest to pin down. The Agile Manifesto drew heavily on Lean principles but the seminal text that formally introduced them in the specific context of software development, Mary & Tom Poppendieck’s Lean Software Development: An Agile Toolkit, was published two years after it in 2003.
Lean, or The Toyota Way as it was known before being rebranded in the late 1980s, is one of the founding fathers of modern project management and design thinking theory. Its roots are in manufacturing but its principles informed and inspired the Agile approach to software development starting with Scrum.
This blog will explore:
- Lean’s place in the family tree of software development methodologies,
- Its relevance as a still popular approach to software development,
- Lean software development’s 9 principles, and;
- Its practical implementation by software development teams
Can We Help You With Your Next Software Development Project?
Flexible models to fit your needs!
A brief history of Lean as a software development methodology
Lean started at Toyota in the late 1940s as a set of principles and practices designed to enable more effective manufacturing. It focuses on removing waste and delays to make the ‘flow of value’ more effective. The core principle is that removing everything from a process that doesn’t add value for the end customer maximises value because resources are maximised. Waste is converted into added value.
The approach, developed on the Toyota factory floor between the late 1940s and 1970s by the industrial engineers Taiichi Ohno and Eiji Toyoda, who worked at the company. The process was first formally documented for the general public by the book Toyota Production System (TPS), published by Ohno in 1978.
It wasn’t until 1988 that “The Toyota Way” was rebranded as “Lean”, with the term coined by John Krafcik’s 1988 article, “Triumph of the Lean Production System”. Lean manufacturing quickly became a highly influential culture and methodology adopted by companies around the world to great effect.
In 2003, Lean evolved from a methodology used in the manufacturing of physical goods to one used for creating digital products through a software development process with the release of the landmark book Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck.
The two authors had an extensive background in IT and product development with Mary’s career spanning roles as a process control programmer, IT department manager and product development. Tom was originally a professor of physics who then worked in IT infrastructure, product development, and manufacturing support, and evolved to consulting project assignments in healthcare, logistics, mortgage banking, and travel services.
Lean Software Development was inspired by a period Mary spent managing a government software project where she encountered the Waterfall software development methodology for the first time. The contrast between the issues she encountered managing a software development project in an organisation used to a Waterfall approach and her previous experiences of successful projects convinced her “a new paradigm” was needed. Lean
The result was Lean Software Development, which meshed the principles of Lean manufacturing with the Agile software development methodologies and philosophy popularised by The Agile Manifesto and the book by Agile Software Development with Scrum by Ken Schwaber, Mike Beedle, Robert C. Martin, both released in 2001.
The Lean tradition in product development was continued by the influential 2011 book The Lean Startup by Eric Ries. Ries focused on how he believed the Lean principles set out by Mary & Tom Poppendieck in the context of software development could be applied by startups or established organisations developing a new product – digital or physical.
The principles of Lean Software Development
As a methodology or mindset, Lean has 5 core principles outlined by the 1996 book Lean Thinking by James P. Womack and Daniel T. Jones:
- Identify value
- Map value streams
- Create flow
- Establish pull
- Continuous Improvement
In their book on Lean’s application as an agile software development toolkit, Mary and Tom Poppendieck lay out 7 principles:
- Eliminate waste
- Build quality in
- Create knowledge
- Defer commitment
- Deliver fast
- Respect people
- Optimize the whole
Lean Software Development: An Agile Toolkit looks at the practical implications of each in the context of building software and offers concrete suggestions on how they can be implemented.
Eliminate waste
The Toyota Way says to minimise waste it is important to identify exactly where it most often creeps in. 7 common sources of waste (muda) are identified in manufacturing processes, including over-production, defects, holding more inventory than necessary and either inventory or workers spending more time than necessary in motion between areas of a factory.
In a software development context, Lean Software Development highlights 9 common areas where waste can creep in:
Unnecessary code or functionality
The waste risk of manufacturing an item before it is required translates to unnecessary code and functionality in software development. Both delay delivery time and feedback loops and should be consciously avoided. One way this is achieved in Lean software development is through the rapid delivery of small increments of working software that Agile frameworks promote.
Too much Work in Progress (WIP)
In software development, starting more tasks than can be completed in a short development cycle adds unnecessary complexity that disrupts workflow, hurting efficiency.
Delay in the software development process
Delays in the software development process put back delivery and slow down feedback loops.
Unclear or changing requirements
Unclear or changing requirements result in focus being lost, work being repeated, frustration and, ultimately, a drop in quality of the software produced.
Bureaucracy
Good organisation is important but more bureaucracy than necessary results in delays to a software development process.
Poor communication
Delayed or poor communication either within a software development team or between it and other stakeholders, results in delays and a drop in focus and enthusiasm if the problem lies with external stakeholders. Poor communication to stakeholders from development teams can have a negative impact on the organisation’s attitude to digital transformation.
Incomplete work
Partially completed work, like unnecessary code or functionality neither adds value for the customer nor provides a learning opportunity for the team.
Task switching
A software development team, or its individual members, switching tasks unnecessarily due to poor planning contributes to a drop in quality, delays, communication issues and can impact morale.
Quality issues
Defected or buggy software introduces waste in the form of repeating work and low customer satisfaction.
When does IT Outsourcing work?
(And when doesn’t it?)
Build quality in
The principle of building quality into software goes beyond the natural inclination of professionals to do a good job. It needs to be systematised for it to be effective and avoid well-intentioned but wasteful measures like excessive testing or logging of bugs.
Lean software development practises that have been found to increase the quality of work produced include:
Incremental development and quick feedback loops.
Test-driven development such as documenting criteria all code being written must meet.
Minimise wait states by reducing task and context switching to avoid loss of focus and knowledge gaps.
Automation of as many manual, repeatable processes vulnerable to human error as possible.
Pair programming means two developers are always teamed up to work on a particular piece of code like a user story. Doing so means the code benefits from the combination of two sets of skills and experience rather than just one.
Create Knowledge
Pair coding is also something Lean development recommends as one tool that contributes to the principle of creating knowledge within the team. The principle encourages the creation of a system that means learning and experience acquired is documented and retained. In addition to pair programming, other recommended tools include:
- Documentation
- Code reviews
- Well commented code
- Training
- Knowledge sharing sessions
- Wiki knowledge base system
- Using tools to manage requirements or user stories
Defer commitment
It can sound counter-intuitive that deferring commitment is a ‘principle’ rather than a negative. But deferring commitment in Lean software development should not be confused with shirking responsibility. In fact, the point is the opposite. Keeping options open encourages a Lean software development team to proactively collect information and feedback before committing rather than being forced to lock something in before the necessary data is available to inform decisions.
Deferring commitment means accepting the responsibility that when things are committed to it is because they are well-informed decisions. Practically, keeping the defer commitment principle means avoiding planning in more detail than necessary before it’s necessary ie. months in advance when things could change and so that planning has to be redone.
It also means ideas and projects shouldn’t be committed to ahead of a full understanding of business requirements and that collecting and analysing information that could influence decisions is an ongoing, structured process.
Deliver fast
Keeping to this Lean principle involves not just ‘trying to deliver value as quickly as possible’ in the general sense. It is founded on the active, systematic avoidance of factors that can slow development teams down, including:
- Thinking and planning too far in advance
- Not responding quickly and effectively enough to blockers
- Over-engineering of both business requirements and their solutions
In Lean, deliver fast is about avoiding falling into the trap of “more haste, less speed”. Spending some time on the things that can cost more time later if they go wrong, which unminded they usually do to some extent, is a worthwhile upfront investment in the pursuit of speed of delivery.
Lean software development’s concept of quickly building and releasing a simple solution and then incrementally improving it based on customer feedback is informed by the reality speed to market is a priceless competitive advantage.
Respect for people
To show respect for people is the Lean principle that is probably most often skipped over and reduced to abstract commitments rather than the systematic practices and accountability for their keeping the Lean approach demands. Lean Software Development suggests Lean teams encourage maintaining the respect for people principle by:
- Communicating proactively and effectively
- Encouraging constructive difference of opinion to avoid groupthink
- Tackling any work-related issues any team members have as a team.
- Empowering each other to do their best work.
Some of the specific tools that Lean teams can use to systematically ensure these things are done are efficiently include:
- Efficiently incorporating the opportunity to do address them into regular meetings.
- Pair programming, code reviews, commented code and other mutually supportive and knowledge building team activities.
- Careful recruitment at the organisational level with soft skills focused on as much as hard skills.
- Thought put into team formation and compatibility between the soft and hard skills of team members.
Optimise the whole
Lean Software Development outline two traps Lean development teams often fall victim to. The first is compromising the quality of code in the pursuit of faster release. A classic more haste, less speed gaffe, substandard code increases the complexity of the software’s overall codebase.
That, in turn, increases the likelihood of defects and the time required to fix them, increasing the overall volume of work and inadvertently creating more time pressure, in a vicious circle.
The second vicious cycle Lean teams need to be aware of the need to avoid is excessive testing. If testers are overloaded, testing cycles and feedback loops are extended. Longer feedback loops increase the chance sub-standard code continues to be produced in the meanwhile. More sub-standard code or other defects means more testing and even longer feedback loops from increasingly stretched testers.
Lean teams should seek to actively avoid these kinds of vicious cycles through a better understanding of team capacity and the downstream impact of work. Teams that are both better balanced from the outset and are encouraged to permanently consider interdependencies when managing workflow avoid these value-eroding traps.
Development, testing, and operations are all connected in how they influence each other up and downstream in the software development process. Lean software development teams recognise the need for the whole to be optimised and unified in purpose before any individual part can be. It is also why Lean software development dovetails so comfortably and complementarily with DevOps.
Lean vs Agile software development – competing or complementary?
But what about Lean and Agile and how they complement each other or otherwise? The concept of Lean software development was introduced and formalised by a book titled Lean Software Development: An Agile Toolkit.
That suggests the two approaches can co-exist and complement each other, despite both being referred to by different people in different circumstances as culture, philosophies, methodologies and frameworks.
But what is the nature of the relationship between Agile and Lean in the context of software development?
Agile development is based on the Agile Manifesto. It seeks to empower and engage teams to deliver value in an iterative and incremental way to customers.
Both Lean and Agile are about instilling a mindset. The Agile mindset is about being adaptive and able to change direction based on customer and market needs. Agile emphasises increasing collaboration and releasing working solutions quickly.
A Lean mindset encourages teams to take a systems view on how an organisation is delivering value and streamline the flow of work.
Lean software development is standardly described as an Agile methodology. But Lean significantly pre-dates the Agile Manifesto, which was only written in 2001.
The main goal of being lean is to increase the value to customers by reducing waste (Poppendieck, M. & Poppendieck, T., 2003).
The Agile Manifesto was heavily influenced by the concepts of the Lean approach to manufacturing and incorporated many of them into how it saw the best approach to building software. Lean Software Development: an Agile Toolkit, released in 2003, explicitly recognises the influence of The Agile Manifesto in its title.
Agile and Lean, in the context of software development and now elsewhere from marketing to engineering, are informed by each other in a feedback loop. The loop can be represented in a way that is remarkably similar to the infinity symbol associated with DevOps, another software development approach that draws from both Agile and Lean and whose relationship to each and both can be confusing.
The cornerstones of all three software development methodologies, philosophies, cultures or systematic sets of practices are reduced process overhead, people empowerment, and a strong focus on deliverables in the pursuit of continuous improvement and value delivery.
Can Lean be used as a stand-alone software development methodology?
Lean is probably most thought of as a set of principles and philosophy that informs practically applicable Agile software development frameworks like Scrum or Kanban rather than a stand-alone process to be followed by software development teams. That’s probably a result of the fact most literature on Lean doesn’t define specific practices in the same way Agile frameworks do.
Lean software development teams are left to decide on their own practices based on the specific needs of the project, as long as they promote the application of Lean principles. Because the Agile frameworks are compatible with Lean software development principles, they serve the purpose of providing a process of established practices.
The pie chart here reflects that, with only 1% of software developers saying they follow a Lean methodology at their team level.
It could also be said that they all follow a Lean methodology. Or at least, an Agile methodology or framework informed by and compatible with Lean principles.
In 2006, Mary and Tom Poppendieck released a follow-up to their original Lean Software Development. Implementing Lean Software Development: From Concept to Cash addressed the lack of easy-to-follow practices in the first book and introduced practical advice and ready-to-use techniques Lean software development teams could follow.
It offers several best practices to support the Lean Software Development principles established three years earlier:
Version control and scripted builds
Version control and scripted builds create knowledge by consolidating all team project knowledge into a single place. They eliminate waste because manual work is saved by automating builds and build quality in because automating builds eliminates a source of errors.
Daily Standups
Introducing daily standup meetings promotes the Lean principle respect people because these meetings encourage a team-oriented attitude. Team members know what each other are doing and can give or ask for help as needed to move the project forward efficiently. They also create knowledge because sharing information fosters organisational learning through the flow of knowledge from individual to group.
Automated Testing
Automated testing is a practice that builds quality in ensuring tests are executed regularly and consistently, which helps prevent defects and quickly highlights issues earlier in the process. Detecting defects and issues earlier means they are easier to correct before they have travelled significantly downstream affecting other parts of the process, which eliminates waste. And tests also create knowledge because they are used to document how the code functions and help team members learn. Automated testing allows for much greater scope and depth of tests which, in turn, offers more learning opportunities.
Continuous Integration
Continuous integration as a best practice of Lean software development supports the principle of build quality in because, combined with tests, it ensures code is high-quality and functional. The greater efficiency of the frequent, small integrations inherent to continuous integration, in comparison to extended integration phases, help eliminate waste.
Continuous integration also supports the deliver fast principle by improving the lead time of feature delivery.
Short Iterations
Short iterations eliminate waste because they are more efficient than extended integration phases and short iterations mean new functional software is delivered fast. And delivering features to customers quickly and in line with what they have actually asked for builds quality in.
Customer Participation
Lean software development demands customer participation as a best practice. Involving the customer helps create knowledge because collaboration allows for requirements to be iteratively discovered and then continuously improved upon. Involving the customer means the end outcome will be directly in line with their requirements, which builds quality in. Involving customers throughout the process also means decisions do not need to be taken upfront, supporting the Lean principle of defer commitment.
Lean can be used as a stand-alone software development methodology. The two books The Lean Startup and Implementing Lean Software Development both offer frameworks. It usually isn’t though. Most software development teams instead pay homage to the principles of Lean by working to one of the popular Agile software development frameworks the original Lean system of manufacturing informed.
K&C - Creating Beautiful Technology Solutions For 20+ Years . Can We Be Your Competitive Edge?
Drop us a line to discuss your needs or next project
