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).
|
|
700 hours of career coaching in 17 minutes
Folks working in nonprofits are often great at doing multiple jobs in an organisation (so many hats!) but haunted by a permanent sense of never quite progressing.
After 700 hours of coaching people like that, Iâve learned what actually helps, and it's not the advice usually given in career chats.
So, I distilled what I know into a short YouTube video with the coaching advice I give most often, and still need to hear myself.
The Weekly Filet (one of my essential weekly newsletters) described it as "career ASMR" and I'm here for it.
|
|
đ 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.
|
|
Pssst. Missed a newsletter from this season? I've got you.
|
|
|