Meeting Deadlines: What’s Wrong with this Release Plan? (AERP7)

Ideally, we wouldn’t have deadlines in agile. As Tom Gilb noted “it’s as though I as a project manager weren’t allowed to know the projects end until the date arrived. The only instructions I’d get in advance would be to “be ready to pack whatever you’ve got every morning and deliver it by close of day” (Waltzing with Bears, pg 132). That would sure force extreme incrementalism the XP way!

Practically, however, deadlines DO matter and the ability to predict a reasonable near term deliverable is one of the hallmarks of effective agile enterprise teams. After all, many outside teams and customers are dependent on us, and it’s reasonable to expect some degree of confidence, at least in a near term deliverable. Any reasonable degree of professionalism demands it.Fortunately, defining and meeting near term deadlines is one of the purposes of release planning, that quintessential practice designed to coordinate and steer large numbers of agile teams in a common direction. (Note: an entire discourse on release planning is posted under the cleverly named category “Release Planning” elsewhere on this blog.

I recently published an article in the agile journal (Experiences in Release Planning at Enterprise Scale: Two Seminal Days in the Life of an Agile Newbie) , an inside-out (i.e. practitioners) view of agile release planning, I don’t know yet if anybody read it, and it’s a little long anyway, but I thought this little extract might speak directly to the topic. In this article, in response to some objectives from product management, Mo and his team came up with a release plan that looks as follows:Draft Release PlanThey were pretty proud of this plan, as it appeared to meet the deadline and left room for some “hardening” activities (reduction of iterative technical debt) at the end of the release. The agile coach, Bill however, quickly underwrote their confidence with the following dialog:

Bill: It looks like you guys are in pretty decent shape for the release? But the plan looks pretty heavily loaded?
Mo: Yeah, we think it’s doable.

Bill: I see you have some stories in the hardening iteration. Do you think you’ve identified every story that you will need to meet the release objectives in the earlier iterations?
Mo: Well most of them.

And then the killer question sequence came in rapid fire…

Bill: What’s the probability that no new and significant stories will be discovered in the next 60 days”?
Mo: ummm, probably zero.

Bill: What’s the probability that you have estimated all the stories you have identified accurately, or overestimated the time it would take for each
Mo: ummm, probably zero.

Bill: What’s the probability that every dependency you have on other teams will be addressed exactly as planned?
Mo: ummm, probably zero.

Bill: “What’s the probability that no one on your team will be sick or take a currently unannounced vacation in the next 60 days?”
Mo: ummm, probably zero.

Bill: “What’s the probability that integrations with the other components will work as smoothly as you hope?”
Mo: ummm, probably zero.

Bill: “So what’s the probability that you will be able to deliver your component on time?”
Mo: ummm, ummm, probably zero.

Bill: “I think you need to rethink your release plan and come in tomorrow with an answer way above zero.

After some out-of-box, productivity-enhancing thinking, (see the article) they came up with a revised plan which looks as follows:

revised-release-plan1.jpg
This plan, at lease, would seem to have a much higher probability of success. Here’s why:

  1. It leaves room for stories that could not be anticipated at the time of the plan
  2. It reserves an entire iteration for the reduction of technical debt
  3. It leaves room for overflow of stories that were initially underestimated
  4. It leaves room for the inevitable gotchas, interdependencies and refactoring that are sure to follow

Some might call this a “gutless” plan as it doesn’t look stretched beyond belief. And it isn’t. Rather it is simply, considered, logical, practical and probable. In other words, just one less impossible thing to believe in.

One thought on “Meeting Deadlines: What’s Wrong with this Release Plan? (AERP7)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s