In my last post, Meeting Deadlines: What’s wrong with this Release Plan #1, I noted that the ability to commit to and deliver on near term deadlines is a reasonable and necessary accomplishment of a professional agile team and enterprise. To achieve this, we depend a lot on the release planning function (see Release Planning category on this blog and this article in the Agile Journal). In the last post, we looked at a flawed release plan from one perspective. In this post, we’ll look at the same plan from another perspective.
In Waltzing with Bears by DeMarco and Lister, the authors posit that software teams aren’t historically very good at estimating and meeting deadlines. In my personal experience, that has absolutely been the case and the projects I have tracked over the years are typically late by about 50-100% of the initial schedule. In other words, six months becomes more typically nine or twelve. (Here’s a fun exercise: you do the math to see what an old-time, twelve-month plan becomes. And then reflect back on your last big waterfall project!).
This is illustrated with the probability-of-meeting-the-deadline graph from their book, which looks roughly as follows:
Don’t worry too much about the shape of this curve, because it isn’t a science and I can’t draw worth a hoot anyway, but the point is that the probability of delivering before the deadline is basically zero. This is because we’ve most likely identified all the tasks that must be done on the project and they can’t likely be accelerated due to all resources being allocated.
And since the area under the curve (total probability of meeting the plan) is 100% (assuming that it will eventually be delivered at some point), then the probability that it will be delivered on any one day predicated in advance, including the deadline date, cannot be 100%! In other words, while it could happen, it isn’t very likely and it would be a stupid thing to build external dependencies on. In addition, since it can’t be delivered early as we discussed above, the logical conclusion is that it will probably be delivered late. Sadly, our own experience has aptly illustrated that this is the most likely outcome.
DeMarco and Lister hold that the proper thing to communicate is not the deadline itself, but the probability of meeting any particular date over time. However, that is a pretty sophisticated notion for most of today’s enterprises.
So are we forever doomed to bad outcomes relative to plan?
Do we need to consider a career change?
Not if we take the lessons learned and adjust our predictive model.
Now, back to my earlier post. We saw in this post that the first plan proposed by the team was flawed, i.e.:
Relative to the risk profile curve above, the flaws are pretty obvious, i.e.:
The probability of meeting the deadline is small, since it cannot possibly be delivered early and there is no allowance for the inevitable gotchas.
In response, the team came up with a revised plan as follows:
This plan was better received at the release planning session.
Why might this plan work when the other likely would not? Because it builds in the allowance for deadline risk mitigation as the following figure shows:
This has the effect of moving the probability curve to the left. Since the third iteration is lightly loaded, it might be possible to deliver a little early, thereby starting the upward curve earlier. Moreover, with the lightly loaded third iteration having the capacity to take on the unanticipated tasks and absorb any underestimated tasks from iterations one and two, it is much more probable to deliver it on time.
The probability is still not 100%, because it can’t be 100% at any particular date, but the area under the curve indicates that there is a higher probability of meeting the date than there is of being late!
Perhaps that’s as good as it gets. This is Research and Development after all. And it’s all software, even at that.
(Refer to Waltzing with Bears for a deeper and more meaningful treatment of the probability curve and its effect on risk management.)