Let’s consider the following statement:
Don’t always deliver what the customer wants;
Always deliver what the customer needs.
There’s a subtle distinction between the two parts of the above sentence, but it’s an important one.
Most of us have heard the argument "Do you really need that?" at some point in our lives, usually when it has to do with something we really want, and are willing to argue passionately about its inclusion in the realm of all things necessary. Usually, this "voice of reason" manifests itself as a parent, spouse or some incorporeal, 3-inch tall, white-robed, haloed dude – or chica – hanging out on your shoulder.
But I digress. The point is that it’s a good question to ask ourselves. Do we really need something, or is it just something we desire to have?
Wants vs. Needs in Software Development
All too often, we – the technical folks – will get a long list of requirements from our business stakeholders, some of which are necessary for them to do business, and some of which are fluff features, or “nice-to-have’s”. Unfortunately, it’s also common for these different category of features to be lumped together into the same set of requirements, and it’s difficult for us to tell which is which. It’s our own fault; we’ve conditioned our business partners to think this way.
So how do we tackle the list? Generally, I’ve seen it done one of a couple ways:
- We treat all requirements as gospel and just start running through the list until we burn out, project time and/or money runs out, or (rarely) we deliver everything.
- We start cherry-picking through the list, based on what we think the business needs.
Both scenarios have major implications. In the first, we risk burning out our teams, the business partners, or both. Burned-out folks tend to leave, or produce lower-quality results. In the second scenario, we are putting the decision of what is important to the business in the hands of the technical folks (as opposed to the hands of those who are actually doing the business work). I’ve got another post planned for this second scenario, so I’ll just leave it at that for now.
So What’s the Alternative?
Half of the Agile Manifesto talks about promoting Customer Collaboration and drawing focus to Individuals and Interactions. So, the first step is to get the business partner involved in the planning of what gets worked on first. After all, they were the source of the requirements, so they should have a good idea of what’s most important to them.
Using iterations (the backbone of iterative and agile methodologies) can also help to promote adaptive and risk-based planning by forcing the team (which includes the business partners) to decide on a subset of requirements to implement during each iteration. Responsible teams will choose features that are the highest priority. (Note the word responsible in that last sentence. Agile practices alone do not a successful team make). Iterations also help the team to "course correct" between iterations of a project if they start going in the wrong direction, or if changing business needs dictate a change in what features are most important.
And while I’ve said this before, I must stress it again. Get the customer / business partner involved. Let them tell the team what they need, and what they want. And, like that voice of reason, the team should sometimes question their needs to make sure they really are needs, and not just a want hidden behind charismatic arguments.