We aspire to eliminate jargon in our work. But you might still sometimes hear the word ‘Agile’ used enthusiastically. So, in the spirit of Princess Bride’s Inigo Montoya we try to explain what it actually means...
Sometimes it seems like the whole world’s gone agile.
Agile working. Agile development. Agile marketing. Agile, Agile, Agile ’til you’re sick of it.
As Inigo Montoya says in the Princess Bride, which some of us might argue is the greatest film of all time.
Agile might not be what you think it is
It’s not agile working, with hot desks, remote teams and data enabled laptops. That’s something else.
Nor is it a way of working without direction, plan or structure.
And it’s definitely not about nimbly hopping from from idea to idea and making it up as you go along.
Agile is methodical, structured and focused. And a little bit counter-intuitive at first…
It’s like finishing a ship while at sea. You first get the minimum you need to make it float: a hull and maybe a mast. Then, instead of finishing it before you launch, you go ahead and launch it and finish building it while it’s at sea. This way you have to focus on the most important things.
Allen Coin, Sideways Dictionary
This ship metaphor is useful, but also a little scary! Aren’t you more likely to sink?
Yeah, maybe. We need another definition, without the nice metaphor.
A charity digital definition
We asked Dan Sutch of CAST how he’d describe Agile. He’s someone with a good bit of experience helping charities use Agile methods. Here’s what he said:
“Agile working is a way of managing risk and waste when developing a charity digital project. It involves highly structured cycles of identifying assumptions, testing them and then iterating an approach. This ensures the project is responsive to learning and change, and better suited to the people it serves and the environment in which it operates.”
Let's look at this definition more closely.
It’s a risky business
Building digital services and software is risky. Almost as risky as going to sea in an untested boat.
There’s risk of designing the wrong thing. Risk of building the right thing in the wrong way (and people not using it). Or a risk of building the right thing in the right way, but then not being able to respond when it’s environment changes (e.g. building a raft that floats on calm seas but sinks in a storm).
Agile reduces this risk by forcing you to check what you’re doing. It makes you prioritise features and test the assumptions behind them. This reduces time spent building non-essential and less important features.
Agile tests assumptions
Every project begins with assumptions. About people’s behaviour and what will solve their problems. Even about how a service might be made sustainable.
And once you’ve begun, every project stage then brings new assumptions.
Assumptions are cool. It’s fine to have them. But Agile’s mantra insists that you turn each one into an hypothesis then validate it. In the simplest and smallest way possible.
Some assumptions can be validated through good user research, but the best validation measures are always test based, involving some kind of experiment.
This could be:
- Delivering a concierge service (delivered by people rather than tech) to test a concept’s viability
- Testing a paper prototype in front of potential users
- Usability testing a digital prototype
- Observing user behaviour through analytics – and using the data to validate a hypothesis
There’s loads of ways to test but Agile always values the smallest, simplest tests needed to get reliable insight into what to build next. This makes it easier to know what to build first (should it be hull or mast?) or iterate next (e.g. tweak the hull or build a mast), because…
Agile prioritises ruthlessly
Good Agile projects reduce waste through ruthless prioritisation. Team members learn how to challenge and remove those features that aren’t essential to solving the problem. They use user stories to do this.
Prioritising is difficult. Axing or delaying your favourite features can be uncomfortable. But prioritising breaks your design and build processes into discrete, manageable chunks of work focused on the most important user needs and features (i.e. what’s needed to make the boat float well). This makes building much easier, because…
Agile helps new projects respond to change
Because they focus on testing and validation, Agile methods constantly generate new insights into your users and their problems. Agile accommodates these changes by dictating that building should happen in small iterations. This is different to the old ‘waterfall’ way of building it all in one go.
“Imagine this, an approach that makes it easy to change what you’re building as you realise through experience what’s needed to make it even more awesome.”
However, sometimes those user needs change because the user’s environment changes over time…
Agile helps established services adapt to change
Good digital services are built to suit people’s behaviour and their daily challenges. But people change and their problems change. And business drivers change too. Even if your service is well established Agile makes it easier to identify and iterate it to meet the challenge (like adapting your raft to meet the storm).
Does Agile mean what you thought it meant?
And just as importantly, do you agree?
Or take a Design Hop and learn how to work Agile (though I promise you we never use the word once on the course!).