The first step in moving towards this optimal development zone is identifying the kind of waste that can and should be avoided. Granted, there's some unavoidable waste inherent in the software development process. For instance, examples of such waste include basic R&D that doesn't get productized, prototyping, and so forth.

The scope of avoidable waste, however, is quite substantial. It can include:

• A day spent fixing a build break that occurred because someone checked in code without locally compiling it. This happens more often than most managers think.
• Two weeks spent debugging a missing curly brace. This seems incredible, but can actually occur when the team is looking at functional manifestations of this error and trying to debug the error from that end.
• Figuring out what the heck this variable g stands for. This is a result of poor naming conventions.
• Nominal case design and development. This is typically a result of ignoring corner case conditions.

Notice the common thread here: a lot of waste stems from late detection of defects that could have been found much earlier or prevented altogether. This applies to all types of defects - including missing requirements, lack of error checking for unexpected user actions, or structural code problems.

Motivators for Waste Reduction
One benefit of reducing waste is that it allows your team to reach a development point that results in reduced development time and a very low percentage of remaining defects. Thinking back to the "development time versus percentage of defects removed" graph in the earlier section, the organizations that are in the optimal area of their development cycles are those that dramatically reduce their waste by targeting defect removal earlier in the process. Thus, they achieve both higher quality software and lower development costs.

The other tangible benefit of reducing waste is that it improves the professional life of developers. Their job satisfaction typically goes up when they're relieved from having to spend excessive time fixing bugs (unproductive work), and can instead focus on the creative tasks they enjoy the most.

Five Countermeasures to Development Waste
Five cornerstones that have been proven to reduce development waste are:

• Robust development infrastructure
• Consistent coding - personal and team practices
• Consistent peer code review
• Early testing
• Automated regression testing

Finally - and most important - reducing waste in a systematic manner also requires a reporting system that enables teams to track qualitative progress towards their goals for all five of the above countermeasures.

The strategies above are explained in the following sections.

1. Robust Development Infrastructure
A robust infrastructure automates repetitive tasks, organizes project activities, tracks project status, and seamlessly collects project data to provide measures necessary for decision making. Most of all, this infrastructure sustains and facilitates the improvement of human-defined processes. 

Figure 2 illustrates the foundation of a robust development infrastructure.

This foundation comprises the following components:

• Source control system: The source control system provides a central place where the team members can store and access the entire source code base. It gives each developer the freedom and safety to write, modify, and re-factor code on his or her workstation. Having a source code repository is also a prerequisite for regularly scheduled automated builds. All of the files needed for the build should be in the source control system, including build files, scripts, etc. not just the source that is being built.
  
• Nightly build system: The automated build system builds an application on a regular basis by automatically executing the required build steps at the scheduled time without any human intervention. Without an automated nightly build, development quickly gets out of control and waste increases. Ideally, builds run nightly. This way, any problems are detected the next day (as opposed to a week or more later). However, the key is running them on any type of regular and frequent basis that suits your needs. Unless regular builds are run in an automated fashion, the probability of producing working software on time drops dramatically.
• Requirements management system (and/or bug tracking system): This is a repository for storing and tracking defects and issues, as well as the developers' ideas for improving the application. Defects are stored so they can be tracked, analyzed, and ultimately prevented from recurring. The system can also be used for storing feature requests and tracking feature and requirement changes. The end result is a central repository of information related to your software.
• Regression testing system: A regression system is any tool or combination of tools that can automatically run the core of the existing tests on the entire code base on a regular basis. For example, the regression system may be a script that runs one or more testing or defect prevention technologies in batch mode. Its purpose is to identify when code modifications cause unexpected faults, especially those faults that occur because a developer didn't fully understand the internal code dependencies when modifying or extending code that previously functioned correctly.
• Other tools: This can include tools for static analysis, code review automation, performance profilers, memory analyzers, coverage analyzers, etc. - whatever automation the team finds reasonable (or can afford) to leverage for productivity.
• Reporting system: This system should be able to gather data from all these components (source control, nightly build, tests, etc.) and present them in a visual way to enable status and trend analysis.