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?

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?