Lean: Avoiding Waste in Software Development
Lean: Avoiding Waste in Software Development
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
“Lean” and “waste” are now two of the most fashionable buzzwords in software development, but what do they mean? How can we avoid waste?
Waste in software development
Lean is a process philosophy which in its core aims to reduce waste to a minimum. Waste is any element that negatively affects the productivity or quality of software development.
Lean recognizes 7 classic types of waste:
- Unused creativity
Because Lean was originally targeted to industrial companies, there are many interpretations of how these types of waste translate to specific wastes in software development. What follows is a list of some of the most important ones.
Defects - Bugs
Bugs being a waste in software development shouldn't come as a surprise. What is different is the approach to tackle them. Following Lean principles, the right way to tackle bugs is by preventing them to appear altogether, and by eliminating them as soon as possible. This usually translates to a major focus on testing, code quality and integration with QA.
Waiting, Transportation - Lack of automation / Manual testing
A Lean software development aims to eliminate all the manual processes. That includes, building, testing, communication etc.
Continuous integration is the most important practice to reduce the lack of automation. It is also becoming very popular. I have seen many teams that immediately after they started using continuous integration saw their productivity massively improved.
Complexity, Overproduction - Gold plating
“That problem's too boring for you? Your vast intellect is wasted on your customer's silly needs? Have I got a solution for you!:
That's right, friend. Before long, you'll discover that almost any problem can be made more complicated! Tap into the unemptyable wells of PrematureComplexity & AccidentalComplexity, and have a heyday!
If your coworkers question you, assume they're idiots who can't code their way out of a paper bag! (Or, in this case, a paper hypercoagulative entity-containing megadevice!)
Hint: This is an AntiPattern”
Gold plating is very common practice amongst programmers trying to impress their colleagues or customers, and often causes the addition of features that are not even noticed by the end user. This causes waste obviously not only in development, but also maintenance time. It has to be avoided at all costs. Avoiding gold plating requires discipline. It requires the team to ask themselves if they are adding unnecessary or over-engineered functionality into the application.
Waiting - Useless meetings
We’ve all been there, the useless meetings with no agendas and no purpose whatsoever. Many times their only reason to exist is to make attendees feel important. One way to detect a useless meeting is to try to find out what actions should be taken after the meeting. If no action are to be taken, then it was probably useless. Another way to detect a useless meeting is to ask yourself if a meeting is necessary to decide an action. Can it not be decided with a simple conversation? An email?
Complexity - Technical complexity / Technical debt
Keep it as simple as possible. Over-engineering is from my experience one of the most common causes for projects to become unmaintainable. If something is not necessary, get rid of it.
I was in a project where we had architects overseas dictating the architecture of the application and adding complexity just for the sake of it. We got to a point where we had big productivity issues due to the complexity of the application, so we convinced the project manager to introduce the “Why?” rule. The “Why?” rule was very simple, the architect had to explain what was the purpose of the architecture, and, if he couldn’t explain the reason in business terms, the architecture would get rejected.
Waiting, Transportation - Heavy process/Bureaucracy
Do you suffer from a 100-step process to post code to production? Do you usually copy and paste documentation from one project to another? Do you have to wait for someone’s approval to move forward? If so, I’m afraid that your development process is filled with waste. Getting rid of waste in the core of your development process is difficult because it usually requires the company to redefine its philosophy. That’s why it is important to engage management and convince them that a lean process is necessary.
Inventory - Uncompleted features
Extracted from an interview to Mary Poppendieck:
Mary: In software development inventory is anything that you’ve started and you haven’t gotten done. It’s “partially done” work. In manufacturing if you start making something and it is in-process, it’s not sold, it is inventory. In development it’s the same thing. If you started developing something and it’s not done, it is inventory. What you’re trying to do Lean software development is the least amount of “partially done” work as possible. You want to go from understanding what you’re supposed to do to having it done and deployed and in somebody’s hands as rapidly as possible.
Uncompleted features are to be avoided at all cost. They don’t add any value, and usually cause other issues as: Integration problems, Over engineering, Maintenance...
Lean suggests to create features based on Minimum Marketable Features.
Extracted from the book Software by Numbers:
MMFs are units of software value creation. They represent components of intrinsic marketable value.
What is particularly unique about software products is that the features are often, or even usually, separately deliverable. In other words, a complex software application can have value to a user even if it is incomplete. Indeed, it is often claimed that software is by its very nature always incomplete!
Typically an MMF creates market value in one or more of the following ways:
Lean principles - Removing the cause, not only the waste
The key to applying Lean successfully is to be able to determine waste from value, but then, not only removing the waste itself, but more importantly, the cause. Ideally you should be able to answer the following four questions.
- What value am I producing right now?
- Is there anything I am doing which is not necessary?
- If tackling an issue, am I tackling the root of the issue, or only the consequences?
- Can I think of any idea to improve the process I am following now?
Lean, like agile, has a strong focus on people, expecting them to be proactive and to recognize what works and what doesn't work around them. Actually, some of the main practices of agile are focused on eliminating waste. For example:
- Continuous Integration - Helps to reduce transportation and waiting.
- KISS - Helps to reduce complexity.
- TDD - Helps to reduce defects.
The best approach to eliminate waste is to follow some basic principles.
- As soon waste is detected, the priority should be to eliminate the waste and its cause. This is similar to "the broken window" theory.
- The hunt for waste should be continuous; it should be performed by all the team members, all the time.
- Prioritize the waste to eliminate.
Opinions expressed by DZone contributors are their own.