The Value of Something

"A house is a machine for living." - Le Corbusier

"Have nothing in your house that you do not know to be useful, or believe to be beautiful" - William Morris

The difference between these two quotations is one of the most important differences between Agile and other methods of project management. Beauty is a word that doesn't get used much in software development. But really what Morris is pointing out is that in any complicated project - such as decorating a house - there are competing values. Actually, by insisting on only utility and beauty, he's trying to rule out some of the other competing values that might have been in the Victorian and Edwardian mind such as "have this in your house because your neighbours have it" or "have this in your house because it is in keeping with your social status".

A specification document is a list of functions. Things that a machine will do. Perhaps not a machine for living, but a machine for booking airline tickets, a machine for allowing teachers to upload videos of their lectures. But lurking behind that list of functions is a mass of values. Maybe they're straight-forward business values, such as "make it easier for our customer to book airline tickets when we're all asleep". Maybe there are slightly more complicated values, such as "Our competitors got a system like this so we have to have one." Maybe there are values that no one will ever admit to out loud: "My rival for the top job has got his pet technical project, this is mine."

So what does Agile do differently? How does it deal with values? First thing is the planning game. The customer has to prioritise the stories. In order to prioritise things, you have to use values. If you're working in a strict Scrum fashion, then you've only got one person representing the customer - the "Product Owner". Maybe you haven't been quite so strict and you've got several representatives of the client in the room. Either way, listen to what they say. Pay close attention to the reasons they give for putting one story above another. Those are their values that they're talking about. This is the Agile process bringing them to the surface.

Second, Agile insists making something that works as soon is possible: at the end of the first iteration. Once you've got something that works, everything changes. When there's nothing to point at, when there's nothing to show, when there's nothing they can have people actually use, managers have no alternative but to stick with attaching value to delivering on a plan. The demo of the working code for that iteration - the "sprint demo" is the second important point to watch out for the customer's values. Once the customer has something that actually works, the "value landscape" completely changes.

Curiously, when all they had was a list of functions, the customer's values could be all over the place. Now the customer has something that could actually improve the performance of their business, that could make their lives easier, something that actually works, it's very likely that their values will focus around the functions that it actually has. Can we make it go faster? Can we make it secure? Can we do that for all file formats? Frequently, as part of this process a whole list of things that were in the initial specification as "nice to haves" will be completely forgotten.

But what if that isn't their response? What if the response to a demo is stunned silence or outrage and fury and the customer says "That is not it at all, that is not what I meant, at all." One of my clients took one look at a demo and then went and sat in a corner, arms crossed, staring at his feet saying "Well, I suppose that is what we agreed on. I suppose that's OK." I was inclined not to believe him. What if it turns out that story number 34 that didn't make the first iteration was the thing that was really important?

Well, you didn't get it right first time, but at least you found out early. The whole of the budget isn't spent. The deadline for presentation to the board of directors hasn't yet arrived. You can do something else. The awful truth that no one likes to mention is that few people - clients or developers know what they're talking about until they've got working software in front of them. A lot of the values around any project lie tacit and submerged not clear even to ourselves. Agile processes help bring these values to the surface.

Perhaps the most quotable man of all time, Oscar Wilde said that a cynic is someone who knows the price of everything and the value of nothing. If that's true, Agile is the opposite of a cynical process. The purpose of Agile processes, of story prioritisation, iteration and demonstration is to find out what is truly valuable and deliver it to the customer. Even if it is one painful bit at a time.