Agile budgeting

How do you build a plan for a new software project? There are different approaches, each of which has its peculiarities; I shall discuss them shortly.

Agile teams are very well aware of the fact that requirements do change, so they don't try to prevent it but ride the wave, focusing on delivering, iteration after iteration, the highest priority requirements: they are happy because they will deliver high quality software, they know their customers will be happy because they will steer the project according to their evolving needs... and they lived happily ever after. Until they talked to the management:

WHAT? NO FIXED PRICE? NO FIXED SCOPE? POSSIBILITY FOR THE CLIENT TO CUT THE BUDGET? AAAAARGH! YOU'RE FIRED! YOU'RE ALL FIRED!

I'm exaggerating of course, but I'm sure you get the point. Well... OK, that's what we'll do: we shall meet the customers, explain to them how they will get only the functionality they really need, how they will always be in control, how they will decide how their money will be spent, and all the other advantages of an agile incremental and iterative approach. So they will talk to our management, persuade them, and tell them they are really enthusiastic with our proposal and that we should get a considerable pay raise. Actually they go more or less like that:

WHAT? NO FIXED PRICE? HOW MUCH WILL IT COST? HOW LONG WILL IT TAKE? AAAAARGH! GET OUTTA HERE! GET OUTTA HERE RIGHT NOW!

Well, we have to reconsider... Agile approaches are really great, but the difficulty lies in persuading a traditional management. Let's take it from their own point of view.

In a traditional approach you spend a lot of time to write a long (and when I say long I mean very, very long) and comprehensive requirements document - which probably no one will ever really read - which in turn is, more or less, accepted by the contractor. At this point you have already invested a considerable amount of resources, but project managers have enough informations to precisely schedule everyone's work for the next months, and that allows them to estimate a fixed price. That makes the management happy because they think they are dealing with the risk of scope creep in an effective way, and customers happy because they know in advance the amount of money to allocate for the project.

That sounds great. But let's face the facts: studies show how 19% of the initial requirements are only rarely used, while 45% are not used at all. And the requirements have changed. They have changed a lot. But the plan did not. So, when the project comes to an end, customers, which have paid a lot of money, will not be happy because they won't have what they really need, managers will not be happy because customers complain, and the blame will be "on those weirdos who developed all this crap".

How can we have happy developers, happy managers, happy clients? a succesful approach is to divide the project in different phases, just like in UP, and contract for the elaboration phase at a fixed price, than use an agile Just-In-Time (JIT) approach for the construction and transition phases. During the inception you only get enough informations to estimate the scope of the project (yes, with this intermediate approach we still want to avoid big creeps) and to do enough architectural modeling to have a sufficient basis on which to produce an initial schedule and budget. In the next phases you let customers steer the project with an agile approach: they'll be more willing to do it because they'll already have the core of the new working, although incomplete, system, and the risks will be smaller. The management will have a reasonable estimate, which will improve iteration after iteration.

Still too extreme? You can follow UP and have two fixed price contracts, the first one covering the elaboration phases, and the second one covering the construction and the transition phases.

And you would get that pay raise, after all.

Forget that. "Money, so they say, is the root of all evil today. But if you ask for a rise it's no surprise that they're giving none away". Thanks to Pink Floyd for the tip (pun intended).