Minimize the waste in software development
By: Sebastian Opałczyński
Tags: Lean Startup, Agile, Software Engineering, Software Development

Lean thinking reduces waste and focuses on the essentials.

The quote mentioned above comes from Scrum Guide because reducing waste is essential for the Scrum framework. Nevertheless, in my opinion, we should avoid waste in all circumstances, no matter if you are a Scrum acolyte or an opponent. In this article, I would like to focus on the types of waste in software development and try and present techniques to minimize it. Please keep in mind that reducing waste to zero is impossible, yet we should try to reduce it to the minimum.

Types of waste

To minimize the waste first you need to recognize it. So let’s quickly present and discuss the types of waste in software development — the source for this list is the book: Lean Software Development: An Agile Toolkit, written by Mary and Tom Poppendieck.

Partially Done Work

In other words, it’s a work in progress, the pieces of code, system, new service that are not yet on production and we do not know if this piece is solving the business problem and bringing value. We also do not know how to integrate this work fully into the environment and do not know what we can expect there. “This kind of work ties up resources in investments that have yet to yield results.”

In an extreme situation, this kind of work can never reach production and there’s a huge investment that needs to be written off.

Extra Processes

Paperwork. We all probably hate it. What we need to realize here is that paperwork consumes resources, and always should be asking ourselves if the paperwork is really needed? It’s often the case that client needs to sign off even the smallest requirements or changes in the system.

In the current times (the book was written in 2003) I think generally there’s less paperwork, but on the other hand, we have more processes in place that are not questioned and they should be. Processes can help you, but they also can make your work harder, time-consuming, and generate waste.

Extra Features

At first sight, it sounds really good, everybody wants extra features, right? Wrong. You just need to realize that every piece of code that’s is written and not utilized generates waste in the long run. Those changes need to be maintained, tested, and integrated each time something is changing. And such changes are living in the codebase till the end of the software project. This kind of waste is also very close to over-engineering. In many situations initial, implementation can be dumb simple until it grows and requires more improvements.

Task Switching

I think it’s a programmer’s favorite one and best known. Task switching has a big cost included related to context switching. It’s still not common knowledge, but doing two projects with the same team will be the fastest if those projects will be done one by one. If you have a setup in which developers are working on two and more projects at the same time — you are producing a lot of waste. It’s also related to so-called task priorities, where one of the levels requires the development team to drop everything and fix the issue.

Waiting

Delays in the process, the nightmare of every team out there. “Delays in starting a project, delays in staffing, delays due to excessive requirements documentation, delays in reviews and approvals, delays in testing, delays in development.”

Why delays are a waste? That’s because the customer (investor, stakeholder) can not realize the value as quickly as possible.

Motion

Everything moves :) This kind of waste is related to people’s movement and artifacts movements. For example — If a developer has a question, how much motion does it take to find out the answer? Is the customer (investor, stakeholder) representative ready and accessible for the questions about features?

The artifacts move too: requirements from analyst to designers, then design documents to programmers, then code from programmers to testers. Each step here produces waste as it’s not possible to create a document (artifact) in a way that all context is passed by the creator.

Defects

Defects are all of those little things we usually call bugs. Some of them are funny, some of them are scary, but each one produces a waste. If you detect a huge defect after three minutes the cost of it will be much less than a medium defect detected after weeks, or a small one after months, because of this fact you should try to configure your development process in a way that allows finding defects as soon as possible. The sources of defects are:

processed not followed — eg. testing procedure not followed

specification may be misunderstood or not followed

specification may have been insufficient or incorrect

indirect effects on existing codebase (regressions)

plain human error — cause we simply make mistakes

Management Activities

As I see this point is creating various discussions, the original claim of the writers of the book is this: “Management activities do not directly add value to a product, but they do have a big impact on waste in an organization.”

In my humble opinion and experience I have, I think the wrong decision taken by the management can produce an extremely huge amount of waste, but, you know sometimes it’s a gamble, and sometimes you’re losing.

If we do more digging, we can also find other sources of waste in software development:

Gold plating — “too good” in software development is bad, it’s a phenomenon of working on a project or task past the point of diminishing returns, so situation when someone tries to enhance the feature beyond what was requested and expected and can result in user disappointment, also very close to over-engineering.

— “too good” in software development is bad, it’s a phenomenon of working on a project or task past the point of diminishing returns, so situation when someone tries to enhance the feature beyond what was requested and expected and can result in user disappointment, also very close to over-engineering. Unused Employee Creativity — this issue is related that people’s talents are not used in the most effective way: employees assigned to tasks that they are not good at, poor communication, not providing enough context to their employees, and not aligning on goals will be main issues here.

Lean principles and ways of minimizing a waste

The software development process can be compared to the factory line (and this comparison is definitely done here not by accident as lean has deep roots in manufacturing). Each factory line can be designed in an effective way, where the waste is minimized. It’s also an interesting exercise to see the software development process the same way modern companies are producing cars for example.

Definitely, I am not an expert in producing cars, but we can imagine the process pretty well, I think. Probably we will start with defining the customer’s expectations from a new car and then do some research. After the research is done we will focus on designing a car — exterior, interior, engine, steering system, and all of the other parts that are needed for a car. After this phase, we will prepare a small factory line (can be the case it’s mostly manual) and create the car prototype. This prototype we can give to the customers, gather feedback, make improvements, we can run some tests (crash tests), and if everything is fine, we can program the main factory line and start mass production.

