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?