Just tell me exactly what you want
Life would be so much simpler if our customer would just tell us exactly what they want the product to do. I wonder why they don’t just write it all down, then we can go off and build it?
In my experience, the customer can’t do this because they don’t know exactly what they want. They have a feel for what they would like, but they don’t always know what is technically feasible given the time & budget constraints. There’s almost always a trade-off between what they would like and what they can afford; maybe Feature A could be a little more robust if a couple of bells and whistles are dropped from Feature B, for example.
But let’s assume the customer chooses to write down exactly what they want: a lot of information is lost in the translation between the customer’s brain and the requirements document, and more between the document and the dev team’s brains. I’m sure most people are familiar with the “broken telephone” game, where the first person says a phrase to person 2, who in turn says the phrase to person 3, and so on down the line; eventually the last person hears something quite different from the original message. Unless the people in the chain can check back with the originator, then they will make assumptions and mistakes.
The third reason I see why the customer can’t just write a wish list and push it under the door of the team room is a more sensitive one. It requires some maturity on the business side to admit that they don’t know exactly what the end user wants. It’s not easy for someone, especially in a more senior position, to admit that they don’t have all the answers. The reality is that we know that they don’t have all the answers, but acknowledging that can be difficult.
The reason they don’t know exactly what the end users want is often because of the diverse user base – if you have just a couple of users, then you could ask them directly, but if you have hundreds or even thousands of users then you’ll probably get hundreds or thousands of different responses. Many users don’t know what they want because they don’t know what’s possible – who knew they wanted a phone that could also exchange text messages, surf the web and play music before Apple told us that’s what we needed?
Of course not every idea will be a success (no-one remembers the 20th Anniversary Mac for a reason!) so it’s important to test frequently and make adjustments based on user experience – run small experiments that test a hypothesis and adjust your course based on the results.
This is why the third part of the Agile manifesto says “we have come to value customer collaboration over contract negotiation“.
If the customer had written a spec that said “build a website where I can buy books using my Discover card”, signed off on it, then the team take a few months to build it, test it, deploy it … and a year later, there’s a website that almost no-one will use. It’s exactly what the customer said they wanted, so they ought to pay for it (says the dev company). It’s not going to be profitable, so why didn’t you build me what I need? (says the customer) Sadly it ends up with everyone pointing fingers and no-one is happy (except maybe the lawyers).
Instead, the customer could say “let’s investigate if people want to buy books online”; the team creates a simple sign-up form, and within a few days the customer can see if there’s enough interest in the concept. OK, great, let’s proceed. Let’s create a page to test which credit cards people are most likely to use. Aha – so now we discover that we ought to support Visa or Mastercard first. Maybe, after we add AmEx, we’ll see if there’s enough demand to pay with Discover to make it worthwhile.
The short feedback loops inherent in Agile don’t just allow the customer to change their mind – they ought to encourage the customer to test out ideas and not be afraid to kill off some of them. But in order to do this, there needs to be flexibility and collaboration, not contracts that force everyone to waste their time & money just because that was what someone wrote.