There are many discussions on the web about why Agile is better or worse (or maybe just trendier) than a traditional Waterfall model for your project. But one aspect rarely discussed is predicting the delivery date.
A waterfall (or V model) project can be represented like this:
Figure 1. V-model: Initial Project Plan
At the start of the project we devise a project plan, and our estimates lead to a delivery date being announced.
However, as the project progresses, the inevitable things go wrong, and before you know it, you are part way through the acceptance test cycle, and ‘Oh My God, we are slipping!’ The acceptance test cycle spins out of control, due to all sorts of possible causes (too many bugs? over-optimistic plans? key staff have left the project already?), and our V plan takes on the characteristics of an extravagant teacher’s tick…
Figure 2. My school teacher’s tick mark
…and the project plan now looks like this:
Figure 3. V-model: Elongated Project Plan
However at this stage there is nothing we can remove from the project to deliver it on time. We cannot reduce the scope, because we have already built it all. Pouring on more staff to increase the rate of test execution just leads to more delays (due to increased communication lines on the project: I have read The Mythical Man Month by Frederick P. Brooks, have you?), so all we can do is announce an end date slip, and indulge in petty-in-fighting to shift the blame to someone else… Not good for team spirit and definitely not good for the project, client or organisation, because pointing the finger of blame does not help anyone get anything delivered in a timely fashion.
But…
If we use an Agile, Iterative delivery model, such as Scrum, then we have some alternative remedies.
Scrum has an ordered Backlog of requirements (called stories), and in each cycle (sprint) we aim to deliver a small subset of requirements. Each sprint contains a mini V cycle of design-build-test, and the output is releasable quality.
After a few sprints, we can measure our velocity*, and predict our rate of completion of stories, and hence when we are likely to finish.
(*The velocity is the number of story points that we can deliver in each sprint. A big story is estimated at more points than a small story. There will be more on estimating story points in a future post…).
Figure 4. Iterative Plan
So when part way through the project, we can reliably determine if our initial plan was hopelessly optimistic, and then we do actually have some options to solve the problem.
We could reduce the scope, by re-ordering the backlog so that we deliver some requirements after the planned delivery date. (Let’s face it, some requirements were just ‘nice-to-have’, and some probably affect only a few end users, so if they don’t get what they want on day one, well, it is an acceptable compromise). The backlog should be ordered, and each requirement should have a measurable benefit to the business, so we know why we are delivering it, and what the cost would be if it was not delivered.
If initially we thought we could achieve 20 story points per sprint, but actually we only accomplish 15, then we should plan future sprints at 15 points, and therefore some requirements will be delivered later. We will need additional sprints to deliver the remaining stories, but at least we can deliver something at our initial planned delivery date.
Figure 5. Iterative Plan with Extra Sprint
Alternatively, we could recruit an additional Scrum team, and split the requirements. It is possible to add more staff if done early enough, and if we separate the requirements cleanly enough. For instance, the Reporting team don’t really need to know much about what the UI team are doing as long as the interfaces are defined cleanly enough. (You do have clean interfaces and separation of responsibilities, don’t you?)
I experienced projects that followed these patterns when working for one particular client. Our first project was waterfall, and the ‘9 month’ project delivered after about 18 months, once we eventually reached the end of the tail of the V when the testing spiralled out of control… Our next project used Scrum, and the 9 month project delivered a cut down (but sufficient for launch) set of requirements in month 9, then we had a few more sprints (cycles), to deliver the removed scope later, and hardly anyone noticed!
So, my conclusion is that if you want to predict your end date accurately, and to be able to do something about fixing it when you do discover it is slipping, you need to be able to measure the rate of progress of all activities of the project from an early stage. This is much more straightforward with an iterative model like Scrum rather than with the V-model, where many activities don’t start and therefore cannot be measured until too late.