Eliminating Waste from your Agile Process

Posted by: Dave Goerlich in Agile.

A central pillar of a lean software development process is elimination of waste. So what is “waste” in a software development process? In a manufacturing process, any amount of work in process above the bare minimum to meet production levels is waste. Keith Swenson recently wrote an an excellent article “Taiichi Ohno Reinterpreted”  where he observed:

Just as in a car factory, you do not want to build 1000 cars in parallel, similarly in software you do not want to create 1000 features in parallel. As you start to build a car, the waste builds as you add more and more parts, but the waste disappears when the car is completed and ready for shipment. The uncompleted cars are a liability on the organization, and building cars in parallel multiplies the amount of waste. Similarly, once your start designing a feature, and start investing person-hours, the waste builds in direct proportion. Finally, when the new feature is actually in a “customer-ready” shape, that waste disappears. The started-but-uncompleted features are a liability. Features designed but not coded is a waste of time. Code that is written but not tested is a real liability because there is now a hidden amount of work that must be done to correct problems in the coding. Completed features in the code, but can not be installed are still a waste. Building a bunch of features in parallel multiplies the waste.

One of our goals with this process was to be able to handle concurrent projects. That dictates that we may have multiple features in development at the same time. A single feature per project is the bare minimum necessary to meet our production level on each project. Parallel development on multiple features for a single project also brings with it the unnecessary overhead of managing different source code branches. This unnecessary work is waste which can easily be eliminated.

Rework is another area of significant waste in a system, be it building cars or software. We determined that there were two possible root causes of the majority of our rework. Rework was generated out of either doing something wrong (quality control issue) or doing something too early (process issue).

Quality control issues broke down into two classifications – the code we wrote didn’t meet the specification or the specifications didn’t accurately represent the business need. The combination of our move to an agile development process which involves the customer much more frequently has helped address this issue. We are also making fundamental technology changes to an environment which includes tools to support BDD. Combined, these changes will go far in reducing the waste of quality control based rework.

The best example of rework due to doing something too early involves doing in-depth design for a feature long before we were ready to work on it. We would spend time laying out all the technical details of how we intended to implement a feature. Any change to the architecture or the definition of the feature by the development of prior features left us with no option but to discard part or all of our prior work. Generous application of the principle of Deferred Commitment has effectively eliminated this waste in our process.

I have traditionally wanted to over-engineer my code. I have invested a lot time building code with the mindset that someday someone might want this. A few times I’ve been right. Most of the time, however, that effort has been 100% waste. Applying the YAGNI principle has yielded a significant reduction in waste. The change hasn’t been easy for me, but the benefits have outweighed my discomfort.

A personal pet peeve is performing repetitive tasks. Perhaps that’s the fundamental reason I’m in software development. In all areas of my life I find myself asking “How could I automate this?” every time I have to do something more than once. Many of the repetitive tasks we perform in the process of software development could easily be automated and are therefore waste. The reason we developed and continue to refine our Sandstone environment is to eliminate waste. Appropriate use of quality development tools has also helped us to automate tasks and therefore eliminate waste in our process. We’ve also looked at our process itself for repetitive tasks that can be automated. Calculation of the key metrics used to monitor our process was the most common repetitive task we found. Some time invested building some simple spreadsheets has yielded consistency and efficiency in that process.

This is far from a comprehensive list of everything that could be considered waste in the software development process. These were the low hanging fruit we identified in our process. I’m always interested to hear what others have identified as waste and how they’ve worked to eliminate it from their process.