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?

If you asked me a few years ago, I would have been really surprised to hear myself described as an expert in agile. But I spend most of my time using agile to deliver big projects, and teaching and supporting others to do the same. How did I get here, and what have I learnt along the way?

Combining innovation and project management

I’m a fundraiser who has spent the last 15 years working in some of the UK’s largest charities, focused on big project management and innovation. That’s my sweet spot – the mixture of managing complex, cross-organisational behemoths and nimble little experiments. I enjoy taking some of the common sense project management lessons into innovation and transferring the drive and processes necessary to stretch and improve into those big projects.

Just because it’s innovation doesn’t mean you don’t need to think about how you collaborate or manage risk or get people on board. In fact those are all more important when you are trying something different. And just because you’re working on a well-established project with layers of bureaucracy doesn’t mean you should keep doing things the way they’ve always been done.

Innovation and project management have a lot to offer each other.

Nothing has that clearer for me than using agile ways of working. Agile is a project management approach that originally came from software development. It’s all about breaking work down into small chunks, collaborating well and learning and adapting as you go. Many of the agile tools are frequently used in innovation, and with good reason. But it’s not until I started adopting the mindsets and techniques for bigger project management that I really understood its potential.

What agile means for me

I manage two teams. One is focused on project managing our major fundraising appeals, complex multi-million pound projects involving a whole range of stakeholders with wildly different needs and goals. The team is the engine room that keeps everyone else on track. And agile is what keeps them on track. It’s how they prioritise, coordinate and learn. It’s enabled them to absorb much more work than I thought would be possible, and it’s kept them focused on the important but not urgent big picture tasks that previously got squeezed out.

My other team supports all of our fundraising department with innovation. Agile is the foundation of what they do, from delivering new product development sprints to running quick experiments on existing products. We were doing all of this before we started describing any of it as agile. But once we adopted that framing – and more importantly, the mindsets and attitudes that go with it – we started seeing so much more success.

We started delivering work more quickly, focusing on the biggest impact pieces without getting bogged down in details. We used more wisdom from diverse perspectives. And we found more things to celebrate, both because we were doing more good work, and because we were actually stopping to reflect on it.

Where I started: using agile in a crisis

It’s a cliche now to say the pandemic changed how I worked, but the pandemic changed how I worked in dramatic ways!

I had used various agile tools here and there for many years, but it wasn’t until the crisis situation of that first lockdown that it went into hyperdrive. I was leading Christian Aid Week at the time, a fundraising appeal that raised a significant amount of my organisation’s income and almost entirely relied on face-to-face contact. All of that became impossible eight weeks before the appeal.

With just a few weeks notice, we rethought everything, introducing new fundraising products, pivoting others and reimagining everything from how supporters would raise the funds to how they would actually get the money to us. We raised £4m, nearly triple our target. It was only possible because of the way agile enabled us to focus on the most important things and to coordinate work in rapidly changing situations.

Where I am now: agile influencing all of my work

Since then, I keep accidentally finding that agile makes lots of different work better. That’s been true for everything from supporting individual projects to helping senior leaders develop and implement strategy. It’s now a major part of my work. I deliver training for a wide variety of teams to learn these practices and I give one-on-one support to enable them to get started. I’m even writing a book about agile (more on that later!).

Agile has helped me achieve much more than I ever thought was possible. But more than that, it’s helped me do it in ways that feel good. Agile mindsets have helped me get better at listening to all of my team, building on their wellbeing and development and making good decisions together. We’re more focused – we’re confident that we are doing the right things. We don’t need to do everything, but agile helps us prioritise the most meaningful and impactful work.

I’ve learnt a lot along the way! The more teams I introduce agile to, the more I see patterns in the questions and difficulties that emerge. I’ll use this blog to reflect on those (an important agile practice) and share some valuable tips that might help you on your journey too.

I’d love to hear from you. How did you first come across agile, and what does it mean to you now?