Intended Work and Wasted Work

This article discusses the work we do that is valuable and the work that is not valuable, work that lean calls “waste.” In knowledge work, activities such as planning and estimation are not waste because they help to shorten the cycle time of the work being done, unless planning or estimation is done to excess.

Table 1. Examples of valuable work and waste in knowledge work

There is a pattern to wasted work that is worth understanding.

Valuable work is work that makes progress on the mission of your organization. Wasted work is created when mistakes are made, or misunderstandings occur. Mistakes and misunderstandings cannot be entirely avoided, but it is important to realize that the effects, or cost, of wasted work greatly increase with the time before it is detected.

To reduce the effects of wasted work, it is important to try to minimize the time until it is detected:

• If a requirement is redone, any effort that went into analyzing and developing against the old requirement statements is wasted work.
• Building the wrong feature is usually due to miscommunication between the customer (or their proxy) and the development team. The greater the delay between getting the initial requirement and building it will increase the amount of work involved in correcting the error and hence the amount of wasted work.
• Unneeded features are common in our industry because of too coarse and unclear requirements, which can lead to excessive implementations. Building the most important features iteratively in small batches creates an opportunity to learn about, and re-assess, the usefulness of the remaining features.

Building the most important features in small batches is a basic tenet of agile/lean which helps accelerate value realization while shortening delays in feedback. All of this contributes to reducing the effects of wasted work.

Example: Bugs in Software

Let’s take a closer look at defects, or “bugs”, in software code. To correct a defect in code, two activities take place: investigating the cause of the defect and correcting the code so that the defect no longer occurs.

Defects make their way into code for a variety of reasons. The longer the time between when a defect was introduced in the code and when it is corrected, the more difficult it becomes, and the longer it takes to investigate the cause of the defect. The team may have moved on to building new features, in which case the developer tasked to correct the defect will have to refresh their understanding of the context of the defect; or the code base may have evolved to a brittle state, and adding more code caused other parts to fail, in which case the investigating activity also will have to involve some learning and discovery to understand the bigger picture of the defective code area.

Once it is found, fixing the bug usually does not take long. It is finding the bug that takes the most time. And that is what causes delay. The longer it takes before looking for the defect, the longer it will take to find the bug especially when the team must remember or even relearn the code before they can start looking.

Other Examples of Waste

Consider some other examples of waste in Table 1. Overbuilding frameworks and duplicating code are more often due to a lack of technical skills which can be improved by using design patterns and emergent design. Duplication is also exacerbated by delays as sometimes people forget what has been done.

What is commonly referred to as integration errors are often errors that occurred well before the time of integration. That is, the integrator integrated just fine but the teams needing to integrate did not stay in sync with each other. The error lay in the fact that the components that were integrated properly just didn’t work properly together. And it is not accurate to call it an “integration” error anymore than calling a bug caught during testing a “testing” error. That is simply when it was found.

The greater the delay between when the error was introduced and when it was detected (during integration) leads to delay and waste. This is why continuous integration (just like test-driven development) is good. Continuous integration isn’t about avoiding integration errors, it is about detecting miscommunications between groups working together as they occur.

June 2023

• Acceptance Test-Driven Development
• Continuous Integration
• Why looking at delay is so important

• Advanced Software Design
• Design Patterns Thinking
• Sustainable Test-Driven Development