There's a vicious game being played daily in the lives of software developers. The rules to this game are not clear cut, and it can change its structure rapidly. If you're not careful, the game will end up controlling your work schedule for quite some time. In this column, Johanna Rothman gives a referee's point of view of this game and reveals the secrets to winning.
Tristan, the senior manager in charge of all projects, strides into Ilene's office and plunks himself down in her visitor's chair. "Ilene, you are the project manager in charge of the project to save the company, right?"
"I really need you to fit this other feature into this release," Tristran says. "We're toast if we don't get it in."
Ilene looks at the feature, asks a few questions, and sighs. "Let me talk to the project team and get back to you."
Ilene gathers her project team and explains the situation. No one is happy, but each person agrees: "We just can't say no, even though it will blow our schedule out of the water."
Tristan and the project team are playing codependent schedule games. The management schedule game is "We gotta have it. We're toast with without it." The team schedule game is "We can't say no."
Too frequently, the management game causes the team schedule game, even when team members know it's not a smart thing to do.
History of the Game
So why do smart people try to fit one more thing into a release? Why do smart people agree to do something they can't accomplish in the given amount of time? Both parties have the best wishes of the company in mind, but they're fooling themselves into thinking they can somehow do more without any extra cost.
Tristan, the senior manager, may well have a reason for his request. Maybe there's a particular customer who wants this feature, one who'll pay a substantial amount for the feature. Maybe the previous release had a gaping hole, and Tristan wants to head off more complaints. Maybe the competition just came out with a similar feature.
And, Ilene and her team may also have a good reason for agreeing to the request. They want to do the best job they can on this release. But blindly accepting more work, without discussing the cost in reference to time and money and the impact on current work, doesn't do the company any good. On the contrary, it starts a downward spiral. The spiral starts with this project's delay (because of the extra work), which starts the next project with fewer people (because they're still working on the previous release) and/or later than it needs to start. The team may take shortcuts with the current project to make the date-increasing the product's technical debt. With fewer people on the project, the new project accumulates technical debt faster. And since that next project is late, the world keeps changing. Each successive project finishes later and later, perpetuating the spiral.