A client was optimizing for what they thought was the bottleneck in their software development: the testers. In the assessment, I gathered some quantitative data about how long the testers took to test and how long it took for the other groups to perform their work. (They used a phased lifecycle.) The testers were busy throughout the entire project preparing for system test, and were completely consumed for final system test. The requirements and design part of the project took over half the project’s duration, whether that project was 18 months, 9 months, or 4 weeks. The testers part of the same projects were 5 weeks, 4 weeks, 3 days. Here’s a table showing the project durations:
|Final Test||Total Duration|
|Project 1||38 weeks||31 weeks||5 weeks||74 weeks|
|Project 2||24 weeks||12 weeks||4 weeks||40 weeks|
|Project 3||2 weeks||1.5 weeks||3 days||4 weeks|
The client was confused in a couple of ways. The first confusion was thinking if you remove time from the end of the project, you save time. Their data proved the opposite. If they could have reduced the requirements and design time, they could have easily saved tons of project time. The next confusion was in thinking testing was a bottleneck. It’s possible at one time testing was a bottleneck. They had effectively made requirements and design a bottleneck based on this data. The third confusion was in thinking optimizing for anyone’s 100% productivity will not produce any bottlenecks anywhere else.
As soon as you optimize for one group over another, you produce a bottleneck. In organizations where you need to produce more than one product, you’re better off optimizing for the strategically important projects, determining how to make each phase as short as possible (but no shorter), and making sure people have what they need to do the job. Agile project techniques help make the phases short, because you don’t waste time doing requirements and design on parts of the project you can’t finish (this organization’s problem). Artificially shortening a phase guarantees you spend more time and get less from it (as does artificially shortening a project).
A project is a system. Each group will have ebbs and flows to its work, but the best optimization you can do is to see that each person on the project has a constant, maintainable flow of work.