Working out who should be Responsible, Accountable, Consulted and Informed on a project should make roles much clearer, right?

Wrong.

Every time someone asks me for a RACI, my heart sinks. I have spent so much time agonising over so many RACIs that only a few people have even skim read. There must be dozens of massive spreadsheets I’ve written over the years to try and answer some basic questions about roles and responsibilities. Yet every time questions pop up, it seems unclear. A RACI might be a helpful starting point, but as soon as your project starts you will think of things you haven’t covered, or discover nuances in things you have covered.

If I’m honest, my RACIs have been expectation setting of the worst kind. It’s me saying ‘I’m not going to consult you about an important decision, and I’ll use this spreadsheet you won’t read to justify this to you in a few months time’. And that’s… not great?

I’m not saying that we shouldn’t set expectations, or that we should involve an unmanageable number of people in every tiny decision. But we use RACIs as the decision making equivalent of security theatre. It’s a bureaucratic piece of admin we spend a disproportionate amount of time on, given how little they help in day to day work.

What does help instead of RACIs?

The goal of RACIs is laudable. We want to be clearer about two things: firstly, who is responsible for tasks, and secondly, how decisions work – who gets to make or input on the decision and who is just informed. One spreadsheet can’t do all of this. But agile tools can be a significant help.

Let’s look at responsibilities first. Next week, we will dig into how to get input into decisions.

Use stand-ups to get clearer on responsibilities

The only way to get clearer on responsibilities is to have regular conversations about them. We’re rubbish at predicting the future and it’s next to impossible to outline all the tasks involved in a project at the outset. So don’t try to do that!

Taking an agile approach means planning in detail for the short term, and keeping it very top-line for the longer term. This is both much more realistic, and much simpler and easier to do.

One tool lots of teams I work with have found really helpful for this is a stand-up. Stand-ups are short, frequent meetings to streamline team communication and quickly address concerns. They take 10-15 minutes and are traditionally held daily, though I’ve found that weekly or twice-weekly can work well depending on the type of work.

For a stand-up to work well, you need a visual record of your work. You can use Microsoft Planner, Trello, monday.com or a similar alternative for this. The tool isn’t important, but how you use it is. All you need to do is make sure you’re capturing all the tasks for your piece of work under either “work in progress” for things you are working on now, “blocked” where you are waiting for something outside your control, and “to do” for anything you haven’t got to yet.

In a stand-up, each person should run through the tasks with their name on that are in progress. They should do this very quickly, just flagging if there’s anything unclear or where they might need some help. They should briefly check what’s blocked or still to do to work out whether they want to move anything to “in progress”, before passing to the next person.

This is a very simple format that you should be able to get through quickly. And there’s lots of benefits to holding stand-ups. They help you keep track of lots of moving pieces and they are an efficient way to make sure you are collaborating effectively. They also mean you are having regular conversations about workload so it’s easier to split this more evenly across the team.

But an underrated side effect of stand-ups is they quickly surface unclear responsibilities. You should spot immediately if there’s a task with no one assigned to it, or if someone is struggling with a task that’s bigger than they can handle. There’s no more mystery, no more hoping someone else will jump in. Having a regular, structured conversation means you will achieve clarity much more quickly.

That’s one way agile helps with clarifying responsibilities. Next week, we’ll look at the other important element of RACI and consider how you should involve people in your decision making.

In the meantime, I’d love to hear what you make of RACIs. Am I the only one who hates them? How do you approach clarifying responsibilities?

I think silence is an underrated agile skill.

That may sound odd, but fundamentally agile is a set of tools to help people collaborate and reflect. And you can’t do either of those things without silence.

Silence helps you pause, slow down and spot what’s happening. If all your meetings are non-stop talking, no one has a chance to think. It’s also harder for the quieter members of the group to speak up. Silence makes for much better meetings.

How silence feels to the facilitator

It might be incredibly valuable, but at first, silence in a meeting you are leading is so uncomfortable. Very often it induces mild panic. ‘Why is no one speaking? Argh, what do I do now?’ But once you get used to it, it can actually start to feel freeing. You know that thinking is happening, and if you just give it a moment, something unexpected will emerge.

Imagine gazing into a still pool of water. It might look like nothing is happening, but fish are swimming round below the surface. If you wait, one might emerge. But if you plunge your hand into the pool, you’ll never see them!

