Let’s say you’re an Agile guy. You are pragmatic, and you perfectly understand the importance of added-value-driven development. You hate Big Design Up Front even more than his big brother “Big Requirements Up Front”. Why? Because it assumes that your customer knows exactly what he wants, and will never change his mind. And you know that it is ALWAYS wrong to assume that.
But let’s say you’re a contractor too, and at some point, before even starting to work, you need a contract. And where there is a contract, there are commitments.
Usually, the first one that comes into play is budget. That’s the big thing in the business world: customers want to have full control over their costs, and as long as your product is not online, your project is nothing but cost to them. Then of course, you can’t commit on budget when you don’t know what you will be asked to do for that budget. Or your customer has a strong time constraint, and tells you that your product has to be ready for such date. And that’s when excellent commercial skills start to become handy: budget, time and scope, those are three very difficult commitments to combine… and negotiate.
The problem is that if you’re just a good commercial guy, you end up committing on all of them because the customer is king, right? WRONG! Because you’re an Agile guy!
Imagine your contract as a bucket, and each commitment is some amount of water. If you start pouring budget and time in your bucket, then unless you’re very good at estimating technical constraints for a given functional scope, your bucket is very likely to overflow with scope water. And even though you know exactly what amount of functionality you can still pour into that bucket, it’s very likely that you will lose the market because other contractors won’t be as “good” as you are. And it’s the same with budget and scope first. Even if you’re good enough to estimate exactly how much time it will take, your customer is likely to be disappointed and to choose another contractor, who promises to do it in less time (even if he’s less realistic than you are). And it’s even more difficult when time and budget are strongly dependent on one another.
I heard someone in the back of the room: “And what about scope and time first?” Come on! Do you know many customers who can tell you “OK, we want to achieve that goal during that time, and we don’t yet about budget.” Well, there are such customers, there are such situations, but that’s more typical of a non-fixed price project. OK, so let’s say that you want to do fixed-price.
I guess the problem at that point is that there is always too much water for this small bucket, because of competition and because the customer doesn’t understand a thing about what you’re doing.
So, what’s the solution then? What’s the Agile Solution? Let’s quote the Great Martin Fowler, in his famous article about Agile Methodologies:
This doesn’t mean that you can’t fix a budget for software up-front. What it does mean is that you cannot fix time, price and scope. The usual agile approach is to fix time and price, and to allow the scope to vary in a controlled manner.
What does “controlled manner” mean? In other words, what third commitment can you use to just fill the bucket without losing the market?
Well, I would say it depends on your customer but I see at least two leads…