Once upon a time, in the land of the rising sun, there were two industrial engineers, Shingo and Ohno. They developed the Toyota Production System (TPS), dubbed as Lean production many years later. 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 startups or companies operating for decades, lean management principles can be applied just as effectively. The focus is concentrated on experimenting, testing hypotheses, and adapting to ever-changing circumstances and requirements.
We're in the software development business, where Agile is very popular. Scrum, Kanban, and Lean are just some of the frameworks found under the Agile umbrella.
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 with 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.
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. Lean suggests there are eight types of waste:
- Partially done work
- Extra features
- Task switching
- Management activities
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 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, design, and general preparation preceded the development.
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, and if we don't put before our users something that brings value, the morale will decrease.
Fundamentals of Agile Project Management
Those that were completed but remained unused. This could mean we spent 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.
Many activities become an essential part of the framework, believing they'll bring value. The problem arises when all those meetings, 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 be improved and regain their original purpose. Any excess must be eliminated.
Unused talent - this is an addition to the "management activities" principle, added in the 90s. Companies often don't harness all the skills 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.
Handoffs are a dangerous part of the process. They open up the opportunity for information to get lost, tasks not being delegated properly, previous or newly appointed assignees washing their hands of responsibility. It's crucial to reduce the number of handoffs and increase their quality, as much as possible.
One of the suggested solutions 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 leads to difficulties when 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 task at hand. It's normal not to have the same level of 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 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 is more often than not 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 things, 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 if we spent an extra hour or two back when we were knees deep in the issue, rather than wasting days or months later.
Everyone's in a rush to release a product, wrap up the new feature as fast as possible, get things done quickly. Hurry creates defects. Defects come with a price. Whether we call them bugs, slips, or glitches, they will come back and bite us sooner or later. The main disproportion when dealing with them is: the longer you wait, the harder they are to solve. When the team shifts its focus to another task, it's increasingly challenging to get back mentally to a particular problem. What once required a day's work now rises to three days.
Now you know all about the first principle of lean management, "Eliminate waste." Our next article will guide you through the rest!