This Month’s Pattern *

76 The Sun’ll Come Out Tomorrow

The manager believes that average future progress will exceed average past progress.

You manage several project teams. You have just poured yourself a cup of coffee and are settling into a conference room with your team leaders, about to review the progress of some of your current development efforts. The first project on the agenda is new to you. It has been under way for a couple of months, but came under your leadership only recently, due to a reorganization. The project manager is relatively junior, but you have heard great things about him. Let’s call him Jerry.

Jerry begins by bringing you up to speed on the project. He is using three-week iterations, and his team has just completed the third of them. During each of the first two iterations, the team did not get through all of its planned work, and had to carry some of it over into the subsequent iteration. The trend continues. At the end of three iterations, the team has completed only what it had planned to finish in the first two. (Some of the specific work elements have changed, due to shifting priorities and a little bit of scope creep.)

You’re not exactly delighted to hear all of this, but at the same time, it’s not entirely surprising. Eager teams tend to be a bit too optimistic about the amount of ground they can cover, especially early in the development cycle. So, it shouldn’t be too difficult to make some course corrections. After all, there are five more development iterations before the planned beta release, with four additional iterations planned for stabilization and for responding to customer feedback on the beta. You just want to ensure that Jerry is thinking about how he will close on these milestones, so you ask, “What adjustments do you have in mind, given the progress thus far?”

Jerry: “Actually, we’re pretty confident that we can stick to the original scope and schedule.”

You: “But in order to do that, you would have to complete six iterations’ worth of work in the next five iterations.”

Jerry: “Yes, and we think that’s entirely reasonable. We’ve got a great team, and everyone is stoked to make these dates.”

You: “That’s great to hear, but then how do you account for the slippage you’ve had during the first three iterations?”

Jerry: “Oh, that. Well, it was no single big issue; it was a bunch of little things, strictly one-time type setbacks.”

You: “Tell me about a few of them.”

Jerry: “Sure. Well, there was that big network outage last month. The outage itself lasted only eighteen hours, but recovering from it cost us a couple of days. Then Darlene’s father died suddenly, and she was out for a week. As you know, she’s our product manager, so we are dependent on her both for requirements and for acceptance of completed features. Then Sales popped up two weeks ago, needing help with a proof of concept for this massive deal they’re trying to close. That one took three guys off-line for several days.”

You: “You’re right. That’s pretty unusual. Anything else?”

Jerry: “Just a couple of others. You know about the big day light-saving time fiasco? Well, that caused a bunch of customer support cases that required time from our developers. And, oh yeah, Jason got called up for jury duty, and since he had postponed it three times, this time they made him do it. He was out for two weeks, and he was the key dev. on the off-line support feature. So, we had to push that off until later.”

You: “Wow. One thing after another. Given all that, you and your team did a great job getting as far as you did through three iterations.”

Jerry: “Thanks. Like I said, they’re a fantastic team.”

You: “So, what percentage of your time during iterations four through eight have you set aside for problems like these?”

[Uncomfortable silence.]

Jerry: “Well, uh, we don’t anticipate having any more problems like these. These were exceptions. You can’t know when things like these are going to happen. I mean, the whole daylight-saving time problem was caused— literally—by an act of Congress. How often is that going to happen?”

You: “So, let me make sure I understand. You figure that you can hit the original dates without having to cut any features, because you have incurred all your bad luck during the first three iterations, and from now on, all your luck will be good?”

Jerry is not a bad manager. Jerry is a dangerously optimistic manager. This may be because he holds an optimistic view of the world and cannot believe that some number of as-yet-unpredictable setbacks will befall his project in the future. But even if Jerry is not a natural optimist, the dynamics of the project may give him an incentive to behave like one.

Consider Jerry’s more realistic alternatives. If he assumes that his project will experience average bad luck in the future, he will most likely have to consider some combination of scope reduction and schedule extension. (Yes, he could seek additional resources, but this is less likely to aid his project in the short term.) Depending on how Jerry perceives that you—his manager—would react, Jerry may be unwilling to declare the need to make such painful changes.

Jerry’s reluctance to propose feature cuts, or a new ship date, may also arise from the fact that—at this point—he can’t prove that he needs them. The planned work fits, if only barely, into the time remaining, if and only if nothing goes wrong. If Jerry did ask to cut a feature to make allowance for future bad luck, and you or someone else challenged the need to do so, Jerry couldn’t point to any one specific problem that justifies the cut, because it hasn’t happened yet.

Extreme Programming offers an elegant approach to counteracting this kind of optimism; it is called “yesterday’s weather.”* The productivity of the next iteration (the one being planned) is assumed to be no greater than the actual productivity experienced on the prior iteration (the one just completed). Whether you use yesterday’s weather or your own adjustment, the one thing you know for sure is that your project’s future bad luck will not be zero. So, plan accordingly.

    * Kent Beck and Martin Fowler, Planning Extreme Programming (Boston: Addison-Wesley, 2001), Chapter 8, pp. 33–34.

* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.


Brussels, Mastering the Requirements Process
21-Feb-2017 to 23-Feb-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works

for details. 

Oslo, Mastering the Requirements Process
21-Feb-2017 to 23-Feb-2017

Suzanne Robertson teaches Mastering the Requirements Process. For more information on this popular course, contact Den Norske Dataforeningen.

London, Mastering the Requirements Process
14-Mar-2017 to 16-Mar-2017

The Spring edition of Mastering the Requirements Process with James Archer. Please contact IRM UK for details.

Brussels, Mastering Business Analysis
22-Mar-2017 to 23-Mar-2017

James Archer teaches Mastering Business Analysis. Contact IT Works for details of this course.  

London, Mastering Business Analysis
28-Mar-2017 to 29-Mar-2017

James Archer presents Mastering Business Analysis. Please contact IRM UK for details and registration.

Rome, Mastering the Requirements Process
3-Apr-2017 to 5-Apr-2017

Rome, Mastering Business Analysis
6-Apr-2017 to 7-Apr-2017

James Robertson teaches Mastering Business Analysis. Contact Technology Transfer for details of this course.  

Hilversum, Mastering Business Analysis
10-Apr-2017 to 11-Apr-2017

James Archer teaches the popular Mastering Business Analysis. Details from Adept Events in English or Dutch.

Stockholm, Mastering the Requirements Process
9-May-2017 to 11-May-2017

Brussels, Mastering the Requirements Process
13-Jun-2017 to 15-Jun-2017

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details. 

Hilversum, Mastering the Requirements Process
13-Jun-2017 to 15-Jun-2017

James Archer presents Mastering the Requirements Process for Adept Events. Details and registration: English - Dutch.

in depth

A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."

Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 

Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.

James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.