Recently someone asked me what to do in the following situation:
At the start of the project, there was some high level estimation done. It was estimated to be a six moth project based on which the executives committed a date to a customer. This was necessary because the customer needed some lead time to setup up some infrastructure and hire people to run it and they needed to know the go-live date by when they had to get everything prepared. It is now a month to go to release. Various uncertainties have resolved and we see that it will actually take another three months. The team is pressurised to meet the date because the client would stand to make losses as they hired all these people, but the software was not ready.
The above scenario is fairly typical in the business world. I want to state up-front that I see nothing wrong in commitments. I have heard many people talk about how agile teams never make commitments, but that is not always the right path for me. Software is not developed in isolation, and in many cases there are other downstream dependencies after the software is built. There may be a need to start marketing, perhaps we need to start training the sales team, and so on.
In the example above, we see that the client needs to start hiring a couple of months before the go-live date because hiring is a process that takes a few weeks. But if they hired people and the release date was pushed out by two months, then it is not a good situation for them. So they need to know in advance when the software would be ready.
What is the answer to this situation?
Luckily, agile is perfectly suited to handle this. Here are some techniques.
The first thing to realise is that everything in agile is about fixed date. That is what a timebox is — a fixed start date and end date. Everything in agile is based on timeboxes, or in other words, it is all about dealing with fixed end date. We handle this by varying the scope. Usually not everything is high priority. And if you have been prioritising well, then most of the high priority features are completed early in the release. So, it should be possible to cut scope and release by the end date.
Agile is actually a much better way to handle fixed dates than a waterfall process. This is because in waterfall it is very hard to cut scope near the end of the release — most of the development is already complete and the whole application is in integration or testing. So the only options are to extend the date or to cut quality; both bad choices compared to cutting scope.
Make commitments as late as possible
Adjusting scope is a fairly standard response to dealing with a fixed date. On the other hand, making commitments as late as possible is a technique that very few organisations practice. It is a technique that has become popularised in mainstream agile with the Real Options work of Chris Matts and Olav Maassen. I highly recommend their book on this topic; appropriately enough it is called Commitment.
Going back to the example at the top of this post, we ask ourselves — what is the last responsible moment to fix the release date? Since the client needs 2 months to hire everyone, the answer is that we need to fix the date when we think we have 2 months of work remaining. There is no value is fixing the date earlier — the client will still need to start only with two months to go. Yet, in project after project, the date gets fixed right at the start of the project. So, a date is fixed many months in advance, when our knowledge is the minimum, and uncertainty is highest. And then that uncertainty comes to bite the team near the release date.
A better approach is to leave the date open at the start. It isn’t time to commit yet. Then, when we see that there are 2 months of work remaining, we work with the client to fix the date. This gives the client the lead time to get their hiring done, and it is MUCH more accurate since we are about 2/3 of the way through the project, most of the uncertainties are resolved and we all have a pretty good idea of the release date by now.
Learning from movies
It is also instructive to see how movie release dates are committed. Like software, movies also have many downstream dependencies. Marketing starts much in advance, but if marketing starts too early, then it is less effective. Distributors have to be selected, contracts negotiated, and advances paid. The film has to be transported to movie theaters, and bookings open a couple of weeks before release. Copies have to be sent to critics and reviewers so that their reviews are in the papers before release. All these activities require sticking to a very precise release date.
However, if we see how that release date is committed, we see that they follow the “commit late” principle outlined above. At first, there is nothing mentioned about a release date. After some of the movie has settled in, we may see an initial trailer with a vague date like “Coming in 2015″. Once shooting is done and post-processing is ongoing, we may see something more specific, like “December 2015″. It is only a couple of months to release that the actual date is finalised, “In theaters on 23rd December”. By this time, 90% of the movie is complete and it is a pretty accurate date.
Imagine if movies took the software approach and fixed the release date of 23rd December 2015 before they even started !! It is simply not a recipe for success. Maybe we should learn from that.