Thoughts are like fishes. Don’t scare them away by speaking too early.

How to tell if it’s a good silence

There’s two kinds of valuable silence in meetings. One is the silence of people working together individually. Maybe you’re getting them to note down thoughts on post-its separately, or you are using something like the silent meeting format we talked about last week.

If you can see people writing, the silence is working and you can leave them be. If you’re not sure, it’s a good idea to set a time limit for activities like this. It’s much more comfortable to be silent for a limited period, and no one will mind if it’s a minute or two longer than they actually think they need.

The other valuable silence is thinking time in response to questions in group discussion. This is harder to judge. How long should you wait before you should break the silence yourself with another comment or prompt?

It’s probably longer than you think. Silence feels much worse for the facilitator than for other participants, because you feel responsible for it. What seems like eons for you probably isn’t that long for the other people involved. And it can actually be a good thing if it starts to feel a little awkward – it gives an extra push for others to start talking.

So in general, hold your nerve and err on the side of more silence than you think. As long as you asked a good, open question that people could potentially answer, allow them the time they need to respond. Keep your questions simple and broad to make them easier to answer. ‘What stands out here?’ is my favourite for getting a conversation going after a bit of individual thinking.

How to get comfortable with silence

The best way to get comfortable with silence is to practice. Try holding a slightly longer pause in your next meeting and see what happens. Or watch what other experienced facilitators do, and notice what makes it easier for you to give good answers.

If you’re nervous about using silence, tell people! Explain at the beginning of the meeting that you’re trying to create more space for thinking and this might mean you go quiet after questions to allow people to process. Ask for feedback after your meeting to see how people found it. Chances are it will have been a lot easier on them than it felt for you.

Do you use silence in your meetings? How did you get used to doing that?

We’ve talked about empowering the team as part of working in an agile way, and how to make collective decisions as part of that. But what if you need to dig into a problem as a group before you make a decision? Here are three of my favourite tools to do just that.

Lean coffee

Lean coffee is a super simple, low-effort technique. It’s great when you have something you want to unpick but you don’t know where to start. It also works well as a way for attendees to build their own agenda in regular team meetings. And it requires very little prep!

All you need to do is introduce a topic and get people to tell you what they want to talk about. I usually give people three minutes to write down questions or ideas to discuss relating to your topic. Then we share and theme answers, before each using three votes to prioritise between them. We discuss the areas with the most votes, capturing notes and actions, continuing until we run out of time.

It’s easy, flexible, and makes sure you are actually talking about what people most care about.

Innovator’s compass

My next format is based on asking powerful questions. There’s more about how to do this here, but again it’s very simple. All you need to do is ask in turn about:

1. Observations: what’s happening and why?
2. Principles: what’s most important here?
3. Ideas: what could you try?
4. Experiments: what’s one thing you will do?

I suggest giving people 3-5 minutes to make notes on the first three areas individually, before sharing and discussing as a group. Then use dot voting to prioritise your ideas and flesh those out in the experiments stage.

Starting with observations and principles gets people thinking and leads to rich ideas for the third question. And ending with experiments helps you turn your ideas into practical actions.

Silent meetings

This works well when you want to discuss an existing idea in principle – perhaps someone has a proposal or a straw man that you want to get input on. The Silent Meeting Manifesto has lots of great tips for writing a good proposal for this.

Once you’ve got something concrete in writing, you meet to discuss, but you spend the first half of your meeting in silence. Everyone reads the document individually, adding comments and responding to others in writing. You only talk after everyone has finished reading and commenting, discussing any questions highlighted in comments that still need resolving.

I love this format. It’s much more efficient because everyone reading and writing at once is much faster than talking one by one. You end up having richer discussions, as the process of commenting means everyone has to really engage with the material so you start with a much clearer shared understanding of the issue. (No more endless recapping for people who didn’t do the pre-reading or who lost the thread during a boring presentation).

It’s also a good way to ensure more people participate, firstly because inputting in writing is more efficient, and secondly because lots of people find it easier to contribute that way than speaking up verbally in a potentially contentious discussion.

Those are three of my favourite group problem solving techniques. Do you have any others you would add?

