When talking to stakeholders about why they want their project to go agile, the most common reason they give is speed. Faster time to market. Faster delivery. Fast, fast fast. If you dig a little deeper though, and ask what they mean by fast, they don't say things like "before our competitors", they will say things like "when you promised it". A lot of the time, speed is a kind of code for "no delays". Make us a commitment and stick to it. Don't jerk us around. What they are really looking for a lot of the time is not more speed in delivery but more predictability.

Predictability is really important to the wider business. They may have trade shows booked, advertising campaigns locked in, shareholder briefings prepared. If commitments aren't met, it can have big impacts on the rest of the organisation. I know of one organisation who sent out letters to a million customers advising of a change on a particular date, only for that date to slip by 6 months. Not only is that not a good look, it's expensive too, as a million other letters needed to be sent out advising that the change would not, in fact, be happening, then another million when the new date was announced. Fortunately, an agile approach is ideally suited to giving the business the certainty it needs. How can this be when the agile approach doesn't try to lock down everything in advance? How can you have predictability without certainty?

The key here is transparency. In a large and complex ecosystem, change is inevitable. The difference between the traditional and agile approaches is in how they deal with that change. The traditional approach is to do a lot of work up front to be as certain as you possibly can, then to essentially pretend that change will not happen. "Make decisions early, then stick to them" is the mantra.

The problem, as we all know, is that this is a fantasy. Change will happen. Pretending otherwise won't stop it. What we have is not certainty but an illusion of certainty. It's a dangerous illusion. It tells us that the project is green right up until the day when it suddenly isn't. It tells big organisations that it's OK to send out a million letters because the schedule we prepared a year ago said "send out letters", and we haven't acknowledged that things have changed. It denies change until the change becomes too big and too obvious to ignore any more, so rather than react all the time to small, manageable changes, we have to react to this sudden appearance of large change. The project is fine right up until the day when it's suddenly 6 months late. The design is fine right up until the day we need a month's redesign to fix fundamental issues.

However beautiful the strategy, you should occasionally look at the results.

Winston Churchill

Traditional projects are unpredictable because they hide the impact of change. By contrast, a good agile project is transparent. It accepts that change will come, and when it does, it will deal with it. By dealing with change when it arrives, we deal with change that is generally small and manageable.

But how does this give us predictability? Things are changing, how can they be predictable? Again, it all comes down to transparency and willingness to deal with change. A prediction is a prediction, not a promise. The prediction we have today is based on what we know today. Our prediction will be different tomorrow. Because we update our prediction as soon as a change occurs, we let the business know early so they can change their plans to match. That 6 month delay I mentioned earlier didn't happen all at once. How does a project get delayed by 6 months? 1 day at a time. If they had been transparent about change, the business would have known not to send out letters on that date. That date would have moved as other things moved around it. Change is inevitable . You can either deal with it or pretend it's not happening. It's much better to deal with it.

By responding to change as it occurs, rather than hiding it, we also become aware of how much things are changing. Some projects change a lot, some hardly at all. Which way is our project going? By understanding the level of change, we can start to refine our predictions based on our expectations of future change. In a highly volatile project, we will provide a prediction with a much greater error margin than in a project where change is small. We may give a date ± 2 months rather than ± 2 days. At the very least we would be able to tell the business that the "send out a letter" date is looking a bit dodgy and they should maybe hold off, or re-word the letter to be less specific (coming soon... or available later in the year) rather than giving a firm date to customers.

So, when the business asks for speed, it's worth digging a bit deeper to see what they really want.