Hello friends,

Welcome back to Theory of Change. Through till November, I’m exploring frameworks and ideologies imported from the marketing and tech world that don’t always survive contact with mission-driven work.

This week: Agile, the product development cult (easy, Adam...) that promised to save us from bureaucracy, and somehow left us with more meetings. It’s one of the more misunderstood and misapplied frameworks, especially in the nonprofit and social change world.

But, fear not! I was sent here to tell you that it’s not inherently bad. You’re probably just doing it wrong.

(New here? Subscribe!)

WHAT IT'S SUPPOSED TO BE

The origin story of Agile (with a capital A, please) begins in 2001, when seventeen software developers meet in Utah to fix a simple problem: projects were too slow, and by the time products shipped, the world had already moved on. They write a short, now-famous document - the Agile Manifesto! - built around four simple principles:

• people over processes

• working software over comprehensive documentation

• collaboration over contract negotiation

• responding to change over following a plan

A decade later, I found myself running five Agile teams as Storyful’s Chief Product Officer, building tools used by thousands of journalists and clients. It worked: we won awards for our approach to product development, stayed close to users, learned fast, and adapted when the market shifted.

But when I later tried bringing that same mindset into a thirty-year-old nonprofit, it didn’t translate.

I hate inefficiency. I hate meetings that meander, programmes that exist because they’re fundable, and products built on hunches. I love things made to meet real needs. Agile supports that.

But Agile isn’t a plug-in fix-all; it’s an ecosystem that runs on time, clarity, and psychological safety: three things most mission-driven organisations don’t have enough of.

WHERE IT FALLS APART

Agile made its way into nonprofits the same way most tech frameworks do - through innovation labs, civic-tech experiments, and funders hungry for (brace yourself) “startup energy.”

By the 2010s, groups like Code for America, UNICEF's Innovation Unit, Omidyar Network, Mozilla Foundation and Nesta were championing sprints and stand-ups as the cure for drift in the face of evolving technologies. Everyone from voter-tech pilots to food relief to newsroom incubators were borrowing its language: sprints, backlogs, MVPs. It offered relief from over-planning and a way to sound modern to donors. But in most mission-driven teams, the method outpaced the means.

Agile looks light on paper but in practice, it’s heavy. It needs time for planning, retrospectives, backlog grooming, and regular reflection. Most frameworks that help teams apply Agile (XP, Scrum, etc.) need distinct roles: a product owner who can decide, a facilitator who can protect process, leaders who can handle uncertainty, and so on.

That’s a luxury many nonprofits don’t have. When everyone’s doing two jobs and the funding cycle renews every winter, the structure collapses. The rituals survive - sticky notes, stand-ups, Trello boards - but the clarity and cadence melt away with the December snow. When we pretend we can "do" Agile part-time, it drains the energy we were trying to save.

The consequences? Churn (everyone’s busy, nothing finishes), role confusion (sorry, who’s in charge?) and cynicism towards new processes.

A BETTER WAY TO THINK ABOUT IT

For most mission-driven teams, Agile doesn’t need reinventing, it just needs rethinking.

To do that, you need to apply it in the right way and - imho - true product ownership is at the centre of that. Most teams stumble because everyone’s sort of in charge. Applying Agile principles mandates that you decide exactly who owns what and make it visible (see Theory of Change #003 RACSI for help on how). It’s essential to have one clear decider, rather than ten people collaborating in circles that go nowhere. And you, dear leader, need to be comfortable delegating. Properly delegating.

Then make space for honest retrospectives. Skip the buzzwords and focus on two questions: what worked, and what drained us? This will only arise if the organisation has a good foundation of psychological safety. If you don’t have that, work out how to build it (easier said than done, I know - see below for more on this).

Agile was born in tight-knit software teams, not in the hybrid, multi-timezone, remote team reality many nonprofits work in. So don’t copy their rituals blindly. If you can’t get into one room IRL, you’ll need to overindex on communication.

Finally, if you’re dealing with funders who expect fixed plans, don’t call it Agile at all. Call it evidence-led adaptation or progress reviews. Funders like learning! But they’re not massive fans of fuzziness.

TRY IT THIS WEEK

For teams already doing some version of Agile, and who are experiencing issues or friction, stop sprinting for a minute. Gather whoever’s involved and ask honest questions. Most Agile “failures” in nonprofits aren’t about skill - they’re about structure, funding, and psychological safety. Be honest: if the system won’t support real iteration, don’t pretend it will. Design something simpler that fits your reality.

For teams thinking about trying Agile, consider testing the principles first, not the whole Scrum playbook. Run an experiment with one or two lightweight practices e.g.

• A 10-minute daily stand-up. Gather the team, ask: What did I do yesterday? What’s next? What’s blocking me? Review how this feels after two weeks.

• Put in place short retrospectives at the end of a project. Ask what worked and what didn’t. Look at how the team responds. Are they being honest, or performative?

If the experiments spark clarity and momentum, great. If they amplify tension or confusion, that’s useful data too.

(In that case you might want to revisit Theory of Change #006 - The Five Dysfunctions of Teams. The real blockers of agility usually live there, not in your Miro board).

🌊 WAVE GOODBYE 🌊

Somewhere along the way, efficiency became our proof of professional competence. We optimise, streamline, and automate in the hope of feeling in control. In reality, that chase often hides something harder: our discomfort with sitting inside complexity.

Under pressure to deliver certainty (to funders, to boards, to ourselves!) we reach for frameworks that promise clarity. They make messy problems feel manageable. But the real work of change - listening, waiting, adapting - doesn’t fit neatly into a sprint plan. Not everything that matters can be written as “As a user I need X so that I can Y.”

But Agile was never meant to be a synonym for efficiency. At its best, I always understood it as a commitment to attention, noticing when something truly needs to change, and when it doesn’t.

And for most purpose-driven teams, the challenge isn’t speed; it’s protecting time to think. The best ones I've worked with treat slowness as a skill: they build in pauses, question urgency, and make space to interpret what’s really happening before they act.

So rather than “doing” Agile, maybe we need to practice a form of temporal resistance, to move at a human pace, even when the system (or the funders) demand more speed, more scale, more everything. Because the most radical thing we can do, sometimes, is not to accelerate, but to pay attention.

*

Thanks for being here, as ever.

I’m gathering ideas and thoughts ahead of the next season. Do you have a framework, mental model, or nonprofit ideology you’d like me to critically unpack? Hit reply and let me know and I’ll do my best to feature it in an upcoming edition.

Take care,

Adam

p.s. If a kind soul forwarded you this and you like what you see, you can subscribe to receive Theory of Change on the regular.