Last week, we touched on the need for leaders to share power as a necessary criteria for working in an agile way. Flatter power dynamics have all sorts of benefits. Working in a less hierarchal way reduces the pressure on you as a manager. It uses the wisdom of the whole team, including those closest to the work who are likely to have the greatest understanding of the possible consequences of any decision. It’s great for getting your team to buy into the decisions and understand them on a practical level. And it’s good for your team’s development and critical thinking.

But how do you actually empower your team as a manager in practice?

Leaders go last

Who gets the most speaking time in your team? If power is well balanced, share of voice should be well balanced too.

For this to work you need to account for style differences. Whatever their preferences, level of introversion or neurodiversity, you need to make it easy for everyone in your team to contribute.

This means you need different ways they can give their input. If you always lean on group discussion and find you just hear from the same people, that’s a warning sign. Think about capturing written contributions, or asking people to chat in pairs before asking them to share idea. And don’t knock an icebreaker. Even for well established teams who know each other well, a good icebreaker can make it easier to contribute risky ideas later on in the conversation.

Remember that people tend to listen to you more when you are the manager, even when you’re not the best placed for an informed opinion. That’s why it’s a good idea to go last in a group discussion. Give everyone else a chance to share their views before you air yours. That way, you reduce the chance of influencing the conversation so that everybody agrees with you.

Sharing decision making

Hearing equally from the whole team is a great start. But it’s not enough if you still make all the decisions.

Practically, it’s much easier to make collective decisions than most people think it is. Spend time mapping out your options together, then use something like a dot vote to choose which one you want to go with as a team.

There’s lots more collaborative decision making tools in my guide to making better decisions with agile. But the important thing is to open your decisions up. Yes, there are some HR type decisions that only you as the manager can decide on. But if you start looking, there’s lots of scope to include the whole team in deciding what you’ll work on and how you’ll do it.

Go where your team tells you

If you make decisions as a team, you aren’t going to agree with all of them. And that’s ok. A helpful question to ask yourself is “is this safe to try?”. If trying something is hugely risky, that’s a good reason not to do it. But most things aren’t. And the benefits you get from empowering the team outweigh the downsides, especially if you are reflecting regularly together so can course-correct if something isn’t working out.

So if you hear your team telling you they want to go in a certain direction, listen to them. If someone gives you constructive feedback, visibly demonstrate that you are taking it on board. If someone wants to try something, work out what needs to be in place to make that safe to try.

What practices help you be an empowering manager?

You might already be “doing agile” – you just don’t know it yet

A common, but surprising reaction I hear when delivering agile training is that some of the content already feels familiar. Maybe one of their team draws on some agile practices even if they’ve never used the term. More likely, they emphasise with some of the mindsets I’ve shared and they can see them in their day-to-day work. Perhaps their role requires regular experimentation and they have a good rhythm of testing embedded in their work.

This is great and I encourage it. Agile is about mindsets, and if people can already start to see them in practice then they have a foundation to build on. People like being told what they are good at already! They will feel much warmer to agile and more open to trying new things if they can recognise ways in which they are already doing something similar.

It’s also helpful to acknowledge that agile is a spectrum, not a binary. You don’t have to do all the things to “count” as being agile. It’s much more approachable if you just start with one or two small things, and it’s even better if those strengthen things the team is already interested in or trying to put into practice.

Of course, there’s more to it

Agile practices reinforce each other. Labelling everything as agile feeds into some of the ways agile goes wrong, setting some fundamentally wrong expectations about what it actually is. But I think there are two complementary mindsets that are sufficient in themselves to enable genuine agile.

First, learning and adapting as you go.

This is often what people are getting at with experimentation. But doing a lot of A/B tests isn’t sufficient. You should be prepared to do things differently based on your tests, to work in short enough cycles that you can take what you have learnt from your experimentation and use that to change what you do in future. This means shifting from “oh what could we test next time?”, to really thinking through what your assumptions are and deciding what you’ll do if they are proved or disproved.

You also need to be learning from both your audience and from yourselves. A regular rhythm of reflection is fundamental to agile, which is why I’m forever recommending retros. If you really have an open, safe space to think about how you are working together and what you want to change, you will naturally get better. This takes time, but it’s like an investment with compound interest.

Of course, creating an open, safe space can be a big ask. And that’s why my other essential mindset is a willingness to share power. It has to be ok for each member of the team to speak up, share their opinions and disagree if they feel like it. And the more a team feel empowered to do that, to make decisions about things that affect them, the more you will be able to learn and improve and use the wisdom of the entire group.

