The Single Most Important Thing in Agile

Another stand-up; another pointing session. Each team member recites the mantra ‘where I am with my work and how long do I think there is to go.’

As the ceremony unfolds, the scrum master notes down the project blockers and extracts a promise from the product owner to help clear them.

After the team has gone, I reflect on why management is paying me to help them with their Agile development. It's quickly obvious: The team knows how to use the tools, they know the process; it’s the principles they haven’t grasped.

Unfortunately, the one principle they need to grasp isn't explicitly stated in the Agile Manifesto.

Agile, for all that it can be broken down into best practice activities and output, is about just one thing: You can only give people what they ask for, not what they want.

I once rewrote the 12 principles of the Agile Manifesto to reflect the strongly held view of mine that there is really only one principle and the rest are just rules. I only released two of them because I got a backlash from people who thought I cared about scrums and backlogs and sprints and blah and all the things they care about.

I have no aspirations to be anyone’s scrum master, and I don’t care about any of these things; packaging work up and managing delivery and expectations is not unique to Agile, and it’ll be here for as long as it is obviously better to use a kettle to make a cup of tea than boil the ocean.

What I do care about is that people understand why we work in Sprints, why we insist on the participation of the business, why Agile is such an effective methodology when properly understood.

The reason is this:

If you can only give people what they ask for not what they want, then you’d better show them what they’re going to get as soon as possible and involve them in bridging the gap.

Don’t let some bright spark claim that this gap is a problem of an ineffective requirements gathering process. Duh! Of course you should try as hard as you can to get the requirements nailed down accurately (is this a conflict with the Agile Manifesto’s be happy with late changes? Discuss).

Accurate requirements can’t solve the problem that people don’t know what they want until after they see what they’re going to get. If there is any doubt about the truth of this, here’s an exercise that I use to demonstrate it:

Get a group together, any group it really doesn’t matter, sit them down so that they face you, and get yourself a flipchart. Ask the group to list all of the features of a car that they think they would need. Write every feature down – steering wheel, seats, wheels, gears, etc.

At the end, when there are no more requirements forthcoming, draw them a car with one of the actual features of a car missing – there will always be dozens!

The last time I did this the team forgot that they might want their car to have doors (and brakes, and an aerial for the radio and…). You can play the ‘you forgot to tell me something that you only realized when I drew a car without it…’ game endlessly.

In other words, until they see the car and discover what is missing, they don’t think to ask for it.

Agile is a methodology that was formed to bridge the gap between abstract requirement and real-world want. It implicitly acknowledges the existence of the gap by requiring the business to participate and therefore to be complicit in the process of development and delivery.

It is the best methodology I have ever seen for overcoming this problem, and this problem is the single biggest cause of pain in software development. This problem is the reason for the existence of the universally hated Change Request, which is about who is going to PAY for the gap.

The solution – that you need to show people what they’re going to get so they can help you build it for them – seems so cheap I’m ashamed to sell it.

Then again, the team that has been working in an Agile manner for several years left the room to work on their sprint without ever telling me (or each other) what it is we’ll be able to see either during, or at the end of it.

It might be Agile to them; to me it’s just coding in the dark.

Originally published October 2014

Further Reading

Why Don't Software Customers Just Say What They Want?

How to Handle Software Requirements Change After Implementation Has Begun