Or “Why shouldn't we do a traditional phase gate approach to projects?”
Or “How can we start working and still deliver 'on time'?”

When you move to agile, there is a tendency to say “we'll do this agile thing with developers, but we will keep our traditional phase gate approach to approving budgets”. After all, to decide whether we should spend the money “we will need to know how much it will cost and that means we will have to do some level of analysis before making any decisions.”

This leads approach leads to a couple of problems for the business and the agile teams. From a business perspective it has a tendency to increase the amount of work in progress and so actually is not the best economic approach. In many shops there is also a tendency to spend a long time in evaluation which means that we are not going to be able to easily respond to business conditions. However we will have a need to change direction, and so we will kick off another project, starting with analysis, and so on and so on.

There is a couple of bigger problems with this thinking which we have already discuss:

• We talk about steering the project, rather than hitting a target, driving highest value first as described in How Does the Agile Approach Allow Us to Deliver Early?
• We talked about small vs large batch sizes (where a big release of project funding is definitely a big batch) as described in What Is The Effect of Batch Size On How Long It Takes to Get Something Done?

But there is something even more basic than that.

All this analysis takes time. “But its time well spent” I hear you say. Is it? The premise of agile is that we cannot predict what is going to happen - our customers will discover what they want, we will discover how to build it. What this leads to is that agile approach, an approach based on ability to respond quickly and cheaply to these changes.

It is a recognition that no amount of additional analysis will provide you with a better plan. When you do your first level of analysis, you make assumptions. When you do a second level of analysis, without the benefit of an objective milestone (for example, a demo of running tested features) then you will build assumptions on top of those assumptions. More analysis, more assumptions building on top of each other. Here's the problem. If one of those assumptions then the whole plan falls apart, like pulling out that bottom block in a game of Jengo.

But here is the rub. While you are doing all that analysis, you are not producing running code. Now if go back to the idea of delivering high value items first, there is another effect.

Take a look at the diagram. This is the same diagram in as before for a fictitious project. On it we see the the value delivered by an agile project doing highest value first. Compare this with a project where we do up front analysis before we start working any value delivery. How much time do you spend on detailed requirements? Industry statistics indicate that this could be anywhere from 30-50% of the total project time. What about financial analysis and all the details required to get through a “start project” phase gate? How much does that add the total project time?

It doesn't really matter. No matter how you look at it in the time an agile project could be delivering a large percentage (40%? 50%? 60%) of the expected value for the project, the traditional approach has still only completed analysis, leaving all the risk remaining in the project. And remember, not only do we have no value delivered, but the additional analysis has also increased the risk associated with our plan.

Does this really make economic sense?

Of course not.

This is not to say that we don't do approval for work when we take on an agile approach. Of course we do. We just minimize the analysis based on what is realistically possible, then start working anything that gets through while using fast feedback to adjust the course we are heading based on latest information. In particular, we end up making more smaller bets based on current information, perhaps releasing money every quarter instead of developing a “committed plan” for years in advance.

And yes, I understand, this is a change in the thinking. It will probably mean you will have to get the finance people, the business people, and the marketing folks involved in the change in thinking process. But given the economic benefits that could result, isn't the change worth the effort?