There’s lots of ways for leaders to share power. Ask for feedback, make some decisions collectively, give people real ownership over the things they are closest to. Combined with regular reflection, it’s my MVP for approaching work in an agile way.

Can you see signs of agile mindsets in your team, even if you don’t formally follow agile?

Last time, we touched on two important mindsets needed for making the shift to agile: a willingness to let the team decide, and a willingness to experiment. But how do you live those out in practice?

Letting the team decide how to adopt agile

If you’re the leader, you may have some ideas about what you want out of agile. There’s probably some improvements you’d like to see, some changes you’d like to make to your ways of working. And that’s great… but only if your team sees it the same way.

The answer here is not to persuade your team to agree with you. The answer is to agree as a team what you want collectively, even if that isn’t exactly what you would have said yourself.
The way I do this is to start by introducing teams to the possibilities of agile, sharing a case study and some principles. Then I ask my magic question:

Imagine it’s a year from now, and we’ve made some really good changes to our ways of working. What outcomes would you see?

I let people capture answers individually, before gathering similar ideas together. Every time I do this, a set of clear themes comes out. Maybe the team wants to feel more connected, or have a clearer pipeline of longer term work, or more time for development.

It usually won’t be exactly what the manager would have said; there will be overlaps, but there will also be some nuance or new ideas that the manager will have missed. And that’s a good thing! The manager is just one person. Letting the team set outcomes collectively makes for better outcomes, because they will be informed by each person’s experience. It also means they will be more bought into making it happen.

Once we’ve got some clear outcomes to aim for, it’s much easier to think about what agile tools could help. I’ll suggest a few things and get the team to vote on the options.
This gives you a great start, but you still need another piece of the puzzle: experimentation.

Experimenting your way into agile ways of working

It’s inevitable, in your shift to agile you are going to try some things that don’t work. But as long as you are trying things – and stopping to reflect on their impact – that’s not a problem.
That’s why I always recommend that teams trialling agile try retros, whatever other practices they are adopting.

Retros, or regular shared reflections on how you are working together, are valuable for all sorts of reasons. But if you are changing how you work together they are even more important, because they give you a natural point to pause and think about how it’s going.

Often you’ll realise things like you’ve scheduled something badly, or you’re not prioritising frequently enough, or you’re not distributing work evenly between the team. That’s all good learnings! A retro provides a safe space to recognise these things and decide how you’re going to respond. It means you are set up well to improve how you work over time.

How did you get started with agile? Or if it’s something you are considering, how will you involve the whole team in choosing and experimenting over what you try?

Agile doesn’t work for everyone. Often when I mention agile to others, they groan, because they’ve seen it done badly. I’ve seen two key failures that cause this: imposing processes on a team and not really trying agile at all.

Failure 1: agile imposed on a team

This is the failure I most often hear about in tech circles. A new leader comes in with the bright idea of adopting agile – maybe they’ve had good experience at a previous organisation – and they make the team work in this way by giving them a mandatory set of processes to follow.

This is head-to-desk-thumpingly stupid. It’s not what agile is about!

Agile is about mindsets – individuals and interactions over processes and tools as the Agile Manifesto puts it. It’s about how you think about things: being outcomes focused, having an experimental mindset, distributing power rather than making all your decisions top down… The tools are only useful to the extent that they support those ways of thinking.

Imposing the tools on a team overrides the context, needs and interests of the people in the team. It’s doing the exact opposite of what you’re supposed to do in agile, which is giving the team the power to choose how they work. So it becomes an annoying new bunch of admin and further evidence that leaders aren’t really listening to their teams. The Manifesto for Half-Arsed Software Development captures this well – doing it this way is doomed to failure.

Embarrassingly, I’ve been involved in this in the charity sector too. I was excited to be bought in by some senior leaders to support a team who were struggling to prioritise a strategic piece of work. But it turned out the team had no opportunity for input.

They were given a list of tasks without any say in the details, and unsurprisingly, the details were wrong. It was all well intentioned, but the people setting direction weren’t close enough to know what was realistic or likely to succeed. And the team knew it. Having this list imposed on them was frustrating and disempowering, and naturally they didn’t care all that much about the outcomes. All the processes in the world for better prioritisation can’t help when what you are prioritising is just misguided. It doesn’t work unless you give the team more say.

