The first step in eliminating waste is to identify it by breaking down all business processes visually and finding opportunities to get rid of any activities that don't add value to customers. The Lean methodology defines seven types of waste that need to be eliminated so that processes can be optimized.
Two industrial engineers, Shingo and Ohno, developed the Toyota Production System (TPS), dubbed Lean production. Although developed in the automotive industry, the principles behind this system proved to be a success when implemented in the software industry.
"Lean" was created as a response to an extremely complex environment. The modern business climate can be characterized as such, especially as we live in a world of startups. Whether we're talking about new businesses or companies operating for decades, Lean principles can be applied just as effectively through small steps. The focus is concentrated on experimenting, testing hypotheses, and adapting to ever-changing circumstances and requirements.
When observing the seven principles of Lean software development, we can see their goal is to help us keep agility and flexibility. At the same time, we should also be capable and ready to implement the right decisions and not limit ourselves to strict and long-term plans. Case in point, imagine being bound by an annual strategy adopted in January 2020. Agile lets us adapt quickly to both disasters such as a pandemic and smaller shifts in the environment with no delays.
In 2003, Mary and Tom Poppendieck published the book "Lean Software Development: An Agile Toolkit" where they adapted the traditional Lean manufacturing principles to software engineering. These are the seven principles of Lean software development:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Here we will explore the first one, "eliminate waste." To eliminate it, we must first learn to recognize it. Originally, the listed seven wastes of Lean were excess inventory, waiting, defects, overproduction, motion, transportation, and overprocessing. When applied to the software industry, Lean suggests there are seven types of waste:
- Partially done work
- Extra features
- Task switching
An additional eighth type of waste is also listed by some authors. Management activities or ineffective leadership are often identified as part of the list above.
All these types of waste are summed up as "Muda", a Japanese word that stands for wastefulness or any activity that wastes resources without adding value to the business. By eliminating Muda, managers pave their way to improving profitability only by lowering costs. This methodology is especially important in Lean manufacturing, where companies reduce operating costs and enhance inventory management. Muda is a key concept in Lean and is completed by Mura (unevenness) and Muri (overburden).
Partially done work
In the software development business, we're talking about unfinished features. They represent all the working hours our teams spent in vain. This is the last thing we want, so we try to avoid it at all costs. When a feature is only 10% completed, it doesn't mean we're throwing 10% of our efforts out the window if we quit working on it. It means a lot more than 10% is wasted, as a great deal of research, decision-making, data, design, and general preparation preceded the development process.
The total amount of invested energy does not equal the percentage of feature completion. The disbalance is visible through the relationship between wasted working hours and the team members' motivation and enthusiasm. Everyone likes to see the results of their efforts without delays, and if we don't put before our users something that brings value, morale will decrease.
Fundamentals of Agile Project Management
Features that were completed but remained unused. This could mean we waste time developing a feature that only 4% of our users find useful. Instead, we could have spent that same time developing a feature that benefits 40% of our users.
Handoffs are a dangerous part of the process. They open up the opportunity for information to get lost, tasks not be delegated properly, and previous or newly appointed assignees washing their hands of responsibility. It's crucial to reduce the number of handoffs in the flow and increase their quality as much as possible.
One of the suggested ways is to create temporary "feature teams" made up of people from various teams and professions to work on something together rather than passing tasks back and forth. The creation of such units should be approached carefully, as they form a parallel structure to the existing organization model. Individuals could find themselves facing two or more scrum masters/managers/product owners, which can impact prioritizing tasks. On the other hand, managers can find themselves in the dark, as they're not fully aware of what's on someone's plate.
Everyone is familiar with the issue of task switching, from developers to creative professionals. The brain needs some time to prepare itself and focus on the demand of the task at hand. It's normal not to have the same level of continuous deep focus throughout the day! However, if our thoughts get interrupted many times while trying to solve a problem, the chances of that problem remaining unsolved increase drastically.
Managers often think that overwhelming employees with tasks and extra duties will make them more productive. This is a common mistake, as the result of this type of thinking is usually a burnt-out team member who can no longer code or perform any tasks.
Any unnecessary delay causes a loss in momentum and maneuvering space for all teams, especially those whose activities highly depend on others' results. Waiting is justified if it makes sense. For instance, when we're waiting for a decision to be made in order to avoid doing the same thing twice.
However, waiting and delaying, more often than not, is a form of conformism and should be avoided. Better discipline and sync of an individual, a team, and the company as a whole should make the system run as smoothly as clockwork.
Let us explain this one with an example. Say we've solved a problem rather successfully and moved on. Two months later, we need to get back to it and improve our original solution. In the meantime, we released several new features, learned new code, and changed context so many times we've forgotten how this sub-system works! Now, an entire team needs to invest a whole day into remembering what's under the hood. Logically, it would have been better to spend an extra hour or two back when we were knee-deep in processing the issue rather than wasting days or months later.
Everyone's in a rush to release a product or service, wrap up the new feature as fast as possible, and progress quickly. Overproduction and hurry create defects that come with a cost. Whether we call them bugs, slips, or glitches, they will come back and bite us sooner or later. The main disproportion when dealing with a defect is: the longer you wait, the harder it is to solve. When the team shifts its focus to another task, it's increasingly challenging for a software developer to get back mentally to a particular problem. What once required a day's work to code now rises to three days.
Many activities become an essential part of the framework, believing they'll bring value. The problem arises when all those meetings, materials, preps, and arrangements turn out to be unnecessary because they don't bring the added value they were supposed to. One needs to be careful here because often, we need a series of meetings to turn an idea into something useful for the users. However, this shouldn't be used as an excuse.
Meetings and other similar activities should have a clear goal, relevant and interested participants, an agenda, and a well-defined next step. These activities are often not much liked, but instead of canceling them altogether, they need to go through analysis, be improved, and regain their original purpose. Any excess must be eliminated according to the Lean process.
Unused talent - this is an addition to the "management activities" principle, added in the 90s. Companies often don't harness all the skills and knowledge their employees have under their belt. This could lead to:
- loss of efficiency
- unnecessary employment of new people
- loss of employee motivation
Management activities could be the cause of this waste.