Faster, Better, Cheaper. That's the way agile is usually sold. Faster delivery, with better quality and lower cost. That's the pitch I hear over and over from people trying to get organisations on board with agile. It's an attractive pitch too. Who wouldn't want something faster, better and cheaper? The only problem with the pitch is that it's not really true. Not initially anyway. Agility will eventually get an organisation delivering faster, better and cheaper but, at least initially, it will be slower and more expensive (it will usually be better quality though). It may well stay slower and more expensive for a long time if the organisation has to overcome a lot of legacy (not just code but culture and processes as well).

So when the organisation goes to measure its new agile initiative and finds that it's not getting what it was sold, questions get asked. And well they should. The first is usually "Why?", to which the standard answer is "cultural change is hard....", the next is usually "When?", to which the answer is usually a shrug and some more about how hard cultural change is. This is often the point where the senior leaders that were really keen on agile, suddenly stop being keen on agile and organisational support vanishes. Given the length of time it takes a big organisation to get to faster, better, cheaper with agile, we really do ourselves no favours by using that as our selling point. What we need is something we can have an immediate (or at least relatively quick) impact on, that is also going to have a positive impact on the business. Fortunately it exists - risk. Agility should be sold as a means of reducing risk.

Given that many organisations see an agile transformation as being a source of risk, pitching agility as a risk reducer may be a bit of a surprise. It's true though. Agile is all about reducing risk. What's more, it is particularly good at reducing the risks that business really cares about - delivery risks.

The biggest risk in any project is that it won't deliver. The organisation will spend a lot of money and receive nothing in return. Agile is particularly good at reducing this kind of risk. By providing high visibility into the project through the regular delivery of value, and the regular reviews and metrics that go along with that, agile helps the business ensure that the project is on track and will deliver. Or if it won't deliver, providing very early warning, so the business can re-assess the project.

If you compare an agile project to a traditional project, the difference in delivery risk profile is stark. A traditional project delivers all of whatever it is supposed to deliver at the end, or at best in a couple of large phases. Because the business has very little real insight into what is going on during delivery, it really doesn't know whether the delivery will happen until it happens. We have all seen the last minute wrangling that goes on close to the delivery date. Delivery dates get shifted, scope gets dropped.

Everything is a surprise to the business, because up until then it had been told that everything was going well. It is this failure to reliably deliver that has broken down the trust between the delivery side of organisations and the business side. No matter how many steering committees, stage gates or progress reviews the business insists on, because they are assessing progress against a schedule with no real deliverables to back it up (and by real deliverables I mean working stuff... not specs and designs), the situation never seems to improve. The business really has nothing more than the project manager's assurance that things are going as planned. There is no real evidence to back that up.

By contrast, an agile project with its regular reviews, and metrics based on actual delivered, working stuff, gives the business far greater insight into the actual state of the project and hence much lower delivery risk. That's not to say that dates aren't going to be missed or scope isn't going to be adjusted or dropped, but it shouldn't be a surprise. In a well-run agile project, any changes to scope and dates should be flagged well in advance and made in consultation with the business, not presented as a fait accompli a few weeks before go live. If a project is going to fail to deliver, I would hope that we discover that after one or two sprints, rather than one or two years.

What agile really gives the business is release predictability. Way more important than fast delivery is the ability to predict what will be delivered and when. Agile, with its fast feedback loops and focus on actual progress, gives that to them.

There is also another delivery risk that isn't often considered - the risk that the project will deliver whatever it was supposed to deliver, but that the organisation will not get the benefits from that delivery. This can happen for many reasons - the product fails in the market because it's not what the customers want, or the assumptions were wrong, or conditions have changed. The benefits may have been oversold. There are dozens of reasons why a project fails to deliver benefits. Essentially, they all boil down to producing the wrong thing. Fortunately, agile provides ways of dealing with this.

The key of course is fast feedback. By producing working stuff quickly and regularly, the business has a chance to test its assumptions early. That testing could be via internal review or it could be with real customers, or focus groups, or whatever. Regardless of how the assumptions are being tested, the business isn't flying blind. This ability to test assumptions and the ability agile brings of being able to change direction when needed, allows the business to significantly reduce the risk of producing the wrong thing.

Fast feedback is key to risk reduction. Not only in delivery risk but technical risk as well. The ability to run discovery spikes around our technical unknowns is a key risk reducer. If we have a significant technical risk, prototype it early. Either it works, in which case the risk goes away, or it doesn't, in which case the project may be doomed but now we know about it early rather than at the end.

An agile approach can make an immediate and very significant difference to the risk profile of projects. So rather than sell agile based on faster, better, cheaper, which are goals that will take a long time to hit, why not sell it on something we can make a difference to quickly - risk reduction? It's probably more valuable to the business that faster, better, cheaper and it's something we can have a much faster impact on.