Failure 2: Not really trying agile at all

I’ve seen an astonishing number of things labelled as agile. Working faster. Changing your mind a lot. Hot desking (really!). Often it’s an excuse to give a team more work without extra resource.

Yes, agile can help you do things more efficiently. In theory you can do more work, or at least, more impactful work, because you’ve stopped doing things that aren’t as good a use of your time. But again, this only works if teams adopt the mindsets of agile, if they are empowered to ruthlessly prioritise, if they spend time experimenting and learning so they can improve. And this doesn’t happen if it’s just some buzzwords rather than a shift in thinking.

The most insidious version of this is subtle. A team might have bought into trying agile themselves, using a lot of the language and regularly holding agile ceremonies. But you dig into it and it’s tokenistic. They hold what they call stand-ups – once a fortnight and it takes an hour. They’ve added this on top of other meetings. It’s all a bit frustrating and sad. Again, they are focusing on processes and tools over ways of thinking.

What’s needed to make the shift to agile successfully?

As we’ve seen, tools are not enough to successfully shift to agile ways of working. You need engagement from the whole team. More than that, you need to give power to the whole team. Leaders can set vision and direction, but they need to trust that their team are best placed to work out the details. They need to be given the space to work out how they’ll get to the vision, and that includes deciding how (or if!) they will adopt agile.

There also needs to be an openness to experimentation. You won’t get agile perfect to start with – in fact, there is no such thing as perfect ways of working. But you will learn a lot over your first few months, and you have to be willing to try things and adapt as you go. More on this in my next blog.

I want to emphasise that agile is worth it! I’d argue that what I’ve described here isn’t really agile, even if that’s what people are calling it. Done properly, agile reduces risk and uses the wisdom of the whole team, in a way that enables you to be much more effective. Done poorly… well, it’s just a bit frustrating.

Have you seen agile fail? What’s you reaction when you hear it mentioned?

Part 2: Using the wisdom of the whole team

We’ve talked about how agile helps you reduce risk by working in shorter cycles, allowing you to learn as you go. But there’s another big reason agile works. It allows you to use the wisdom of the entire team.

Your team are smarter than you think they are

When you work in an agile way, the whole team gets equal say in choosing what to work on and how you’ll do it. This is another idea that lots of managers understandably resist. We’re taught that these types of decisions should come top-down – after all, that’s why we pay managers more! Managers should be more experienced, have more context about what’s going on in the organisation and so be best placed to make the decisions.

But is this really true?

All of us have biases and blind spots, and that’s no less true for managers. And all of us only see part of the full picture. The manager may well know more about the organisational context. But they’ll probably know less about the practical details of the work.

How long will something will take, what happened when we tried this last time, who needs to be involved from other teams, what’s their capacity is likely going to be… All of these are probably areas where the rest of the team knows more than the manager. And all of them are things that should be taken into account in your decision making.

Make better decisions, together

We default to one person making the decisions because it’s simpler. But agile has lots of tools to help you to decide collaboratively. In fact, I’ve got a whole guide on how to make better decisions with agile, with five different easy-to-follow processes you can use to do this. But the important thing is to decide together.

Each member of your team has different experiences, relationships and knowledge you can draw on. And the whole is greater than the sum of its parts. Why wouldn’t you want to involve them in the choices governing your day-to-day work?

How deciding collaboratively benefits each team member

Involving your team in choosing has other surprising benefits. It’s well established that psychological safety is one of the most important drivers of team performance. Teams that feel comfortable speaking up, taking risks and giving feedback perform better. And giving team members equal share of voice in the decisions that affects their work helps build that psychological safety. They know they will be listened to, that their expertise is appreciated. And they know that they don’t have to get it all right. Part of the value of deciding collaboratively is that if one of you is way off track, others will counterbalance that.

Involving everyone in deciding also gives them greater buy-in to the choices you make. They will know exactly why it’s important, and give them real ownership of the decision. It makes it easier for them to connect individual tasks to the bigger picture. Because they were involved in the decisions, they have a real understanding of them and can think more about how that should emerge in different settings.

