One of the things I like about Lean is that it offers a metaphor that everyone involved (even executives and customers) can understand. The metaphor is that the development system is like a pipeline. Ideas go in and value comes out. Yes, it's much more complex than this but this simple metaphor will suffice for the points I want to make. I illustrate this pipeline in Figure 1.
Figure 1. Present blend of new features and bug fixes.
Note how the input contains both new features and bug fixes. The figure above illustrates how the development pipeline is one-third occupied by bug fixes, with the remaining two-thirds being available for new feature work. Now, what happens if your code quality continues to degrade? This causes two problems. First, you'll have more bugs to fix, giving you less capability to do new features. I show this in Figure two.
Figure 2. The impact of lowered code quality on the new features to bug fixes ratio.
With more time spent fixing bugs, there's even less time to work on new features. But it's worse than this looks. The lower code quality also makes working on the existing code harder. This means that even when we work on new features, it'll take longer to get them done. So, as code quality gets worse, we not only have less time to work on new features, but it'll take longer to get them done because the code will be harder to change. Of course, what often happens is that the developers just hack things in to meet deadlines. This, of course, just gets the code quality to go down faster. Bad cycle here.
If this isn't bad enough, there is another factor that can be even worse – working on too many things at once. In a lightning webinar called How Delays Cause Waste: A Main Tenet of Lean , I discuss how delays in the development cycle actually create additional work to be done. Delays of this type include the time from getting requirements until starting using them, from when code is written until it is tested and from when teams get out of synch and this is discovered during integration. My own experience leads me to believe that these delays are one of the biggest causes of low productivity and high bug rates around. Unfortunately, low efficiency by teams often results in management putting more and more pressure on development teams to get more and more done. They often do this by just piling on the work. This results in two other kinds of waste – the new work created by the delays that result from working on several things at once as well as the thrashing that also results from this. So now, much of the work of the team is lost by the pipeline getting clogged with work that is either wasted or shouldn't need to happen. This is shown in figure 3.
Figure 3. Too much WIP makes things even worse.
These factors, poor code quality, technical debt, and too much work in progress are still not the entire picture. I've left out the entire test cycle. If automated tests are not available, another kind of downward spiral occurs – manually re-testing the system before every release. If you don't have completely automated acceptance tests, this will get worse the more features you have- taking even more time away from development. The one piece of good news is that with all of these downward spirals, new features are likely to be added ever more slowly, making testing them take less time each pass - oh, but that's actually not a good thing, is it?
CEO, Enterprise Engagement Manager
Related content (too much WIP): Learn why delay is so deadly The Tenets of Lean (YouTube video)
Related content (low code quality): Roadmap to Lean-Agile Programming Competencies on our Technical Resources page .
Interested in learning how to improve your technical debt? Please send me an e-mail at alshall AT netobjectives.com OR read one of these great books from our thought leading trainers / consultants: