Do you think that by removing deadlines from a project a team will have enough time to create perfect software? Theoretically, it's possible, but in this column Mike Cohn explains that this theory might not hold against ingrained behavior. He recalls how several teams reacted when deadlines were lifted from the projects they were working on. Their only goal: to produce perfect software. But that goal inadvertently brought something to the surface, that old habits die hard.
I recently had the rare opportunity to observe a development team working on a project from which all deadline pressures had been removed. However, those pressures were replaced with something else--quality pressure. The team responded in an interesting and unexpected way, which led me to some observations about how we respond to schedule pressure.
This team was not writing software for pacemakers, the space shuttle, or any domain where you might expect an extraordinary level of quality pressure. Rather, they were developing a fairly typical Web-based application. Quality issues would cost--in Allistair Cockburn's terms--discretionary money. That is, each failure in the site would cost the company a few hundred dollars, which is not enough on its own to truly jeopardize that particular company.
The company removed all schedule pressure because of past issues with the reliability of a part of their Web site. Even though this part is used by customers only during a short portion of each year, it was so buggy that the company determined they would begin losing customers if it was not dramatically improved. The developers were told to take as long as necessary to fix this part of the site with the expectation that the rewritten portion of the site should be perfect. A goal of no defects in that area was established.
I checked in with team members periodically over the next few months while they were engaged in their tasks. Every time I met with them they had established a new deadline for themselves. They'd say, "We want to be this far along by July," or "By August we need to be able to handle these types of transactions." I'd ask them how they'd established those deadlines. The answer was always the same: No businessperson had asked for a specific amount of progress by a specific date, but the team had decided how far along it needed to be at various checkpoints to feel good about the overall progress.
At first I didn't understand why this was happening and I would simply encourage team members to remove the deadline pressure. I'd remind them that the CEO had stressed to them that the goal of "no defects" outweighed any urgency in delivering the feature quickly. After a few months of this pattern, I eventually realized that the team liked schedule pressure but did not like quality pressure. Schedule pressure is comfortable to us; we are used to it, even though we often fail to meet the schedules. The pressure to do extraordinarily high-quality work is foreign to us. It also puts us in the uncomfortable position of having no excuse other than to admit our inability to do perfect work when defects creep into our work. With even the slightest bit of schedule pressure, a team can rationalize: "That bug happened only because we were hurrying." Without schedule pressure, a team has no such easy-to-reach excuse for any defects.
In another case, a project manager told me her team wasn't hearing her message about the need to focus on quality. She said that even though she'd stressed the importance of doing extremely high-quality work, team members kept falling back into old habits of rushing through their work because of a perceived need for more speed. We discussed how often she was communicating the need for high-quality work; she replied she was conveying that message a couple of times per week. We then discussed how often she talked to the team about deadlines, and she said the subject came up at least once a day during the team's morning standup meeting.
Because teams are hypersensitive