Extreme Schedule Negotiation

See PlanningGame for another take on the same activity.

In ExtremeProgramming, we focus on FourVariables on any project: Resources, Scope, Quality, and Time. Even when the project is under stress (see FourVariablesUnderStress), the actions you can take must all work within the relationships between these variables.

In XP, we have UserStories for everything that needs to be done, and we estimate stories at the story level for our CommitmentSchedule, and at the level of each EngineeringTask to do our three-week IterationPlan.

The result of this is that, unlike most project teams, we actually do know how long it is going to take to get done. We have become remarkably accurate at this estimation, probably due to having so much practice at it.

When there is a new proposal for something that needs to be done (i.e. a change), we don't get upset, we just estimate it. We ask where in the priority ordering the new thing should go. We know how much engineering we can produce per unit time, so we know just how much it will push downstream.

If the user is thinking of a specific date to be done, we just say, "OK, we're 5 engineering weeks over that date, please remove 5 weeks worth of work to get us back inside your date."

Now, of course nothing will make a truly irrational user or manager become rational. However, imagine how much better equipped you are to negotiate, and to remain calm, when you know how long it will take to do what is being asked! The result is that at least one party in the room is able to talk about what the tradeoffs are and can be. You can actually give user/management the information they need to make an informed decision. More often than not, they will fight the hook a little and then get down to solving the problem.

Remember that people will raise objections as they go. Sales training (take some if you get a chance) will teach you that the first time an objection is raised you should ignore it. Usually they're just noise. If the objection really matters to the person, they'll bring it up again.

Here are some objections or threats and our parries:

That should only take you two days!

Our best estimate is one week. We don't have a developer who will estimate two days. It seems prudent to go with our best estimate.

Work overtime!

We tried that. For two weeks we got a little more done, but after that it actually slowed us down because quality dropped. We'll actually go faster working our usual hours, which are already well over 40.

(This intrigues me. In typical British companies, anything over 37.5 hours per week is overtime. It may not be paid overtime, of course :). It seems to me that what you are saying here is that you already work extra hours, but you are reluctant to call it overtime. Or am I missing the point? ) -- FrankCarver

In France anything over 35 hours per week is overtime. Having 2 hours per day for lunch and 7 weeks of paid vacations per year is heaven.

Recall that all this is an imaginary for example conversation. But where I hang out, many programmers work extra hours just because it's fun. What we're saying here is that folks should work their natural hours - to work more is unproductive.

You have to make the date!

We are dedicated to making the date. As you can see, there is too much to do. You can help us select things to defer.

I'll get someone else!

If you can get people who can do this better than we can, we recommend that you do so.

I'll buy a product!

If you can find a product that does what you've asked us to do, we recommend that you buy it.

--RonJeffries

---

Which one did Chrysler do? See CthreeProjectTerminated

---

For more XP scheduling information, check IterationPlan and CommitmentSchedule, and the pages pointed to from there. C3 uses a three-week period for the IterationPlan. Questions welcome of course.

I wonder. Would be productive or counter-productive to hum "You can't always get what you want" by the Rolling Stones as people filter into a meeting? Probably counter-productive.. Sometimes I get the urge to burst out in song.

Define "GoingPostal" for programmers: a whole team jumping on the meeting table shaking their butts, singing YCAGWYW. -- MichaelFeathers