We hear the word ‘Agile’ used a lot within tech projects. But what does it actually mean?
Agile.
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.
Agile might not be what you think it is
Its not agile working, with hot desks, remote teams and data enabled laptops. That’s something else.
Nor is it a way of working without a plan or documentation (it actually has a very structured methodology).
And its definitely not about making it up as you go along (though it recognises that you can only learn what you need to build as you go along).
It’s a bit like…
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.
This ship metaphor is useful. But we also need a tech project definition.
A non-metaphorical definition
Last week I asked Dan Sutch of CAST how he’d describe Agile. He’s someone with a good bit of experience of helping charities and developers use Agile methods to build tech together. Here’s what he said:
“Agile working is a way of effectively managing risk and waste when developing a project. Working through cycles of identifying assumptions, testing them and then iterating an approach, it ensures the project is responsive to change and better suited to the environment in which it operates.”
Lets look at this definition more closely.
It’s a risky business
Building software is awfully risky. Almost as risky as going to sea in an untested boat.
There’s risk of building the wrong thing. Risk of building the right thing in the wrong way (and people not using it). Or 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, and the time wasted on building more than is needed, or building stuff that is less important than stuff that is. It does this by prioritising features and testing the assumptions behind them.
Agile tests assumptions
Every project begins with assumptions. About user behaviour, about what features are needed to solve a problem, or even about how a product might be made sustainable.
And every project stage brings new assumptions.
Assumptions are cool. It’s fine to have them. But Agile 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 or development.
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 (e.g. tweak the hull or build a mast next), 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 favoured features can be uncomfortable. But when done well it breaks a build process into discrete, manageable chunks of work linked to the most important user needs (or what’s needed to make the boat float). This makes building much easier, because…
Agile responds to change
Agile methods’ focus on assumptions, testing and validation means what we know about our users is always evolving.
Fortunately because Agile builds in small iterations it’s easy to change the product to reflect new knowledge. In this way it really kicks ass.
“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.”
Darth Agile
However, sometimes those user needs change because the user’s environment changes over time…
Agile helps products adapt to the environment
A good Tech for Good product is built to suit people’s behaviour, their social problems and their economic context (or that of their services). But people change, social problems change, and business drivers change. When this happens to a mature, or even early stage product, Agile makes it easier to identify and iterate the most important changes needed to meet the challenge (like making your raft adapt to the storm).
Does it mean what you thought it meant?
And just as importantly, do you agree? Please leave a comment below.
Or learn how to implement Agile project management into your organisation.
Leave a Reply