Finally, it’s good for their development. Prioritising is a skill like any other, as are broader forms of decision making. Getting to practice prioritisation on a regular basis makes you better at it. Not only does the specific skill transfer to other settings, but the process also gives you the opportunity to consider why you make specific choices. It’s a natural way to hone your strategic thinking over time.

I want to emphasise again that this is practical and easy to do. There are simple, well established ways of deciding collectively described in my how-to guide. It may be simple, but it’s also powerful. This is a major reason agile works.

How do you approach decision making in your team?

Part 1: a different approach to planning and risk

I’ve already talked about how agile enables good prioritisation. This means you are doing the right things, and more importantly, you are doing fewer things at once. You can achieve so much more if you are focused on a few high impact pieces of work instead of trying to do a million things at once.

When this month (or this week, or this day), is all about getting this one very important piece of work done, you make a lot more progress. This doesn’t mean you can’t do those other priorities later, but limiting what you do at any one time stops you wasting time flitting back and forth between competing priorities.

So, the emphasis on agile in prioritising a few things – maximising the work you’re not doing at any one time – is really helpful. But there’s more to it than that. I’m going to explore one of the most important today, and then I’ll touch on others in future blogs.

Agile reduces risk

We don’t often think about it this way because it sounds very boring, but agile reduces the risk involved in your work. Agile emphasises working on a shorter timescale, not planning too far ahead and not going too long before you have an opportunity to stop and reflect. Very often, we plan in annual cycles, often developing our plans months and months before we actually implement then. But then things change – people leave, there’s a new opportunity or a competing product or a trend in the market. Planning well in advance means you can’t respond to those things.

Even if you could account for inevitable change, long-term plans would still turn out to be a bit rubbish. Our work is complex and we are notoriously bad at predicting how long things will take, what others will need or what barriers might crop up along the way. I’ve written embarrassingly many project plans that have turned out to be nonsense, and I’m sure you have too. I can probably map out the big milestones for a project, but for anything more granular than that, I am just guessing, and guessing badly.

Agile reduces the risks inherent in planning because it stops you from going into detail too far in advance. Since your plan is going to be nonsense, you might as well not waste time in developing it. Instead, think in shorter cycles. What do you want to achieve over the next fortnight, or the next month? You can make a much better plan for a short time-frame like that than a longer one. So plan for your short cycle, enact your plans and then stop and reflect on how it went.

The stopping and reflecting element is vital! This is how you course correct as you go along.

If you pause to think, you’ll realise you’re learning about your work and about how you are doing it all the time – and indeed you should be deliberately structuring your work to do this. Done well, agile turns some of your work into a series of experiments that help you learn more about your audience, the external market and what you’re trying to achieve. This allows you to iterate your way forward, avoiding the pitfalls you would otherwise have fallen into. It’s much less risky than the alternative, because you won’t go very far before validating your learnings.

This works for everyone

You may be reading this thinking this is all very well, but in no way applies to your work. Perhaps you have to work in an annual planning cycle because that’s how everyone else in your organisation does it. Perhaps you’re focused on a project that inherently involves longer cycles, like an event you deliver every six months. Perhaps the idea of not planning out your work in detail seems laughable.

I get it! I would have said the same for my work too a few years ago. Most of my career has involved delivering annual fundraising appeals. Each of these has a long list of deadlines spread out over many months. I need to be confident that we’ll hit those otherwise it will go disastrously wrong. Thinking on an annual cycle seems like the obvious and sensible thing to do.

Except that, as we’ve said, plans are rubbish. It turns out that you can take an agile approach to annual projects like mine too. I’ve already described how my team uses backlog refinement to prioritise. This is a big part of how we plan! We spend time at the start of the project thinking big picture about the outcomes we want to achieve, and what activities will be needed to support those. But we don’t map out those activities in detail until we come to them.

This doesn’t mean we miss those deadlines. We have a rough idea of when things need to happen at a high level, and we work around those. Each time we prioritise we naturally think about time-sensitive work and we plan for the short term accordingly. But we also think about the more important tasks that aren’t time sensitive. And we incorporate everything we’re learning so far, including a lot of up-to-date knowledge about interdependencies.

Instead of spending several weeks planning at the beginning of a project, we do a light touch plan and then invest an hour or so each month in planning for the upcoming month. This saves us time overall and leads to much better, more informed results.

I’d love to hear from you – what’s your planning process like and do you experience some of these pitfalls?

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?