In a previous blog post I talked about applying Lean Thinking to a software development environment and what concepts can be translated from the Lean Manufacturing Practices. Another concept within Lean Thinking involves getting rid of all the waste. In a manufacturing environment, these are considered to be the 7 wastes:
(just click on the waste to directly go to the detailed explanation)
While some of these may sound obvious, for others you may have to change the way you look at things in your development environment to actually see these wastes. To help you change your point of view, allow me to clarify how these manufacturing wastes translate to a software factory.
Waste #1: Transport
Transport is probably the hardest waste to discover in a software development environment. When you think of an IT department, the end product is a virtual thing, it’s a piece of software that resides on some server. How on earth will this be transported? Copy on a CD/DVD and ship it to the customer? It could be, but that it completely at the end of the line in your process and most of the time, this has nothing to do with de IT department itself. So how exactly can tasks or bug fixes be transported during the development process?
Instead of thinking about a physical transport, you have to think about how tasks get from one developer to the next, from designer to developer, from the analyst to the designer etc. This kind of waste introduces yet another type of waste, which is called setup time. If I take a practical example of this transport waste, let’s assume a developer has finished a task and hands over the task to a tester. Let’s assume the tester has just finished another task and the task can be picked up immediately. The tester first has to look at the task to understand what it is supposed to do or fix. Then he has to start up the application and get to the proper step in the application to test what has been programmed. I’m sure you can images that it takes some time to get to that point (and I’m still leaving out the possibility that the task needs to be deployed on a test environment first).
This is what is called setup time and in this case it is generated by the handover to the next step. Of course, there are many other situations where the setup time comes into play, but this is just one example to demonstrate a point. Another clear example of transport being a waste is the fact that when you handover a certain task, it usually does not get treated immediately by the next person in the process chain. So, in a way, transport also introduces additional waiting time, which I’ll discuss in detail later on.
On a side note and if you’re really picky about physical transport of a task or bug fix, you could also consider the fact that a paper note with the task number needs to be placed in different locations on the Kanban or Scrum board throughout your development cycle. 
Waste #2: Inventory
Inventory is another form of waste in a software factory that might not seem obvious when you first think about it. It’s software! You don’t stack software somewhere in a warehouse where you can result in overstock, right? Actually, you kind of do that, with the only difference that you call this backlog. The more items you have waiting to be tackled, the more stock or inventory you’re building.
Now, backlog isn’t the only type of inventory you have in your software development environment. If you think about it, how many items, tickets, feature requests have you begun working on, only to have to put them on the side for a while because you have a higher priority, you are waiting for another piece of software to be installed first, you have to wait for a customer’s response etc.? Starting a task and not finishing it straight away for whatever reason – the other 6 wastes can be reasons for this to happen – also results in inventory building up.
Waste #3: Motion
Motion is together with Transport the hardest waste to discover at first. It really needs you to start thinking about the tasks and process differently. When you talk about motion is a software environment, you automatically start thinking about how a task, which is a virtual item, can actually move. But that’s just a wrong point of view.
Motion is all about physical motion: people or objects that are moving. And when they are moving, they are not contributing anything to the Value Added time. However, not all motion can be considered waste. If you look at manufacturing, there motion can easily be identified by people having to get materials in different locations, or the product having to be moved to a storage room or even to the client’s location. Movement is logical and easy to understand in that kind of environment.
But what about motion in a software environment? People don’t sit at their desk all day long (ok, some of you might think so, specifically for the software industry). But the truth is that people are actually running around the office quite a bit. A couple of examples:
- Getting and updating tasks on the Scrum board
- Unavoidable meetings
- Talking to other developers/testers/managers
- …
You would be amazed at the distance your team members are actually walking each and every day. Now, how do you eliminate the waste of motion as much as possible? Well, you probably know this instinctively, but putting people that are working on the same project in the same room works a lot more effectively than when they are separated by a floor or sometimes even another building. Why is that? One reason is simply that communication is a big factor in performance optimization and with shorter communication lines (literally) communication comes more natural, more direct and more instantaneous, which brings us automatically to our next waste: Waiting
Waste #4: Waiting
When Work In Progress (WIP) sits around, waiting for the next step in the process, it is not being handled efficiently. Tasks that are waiting on something are adding Non-Value Added (NVA) time to your process, delaying the delivery of not only that item, but of all items, because sooner or later, this task will have to be picked up again.
Non-Value Added time can best be described as the time you spend on a task for which the customer is not willing to pay. Good examples are bug fixes, quality control etc. Some of this NVA should be eliminated all together, but some of it can be classified as Business Value Added (BVA) time, meaning it is time the client isn’t willing to pay for, but is necessary to keep the system running at a certain quality level.
Waste #5: Overproduction
Overproduction is a typical waste within a software development environment. In my opinion, it exists on 2 levels. The first level of overproduction is scope creep. Scope creep happens when you set off with a defined set of features when you start developing, but after a while additional features need to be implemented as well, or the features change. This will result in additional work that was not foreseen at the start, which in turn leads to longer Process Lead Time (PLT) and monger delivery cycles.
The second level of overproduction can be made aware of by applying the Pareto principle. If we apply this principle, we can say that 80% of your target audience will only use 20% of the features. You will probably spend a lot of time developing those features that will hardly ever be used. Does that mean you should not develop them at all? Definitely not! These bells and whistles are often delighters; things that make clients happy. They may result in having an advantage over the competition, attracting more clients. And since you’re in business to earn some money, attracting more clients is always a good thing.
Waste #6: Overprocessing
Every software development department has some kind of process that describes and guides the way tasks, feature requests or bug fixes are handled. Having this documentation readily available and well known by the team is a necessity to keep the workflow moving. However, with all good intentions of breaking the process up into many different defined steps for clarity and strictly defined responsibilities, you run into the risk over overprocessing the entire process.
As mentioned, a process flow needs to be defined, but too many sub-processes or steps within your process only make it more complex. Increasing complexity causes confusion and sometimes frustration amongst the people that have to follow it. Everybody hates the government’s red tape, but on the other hand, you introduce this red tape in your own working environment? This will add more waste to your process because people spent time on things like figuring out the next step, getting all worked up because a colleague has to handle a certain subtask and he’s not available at the moment etc.
Another thing that happens when you have a very complex process flow is that you will have overlapping tasks or responsibilities. Sometimes 2 people will undertake the same action in different steps of the process. Is that really necessary? Can’t you simply eliminate one of those tasks? Sometimes you can’t, because they add an additional quality control step. But I’m pretty sure that in a software development environment you usually can eliminate one of the 2 tasks, avoiding duplicate work and speeding up your process.
Waste #7: Defects
Defects is probably the easiest to recognize in this line of wastes. A defect is a concept that is well known in the software development business and very easy to explain. A defect occurs when the software product, patch or feature request does not perform as it should be. The definition of "as it should be" is also defined buy the customer. If the customer isn’t happy with the solution you’re offering, you have a defect.
Now, as you can deduct from the previous sentence, a defect isn’t necessarily a bug. If the client orders or buys a product and it doesn’t fully meet his expectations, you have a defect. If you’re talking about an actual bug, that should definitely be fixed. But not all defects can be fixed. Sometimes you run into limitations that don’t allow you to satisfy the customer 100%. In other cases it’s just not financially feasible to satisfy the customer’s needs 100% and you have to make some tough choices about what to implement and what gets scrapped. The cost of satisfying that specific need would be higher than the return on investment. And of course, if you have multiple clients (which I hope you do), you can’t satisfy each and every one of them to the same extent.