The Third Commitment

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…

User Satisfaction

The first way to do it one that the company I work for has chosen to experiment. The idea is that business people often assume that the more functionality there is, the happier they will be. Because that’s the way it is: quantity is king. Until you understand that too much functionality creates some noise at best, and prevents the development team from focusing on the quality of really useful features. With a little experience and pragmatism, you realize that your satisfaction as a customer is what really matters, and the amount of functionality is just one dumb simple way to measure your satisfaction.

Then your idea as a creative contractor is to try and identify new metrics for customer satisfaction, like:

• Does the application do what the end-user expects it to do? (least astonishment)
• Does it do it constantly over time? (reliability)
• Are most often used features more accessible than others? (ergonomic)
• …
• Does the application all I need it to do ? (<– this is the scope)

Though maybe the easiest to answer, the last question is only one of them. So maybe there’s a way to design a survey to actually evaluate as many criteria as possible. The idea seems better. I’ll try to let you know what we’ve come up with in a few months.

But there is already something that disturbs me in this approach: the people we’re talking to. When negotiating a contract, when trying to agree on commitments, we’re almost always talking to business people. Sometimes they know what they’re talking about. Sometimes they are potential users of the application and they know what it should look like. But in my own experience, that’s very rare.

Added Value

When the end users and the people you’re talking to are two very different groups with different concerns, then I think you should dig deeper.

What’s the purpose of software after all? As far as I’m concerned, I’m convinced that software is here to help people do their job faster and better. That’s what I associate with the concept of added value. That’s why customers invest in software: because they see it as an investment that they will compensate by saving time and money on tasks they used to perform without it.

What is the link between this and customer/user satisfaction then? Once again, some simplified assumption: you assume that the happier users are with the application, the more productive they are… and the higher the added value. The problem I see with this assumption is that users are rarely very imaginative. Unless they are big software consumers themselves, they rarely have enough software experience to even consider alternate ways to do things. I was very satisfied with my blog engine until I discovered the fat blogging client I’m using right now. The same for my transition from PC to Mac.

As software developers AND consumers, we have that experience, we can imagine new ways to do things, better and more productive ways that users and their bosses hadn’t even thought of. And of course that makes scope commitment even more absurd.

My question is: isn’t there a way to evaluate how much time and money it takes to perform certain tasks without and with the application, in order to estimate the overall added value of your development? If you could do that, then maybe you could commit on added value, or even better, you could negotiate some part of your retribution as a percentage of this added value. That way you would have as much interest as your customer in getting a better software solution in the end, what we call a WIN-WIN situation. And the way I see it, added value would be easier to measure than user satisfaction, and still so much more powerful than the amount of implemented functionality.

What do you think? What could be your third commitment for an agile fixed-priced project?