When I told my mother that I was writing a book about agile, her first reaction was, of course, supportive. But she wasn’t really sure what I was talking about. “Agile… that’s a computer programme, isn’t it?” Not quite, Mum! But she’s not the only one who has some funny ideas about what agile entails.

Part of the confusion is that there are a lot of specific agile methodologies, which mean people get hung up on the jargon and specific techniques. But that’s not what agile is about either.

What is agile then?

At it’s heart, agile involves taking an iterative approach, learning from your audience as you go. It’s a way of working that encourages focus and close collaboration, relying on the idea that if you give motivated people the support and environment they need, they’ll produce great work. Agile flips lots of work conventions on their head, particularly ones about power. You shift from things being led top-down, with detailed plans and lots of bureaucracy, to self-organised teams deciding what to work on and reflecting regularly together.

Agile has a whole bunch of specific techniques. You might have heard of some of these! For example, retrospectives are a structured way for a team to think about how they are working together, which has been adopted by many teams even if they aren’t using agile more widely. There’s lots of other tools for things like prioritising and coordinating work, but that’s all they are – tools. The values and attitudes behind agile are the important bit, and all the techniques you might hear about are just structures to help you put those into practice.

Doesn’t tech come into it somewhere?

My mum was partly right when she mentioned computer programmes, because software development has played an important part in the history of agile and it’s where it’s most widely used today. This means when you start looking into agile, it’s easy to get bogged down in lots of technical ideas that don’t seem that relevant outside of that field. But agile is useful in lots of different settings! I’ve talked already about how agile has emerged in lots of different spheres of my work – let’s look at one of those in detail.

Agile in a traditional fundraising team

Agile has transformed the way we manage the big, cross-organisational fundraising appeals that my team leads on. We had two inter-related challenges that lots of you may be able to relate to:

1. A high volume of work, much of which is time-sensitive and risks driving out the less urgent but more important tasks.
2. A desire to improve and grow, but with many possible routes we could take and no clear way to decide what we should focus on.

Both of those challenges are essentially about prioritisation – how do we focus on the most important things? How do we work out what the most important things even are? So, whilst there’s lots of ways agile has helped us (not least, enabling us to get more done, more efficiently), I’ll focus on how it’s helped us prioritise.

Prioritising regularly through backlog refinement

My team has a long list of things we think we should do at some point. Some of these are very practical (we really should write an internal comms plan already), some are bigger picture (we’d like to come up with a new process for developing a strategy for our Christmas appeal; we want to find a new way to engage with corporate partners; it would be good to talk to that team about how we can collaborate more). The list is called our backlog.

Once a month, we meet to decide what we want to focus on from the list. We each shortlist a few things from our backlog, and then collectively rank those in order of importance. In practical terms, this means we compare two items at a time on our shortlist and ask “which of these would be more impactful for us to focus on in the next month?”. Someone shouts out an answer, and we use this to order a list of high priority tasks. Then we decide how much we can realistically do together, break those tasks down and work out who should take them on.

This is a surprisingly simple practice that’s made a real difference to how we work! We make so much more progress when we try and do five or so things in a month instead of thirty or forty. It turns out when we stop stretching ourselves so thin and all pull together in the same direction, we get a lot more done. And the collective prioritisation means we are getting the most important things done – our work has much higher impact because of it.

But agile is about mindsets and not techniques…

Backlog refinement is an example of an agile technique, and it’s a good one. But the reason it works is because of some of those values and attitudes we touched on earlier.

Firstly, focus. As we’ve already discussed, it’s much better to do a few things well then a lot of things inevitably badly.

Second, learning as you go. Because we prioritise on a monthly basis, we’re able to try things and learn from them before deciding what to do next. We’re not attempting to predict what will help a year from now at the beginning of a project, because that’s impossible. Nor are we giving up entirely and just focusing on delivering what we’ve always done. If you work in software development, you might do backlog refinement more frequently, but once a month seems to be the right cadence for us.

Finally, we’re prioritising as a team, rather than me deciding as the manager what we should be doing. It turns out that collectively we are much better at prioritising than I am on my own! No one person knows everything, not even me. Using the wisdom of the group to choose what we focus on leads to much better choices. And it gives each member of the team more ownership over what we do. They are motivated by their choices and think through practical implications that I had no idea about.

That’s one small example of how agile has helped us. I’d love to hear from you – have you tried backlog refinement? What difference does it make to your work?