Codependent Schedule Games

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?"

Ilene nods.

"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.Breaking the Rules
Feeling guilty leads people to disregard the facts. Here, the facts are that adding more features to a release without removing anything else guarantees the release will take longer and not produce what the company wants. So, instead of feeling guilty, ask some questions.

If you receive a request from a senior manager to add one more thing in a release, your first question could be something like "What don't you want in this release so I can see if I can find a way to fit this in?" Or, make the costs of the request explicit: "I see why you want it, but it will take two weeks longer to build than the other features. We can't just take one feature out and put this one in; we need to rethink the entire release. Do you want me to do that now? It's going to take the team some time to estimate and replan the release. Let's make sure that is what you want."

If you want to make sure you never get into a position like this, build a prioritized list of features. And, move to time boxed iterations, making sure to implement by feature and always having releasable software at the end of each iteration. Management can always re-rank the list of features—and it's very clear that to add something for the next iteration, some other feature has to come off the list. If you can release on a short cycle, you can get management to stop asking for additional features late in the game. And you don't have to say yes even when it's impossible. You break the downward spiral with frequent releases.

If your customers don't want frequent releases, that's OK. Not all your customers need to take every release. Sometimes your customers are testers; sometimes they're senior management. Sometimes they're people who use the system every day. But part of what breaks the codependency and the spiral is being able to see the new features working.

The Key to Winning
Attempting to jam more features into a release adds technical debt and may cause a delay in the release—yet teams everywhere try to do so. If you're deep into the downward spiral, move to time boxed iterations, finishing feature by feature. Work with your management or marketing to decide when you can release. Keep a rank-ordered list of features to add, and add them in time boxed iterations in that order. It's the ability to change the rank ordering between iterations, coupled with short iterations that takes the immediate pressure off and breaks the spiral.

Saying "We gotta have it" and "We can't say no" allows managers and project teams to blame each other for not knowing which features are most important and not implementing by feature. You don't have to play those games. Ask questions and organize the work so that you are able to release at frequent intervals. That will stop the codependent schedule games and provide a product to your customers faster.

Acknowledgements
I thank Dave Smith and Dwayne Phillips for their review.