As mentioned in a previous blog post, waste elimination is usually the most obvious and least resistant way to improve value and flow in a product. So I’m just going to jump right into some of the waste factors that are usually easy to identify, evaluate, modify and sustain their solutions in software product development. Not going to cover all forms of waste, just the most common ones.
Bugs and Defects.
A bug, in simplist terms, is any behavior of the system that do not meet the expectations of the customer. Defects have a bit broader scope of who’s definitions cross into other forms of identifiable waste. A defect may not be a symptom of the product itself, but rather of the team, or communication patters, or materials transportation, or processing and production. Missing a deadline is a defect, but it is a defect of a larger entity than the product itself, same as missing information (most commonly found in requirements gathering, prioritization, feedback loops). Bugs cause rework. Rework is waste. Retest is waste. Every single bug and defect, no matter how large or small, has an impact on the overal production cost of a product, due to having to revisit ideas and code that have been addressed in a previous cycle.
Movement of Artifacts and Materials in Excess (Transportation)
Unnecessary movements are wasteful activities, and by unnecessary, I mean movements that do not add value. Routing is probably the largest culprit of excess transportation. Routing of materials is usually something that has room to be streamlined and improved and should be looked at promptly. Signature requirements, too many eyes involved, processes out of sync or sequence, lengthy lead times, report approvals, data replication techniques, poor configuration management, lengthy feedback loops; all of these are usually causing too many movements to be involved in order to achieve a goal and end up increase the cost of production. One thing not so obvious? Office layout. Yes, the layout of the facility in which teams work in very often causes excess movement of resources. Think about that one.
Waiting overlaps into excess movement a bit, but still has its own caveats. Feedback loops. This is where most software teams have room to improve in waiting. In manufacturing, its usually materials and inventory shortages that cause excess waiting. When you wait, you waste. That’s obvious and simple. Waiting pops up in so, so many ways in software development. Document generation and reviews, bugs and defects, resource shortage (not enough staff), somebody on vacation when collective code ownership is not practiced, no continuous integration, no unit tests, wrong kanban levels, manual and lengthy deployment scenarios, poor workflow… I could go on and on. Usually in software, like mentioned in the beginning of this paragraph, its feedback loops. And more common, is feedback from your own product, not the customer themselves. Feedback in the forms of unit tests, integration tests, build servers, metrics reports, code reviews, a customer on the team etc are critical to the elimination of waste generated by waiting.
Backlogs (Excess inventory)
In manufacturing, this would be identified as excess inventory. Scrum is an obvious process to identify “inventory excess” in the form of a complete backlog. In lean, any backlog item that cannot be identified as a customer need based on actual, current demand, is excess and should be gotten rid of. If its important, it will resurface later. Managing those excess backlog items is a wateful activity and may cause issues that lead to less than ideal planning and processing. Removing excess backlog items that are not pulled based on current demand may surface issues that need to be addressed, such as hidden processes and schedulings that are causing waste.
Over-processing is most commonly found in the form of writing a piece of code that does not pertain directly to the needs of the customer. Beahvior driven design is the way I use to elimate this wasteful activity. By practicing behavior driven design, I know that each and every line of code can be traced back to a customer requirement. Code that is written because you think you might need it later, system reconfigurations, unnecessary refactorings, writing code is a very elaborate way when something simple will suffice; these are all wasteful activites and are not adding value to the product.
This ties a bit into over-processing, but production is a result of processing, so when you have over-production, you’ve already over-processed. Building modules that are not required and completing items when they are not part of the current demand of the customer are forms of over-production. Even though the customer has not requested a feature, if you have built it, now it become excess inventory in the product that has to be maintained (carrying costs). Not only that, its much more likely to have to be reworked when and if the customer does make a request for that feature, if it doesn’t become obsolete alltogether.