Lean manufacturing vs Scrum - inventory waste (part 3)

This is a continuation of the previous post in this series.

In short, the number one goal in lean manufacturing is eliminating waste. In this series I'm looking at the seven categories of waste identified in lean manufacturing, how these translate to software development, and how scrum can help eliminate that waste. This is the third post in the series.

In this post I want to focus on inventory. This is one of the seven categories of waste targeted by lean manufacturing.

It is somewhat counterintuitive, even in manufacturing and especially for those with financial backgrounds, to see inventory as anything but an asset. Yet, inventory can be your greatest enemy. I'm not going to go into the manufacturing theory in detail here, but in summary inventory is a major waste. It basically means that you've tied up resources (including cash), into something that is not being used. Aside from tying up resources, there are also additional costs in handling of inventory from its storage and transportation to simple administrative costs. But perhaps the greatest problem with inventory is that it tends to hide other forms of waste. Inventory creates an illusion that things are well when they're not.

In software development any partially completed work is inventory and should be minimized. Partially completed tasks are mostly problematic because they hide the truth. There are usually complex integration or quality issues hidden in those partially completed tasks that you will never know about until you finally get around to trying to complete them.

To explain this I'll revert back to a manufacturing analogy. Imagine you produce custom furniture and have just won an order for a large batch of chairs. To minimize cutover times on machine setups you produce a large batch of legs, then a large batch of backrests, then a large batch of seats, then you assemble. Come assembly time, you realize that many of the legs are faulty and cannot be fitted onto the seats without some rework. Now you have more machine setup time, more work on the legs, and finally you can start assembly again. Now look at all the waste. Aside from the cost incurred because of effort, storage space, etc. and the waste associated with the rework, the inventory was hiding a quality issue. If you had made four legs, one backrest, one seat, assembled and repeated, you would have discovered the quality issue the moment it started happening, but instead you continued to build up inventory that you thought would be an asset, but quickly turned into a liability.

This is a very simplistic example of something that is usually much more nuanced and complex in manufacturing and even more so in software development, but it highlights how inventory can hide other problems.

Back to the world of software. To make matters worse software projects have traditionally made extensive use of progress reports. Progress reports are great perpetuators of the lies of inventory. People want to look good in progress reports so they overestimate progress. They also tend to vastly underestimate the amount of work remaining on any given task. And progress reports tend to accumulate a false narrative up to a climax where the whole project crashes down. At the start of a project there will be zero tasks with any progress, when you get to the 80% completed stage, this tends to be represented not by 80% of tasks completed, but by a small number of tasks completed and a large number of tasks almost completed (typically with progress percentages in the 75%-95% range). If this sounds familiar, you're not alone.

Consider the problem with the chairs again. If you were asked to estimate progress after the complete batch of legs had been done, you might have broken the work up into 4 tasks (legs, seats, backrests, assembly) and you probably would have said that manufacturing of the components is more effort so will carry more weight. Thus, by the time the legs were done the overall completion estimate might well have been about 30% (100% legs, 0% seats, 0% backrests, 0% assembly). At the start of assembly you would be forgiven for thinking that you were 90% done. But because of the quality issue hiding in inventory, you would have been completely wrong and 50% would probably have been a much more accurate number.

Unfortunately, these kinds of errors only cut one way. There are always hidden quality issues or complexities that you didn't realize would exist, but there are never golden eggs that make your life magically easier. Legs that work so much better than expected that you only need to fit two per chair or legs that assemble themselves simply don't exist. Legs that break or don't fit do exist.

How does this tie back to scrum?

Scrum puts a lot of emphasis on task completion. You must finish a task before starting the next one. A feature must be completed before moving on to the next one and the goal for a sprint is to complete features, not to have them at some point of perceived progress. This is important because it eliminates all the risk associated with work in progress.

In scrum there are no progress estimates and the only measurement of progress is when a feature is completed. Look back to the chair example: If progress was measured by completed number of fully functional chairs (i.e. the only thing of real value to an end user), you would have been sitting at 0% progress when you first started assembly. This sounds harsh, but it would have been a good warning sign of the trouble that lay ahead. If the batch was for a 100 chairs, you would have been at 1% after completing the first fully functional chair and by the time you got to 80%, the remaining 20% would most likely have been a walk in the park.

The definition of done becomes very important here (and there are lots of online resources that delve much deeper into this topic) as it directly affects how we perceive progress. A software feature isn't done when it just needs to be tested, or when it just needs to be integrated with something else, or when it just needs to be deployed. It's done only when there are no justs left. Exactly what the team's exact definition of done is depends on the context of their work, but it is important the definition of done is agreed upfront and is transparent. This definition of done is very central to scrum and an important part of managing software development without getting nasty surprises.

Scrum also puts a lot of focus on delivering shippable product at the end of each sprint. Artefacts like requirements specifications or design documents have no real value to the customer, so delivery is focused on working software. Before you have working software delivered and being used by real-world end users, it's not delivering real value.

To summarize, I think scrum is great at eliminating inventory waste and does so in many ways. Particularly:

1. Emphasis on task completion and how a task needs to get done before starting the next.
2. There is no reward or recognition for partially completed tasks.
3. There are no progress estimates that give a false sense of security.
4. Delivery of shippable product in each sprint is emphasized.
5. Working software is emphasized over work artefacts that don't have inherent value.

Scrum isn't prescriptive about everything that could impact inventory waste though, and it is important that the team also keeps an eye on this. I think what is especially important here is the definition of done. Scrum puts a lot of emphasis on this, but ultimately the team has to decide what their definition of done is and if this definition allows any scope for partial work to be considered done, the end result is inventory waste.