Software’s Seven Deadly Wastes

There are seven things that slow your software team down. Learning to conquer each of them is the key delivering faster.

The seven wastes come from the principle of of Lean Manufacturing, an idea with its origins in Japanese industry at the beginning of the 20th century. That may seem a long way from the software industry of today, but the lessons are just as applicable to modern software development. By eliminating the seven wastes from your process, you’ll soon find your delivery times improve.

Let’s look at each of them.

Transport

This is the movement of materials from one location to another. It’s not hard to see how this slows manufacturing — a factory split across two sites will obviously be difficult to run — but in software transport waste is generally harder to see. Think in terms of hand-overs between teams. If your developers must pass work onto a test team (or individual), and it then moves to another person’s responsibility for acceptance or sign-off, and then again for release, you have transport waste.

Reducing transport waste can be as simple as pairing testers with developers, but building a continuous integration (CI) system, or continuous delivery (CD) pipeline are also great solutions.

Inventory

­­This is undelivered stuff cluttering up the production line. Features that are started and then left behind by higher priority work are considered inventory, as are features that might be technically complete but which haven’t yet made it to customers. Carrying all this stuff along with you takes up brain space, confuses the picture and slows the team down. This can be an especially big problem if your branching strategy means you’re carrying lots of un-merged branches along with you.

The simplest way to reduce inventory is to just agree not to start things until you’ve finished other things. Each feature should enjoy a smooth progression from conception to delivery, and not stall during the process. Visualising your work on a Kanban board is a great way to see where you’re carrying inventory and help to reduce it.

Motion

Motion is the movement of people around the work at hand. This might be as simple as having to travel to another floor to find a meeting room, or search for a space in a hot-desking environment. It could also be more abstract — the delay caused by having to switch tasks too often, or deal with constant interruptions from other people and problems.

Motion is often caused by carrying too much inventory, so many of the steps above can help to reduce it. So can thinking about the physical environment, and agreeing fixed meetings rather than ad-hoc interruptions.

Waiting

­­Very simply, waiting is hanging around for delays. Waiting for an answer to a product question, waiting for an external system to be ready, or for another team to complete their work will all slow the process down.

You can reduce waiting by being careful not to start a feature until it’s well understood, and by ensuring any external teams or individuals have some slack in their schedules so they’re free when they’re needed.

Over Processing

In manufacturing this broadly refers to working too hard — building to unnecessarily fine tolerances or polishing things that will be hidden in the final piece. In software, this speaks to the YAGNI principle (“You ain’t gonna need it”). This refers to things like coding for imaginary levels of scale, building in useless caching or agonising over architecture for a simple product. A team mentality that favours frequent releases is your best weapon against such gold-plating, but be care must be taken to balance urgency of delivery with doing a job that’s good enough.

Overproduction

Put simply, this is building useless features. A figure often bandied around is that some 64% of built software features are rarely or never used. This comes from a limited study done in 2002, so the actual figure industry-wide probably varies. However, the absurdity of building things no-one will use is not hard to grasp. Careful product ownership and good user feedback can help combat this.

Defects

There’s an old story about a company that builds petrol lawnmowers. If the mower doesn’t start first time once it leaves the production line they simply throw it away for scrap. Spending time on fixing the defects doesn’t make economic sense for them.

Software is perhaps less cut-and-dried than that, but bug-chasing during development can certainly be a time sink. Automated tests are a good fix for this, but a good product owner can also reduce defects by making sure the requirements are understood first time.

The seven wastes will all manifest themselves differently in different teams, and the way you reduce each of them will be very specific to your situation. Keeping them in mind, however, is a really useful tool in your quest for faster delivery.