Anecdotal Observations from Development Teams Using Iterative Techniques Versus Waterfall Techniques

I have worked with a number of teams who have made the transition from applying Waterfall-style methods to applying iterative methods. In addition to all the advantages of iterative techniques we have already discussed, I have noticed one other interesting phenomenonobserving the general stress levels of the development staff.

Figure 10-2 plots my experiences concerning general trends of team stress for projects using Waterfall versus iterative techniques. This is not based on scientific research, but on my own observations across many projects. I interviewed a number of development teams at the conclusion of various projects and asked how they felt about the experience.

Figure 10-2. Developer stress levels over time for Waterfall versus iterative methods

For Waterfall projects, the developer stress level starts out very low and tends to stay low for quite some time. Usually after Critical Design Review (CDR), stress levels rise rapidly as implementation suddenly begins (after months of doing some design work and producing documentation). Initially, developers are quite happy and morale is high as they finally begin the work they really like to dodeveloping code. After a time, when the delayed risk reduction begins to hurt forward progress, developers start working overtime as they rush to solve unforeseen problems. On some projects, panic sets in. Testing often ceases. There generally isn't much time for testing as resources are diverted to fight the inevitable brush fires. If the project makes it to its deadline, the result is often riddled with bugs, morale is low, and development personnel and management are frustrated.

For iterative projects, the team stress level seems to rise almost instantly. This makes sense, because the developers begin work almost right away, designing architectures, testing, developing, and having to meet deadlines that are seldom more than a few weeks away. Then an interesting thing happensthe stress level seems to stabilize and fall into a rhythmic pattern. This coincides with the beginning and end of iterations. However, "panic mode" seldom seems to occur.

I'll never forget the first major project I managed using iterative development. I had become accustomed to the normal "panic" stages that always seemed to occur on Waterfall-based projects. It was very common to work evenings and weekends on those projects. As my new project entered the Construction phase, I assumed it would be the samelots of overtime. I designated every Wednesday as the night the entire team would work late (I bought the pizza). We did this twice before we decided it simply wasn't needed. Selected team members occasionally worked overtime, but it did not seem to be needed for the entire team. I scheduled the final iteration to end the day before a holiday weekend, knowing that if the team got in trouble, they would work over that long weekend to catch up. This elicited many groans from the team. However, when the time came, not a single developer had to work over the weekend.

I would much rather manage a group using these iterative techniques. Just judging from the stress level alone, it's much easier to manage a group where there is some stress, but it is fairly constant and stays at a healthy level.