It can be the case that I’ve missed some parts — obviously, in the car industry, there will be a lot of effort related to logistics, like ordering the parts from suppliers, create sub-component of the car, factory staffing, and all other activities we can imagine. For your interest I did some quick search and producing a car from scratch takes from 3–5 years, just to put things in context.

You can do exercise and map a process of car production to the process of software development, I think you will be surprised how many pieces match.

Now, let’s get to the core, the lean principles:

Identify value — value is always defined by the customer’s needs for a specific product. In other words — if a customer wants to buy five apples, you are not selling him five bananas. Here you can also ask yourself — how much customer is willing to pay for five apples.

— value is always defined by the customer’s needs for a specific product. In other words — if a customer wants to buy five apples, you are not selling him five bananas. Here you can also ask yourself — how much customer is willing to pay for five apples. Map the value stream — this exercise can take place only when you defined a value, cause it’s mapping all of the steps that need to be taken to deliver products to the customers from raw materials. This is an eye-opening exercise that allows you to identify all of the processes and actions, from here you can identify the blocks that are not delivering value and are a waste. You can find a lot of resources on the web on how to do this exercise and how to make it beneficial for your organization.

— this exercise can take place only when you defined a value, cause it’s mapping all of the steps that need to be taken to deliver products to the customers from raw materials. This is an eye-opening exercise that allows you to identify all of the processes and actions, from here you can identify the blocks that are not delivering value and are a waste. You can find a lot of resources on the web on how to do this exercise and how to make it beneficial for your organization. Create Flow — after removing the waste you can configure a flow, and make sure that flow works smoothly without interruptions, delay, or bottlenecks. Here it can happen that you need to change how your organization work — be more cross-functional and break silos.

— after removing the waste you can configure a flow, and make sure that flow works smoothly without interruptions, delay, or bottlenecks. Here it can happen that you need to change how your organization work — be more cross-functional and break silos. Establish Pull — now your flow is improved so you can deliver products as needed (“just in time”). The customer can “pull” the product from you as needed. As a result, products do not need to be built in advance or materials stockpiled.

— now your flow is improved so you can deliver products as needed (“just in time”). The customer can “pull” the product from you as needed. As a result, products do not need to be built in advance or materials stockpiled. Seek perfection — the system needs constant effort to perfect. This means that with time you can define another value stream map and identify waste and find improvements.

In software development lean was restated, and principles here are (but still there are deeply connected with lean approach):

Eliminate the waste — in order to eliminate you need to recognize first. I’ve mentioned the types of waste above. Some of them are pretty obvious to find, like work-in-progress — here simply check how much of the work is not yet delivered to production. Some of them are harder to find — like defects without any bugs monitoring tools, but generally speaking, you should be able to identify most of them and propose changes that will reduce or eliminate them.

— in order to eliminate you need to recognize first. I’ve mentioned the types of waste above. Some of them are pretty obvious to find, like work-in-progress — here simply check how much of the work is not yet delivered to production. Some of them are harder to find — like defects without any bugs monitoring tools, but generally speaking, you should be able to identify most of them and propose changes that will reduce or eliminate them. Amplify learning — well, creating the software is not about coding, it’s about problem-solving. To enable better problem solving we need to amplify learning, for example. instead of gathering requirements from a customer on paper, try to have workshops with him/her with low fidelity mocks. The key idea here is that you should pass the knowledge in the most effective way. Fast feedback loops, short iterations will also help.

— well, creating the software is not about coding, it’s about problem-solving. To enable better problem solving we need to amplify learning, for example. instead of gathering requirements from a customer on paper, try to have workshops with him/her with low fidelity mocks. The key idea here is that you should pass the knowledge in the most effective way. Fast feedback loops, short iterations will also help. Decide as late as possible — decisions are always taken with uncertainty, it’s logical to make them as late as possible because over time you can gather more knowledge and data, which will result in a better outcome. It’s a bit like playing the poker card game and you know how to count cards. The later the game the more information you get.

— decisions are always taken with uncertainty, it’s logical to make them as late as possible because over time you can gather more knowledge and data, which will result in a better outcome. It’s a bit like playing the poker card game and you know how to count cards. The later the game the more information you get. Deliver as fast as possible — this will bring you a lot of benefits: faster feedback, faster feedback means that the changes can be delivered in the next cycle, the learning process is amplified, with speed decisions can be delayed — cause you gather knowledge and data, and not delivering features blindly.

— this will bring you a lot of benefits: faster feedback, faster feedback means that the changes can be delivered in the next cycle, the learning process is amplified, with speed decisions can be delayed — cause you gather knowledge and data, and not delivering features blindly. Empower the team — there’s one simple agile principle here: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” People need the higher purpose of work, the misconception that people (software developers in particular) are resources making tasks is still alive out there, and it’s wrong.

— there’s one simple agile principle here: People need the higher purpose of work, the misconception that people (software developers in particular) are resources making tasks is still alive out there, and it’s wrong. Build integrity in — all of the pieces need to work nicely together: product advertisement, delivery, deployment, how intuitive its use is, the price, and how well it solves the problem. The integrity needs to be builds-in into the product on all levels.

— all of the pieces need to work nicely together: product advertisement, delivery, deployment, how intuitive its use is, the price, and how well it solves the problem. The integrity needs to be builds-in into the product on all levels. Optimize the whole — Seek perfection. You should constantly overview the processes and make them better with each iteration. In the book mentioned above, there’s a quote worth noting: “Think big, act small, fail fast; learn rapidly”

Hope that this article can help you make better software and provide more value to the end-users. Thanks for reading.