Alex Steer

928 words | ~5 min

This might get a little bit technical. But hopefully not too much.

If you work anywhere near software developers or digital project managers you'll know about agile projects, and the Agile Manifesto that underlies this way of working. If not, in essence it defines a way of working designed to make projects less slow, unwieldy and painful. It values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Good things, I tend to think. Except the last one.

Okay, controversy time. I make plans for a living. I try to make them as painless as possible for the people who have to work with them. That's why I think good plans need to be single-minded and minimally complex. I won't say 'short'. Sometimes they're long. But they should be as short as possible.

I also work in an agile environment, and I'm learning a whole new set of ways of talking about projects - as are many planners, now that planning is increasingly happening in technology companies as well as communications agencies and marketing departments. For those interested in some of the implications of agile environments on the job of planning advertising, I recommend Neil Perkin's presentations on the subject - first this, then these. The single most important point (for me) in all of it is the idea that advertisers shouldn't be too hung up on structures, roles and processes, and that planners should pitch in whenever they can be helpful. Which in turn just suggests to me that you should hire smart, quick-thinking, adaptable people. (Though I can't really imagine anyone ever advocating the opposite.)

But in the terms of the Agile Manifesto, planners don't really have a place on the project team - because agile teams value responding to change over following a plan.

So at risk of heresy, here's why I think this part of the Manifesto is a bad thing.

When you establish a culture that sees following a plan as a bad thing, you damage that culture's ability to respond to change in an effective, considered manner. What matters to that culture is the speed and vitality of the response - not its quality. And when you do that, you end up with the continuous iteration of rubbish. Yes, you produce lots of rubbish, with an air-punching sense of urgency and at breakneck speed - but it's still rubbish.

Privileging iteration over quality means you lose all the other stuff that the Agile Manifesto values.  Individuals don't want to interact with what you make. What you make doesn't work. And you can't collaborate with your customers because you won't have any.

Following a plan is not the opposite of responding to change. Plan-making is a response to change, and good plans let you assess the quality of your responses too, by defining how you will know if you're on the right track.

What the Agile Manifesto really tells us is that plans need to start with objectives, people and capabilities. What do you want to do? (Here's a tip: keep asking 'why?' If you want to build a website - why? If you want to develop a new product - why? If you want your ads to be funnier - why? Until you hit a wall you can't break down - the basic objective of what your organisation does, which is probably to make money somehow, if you're a business.) And how are people and capabilities going to get you there? What do your people have? What do other people want? What capabilities do you have (or need) to get where you want to go?

Agile projects can get stuck in feedback loops. You can spend a lot of time iterating, making incremental improvements to features. Sometimes this is fine - if it's provides you with the capabilities you need to meet an objective, in a simple and minimally complex way. But if it doesn't, sometimes you just need to chuck stuff out and replace it. Sometimes you even need to chuck out the plan - which is why a good plan, as I said, has those 'is this working?' tests built in. (This is a bit Catch-22, obviously - sometimes a bad plan is so bad, it doesn't let you realise it's a bad plan.)

This stuff isn't hard - but it does require focus. I've started watching the Tour de France a lot more this year, and am amazed at Team Sky's performance, which feels to me like the definition of agile strategy in action: a single clear objective, years spent building the people and capabilities, and enough common agreement that they know how to vary the formula day by day as circumstances dictate.

So all that said, I like the agile way of working. But it's not done yet, and as it moves from pure software development into marketing and other areas of business, those of us who think plans are good things need to find ways to include them in the process, for the benefit of the people along the way, and at the end.