Slow agile
To design public services for the 21st century, we approach change through small-scale interventions, combining human-centred design with agile delivery. A trojan horse; to begin creating the conditions for impact at scale.
However small we start, you can almost guarantee one of our first challenges will be in how we fit agile ways of working into the cadence of a traditionally structured organisation.
What’s the problem with taking agile at face value?
Agile as a mindset, approach or methodology largely signals speed. The terminology would suggest this to anyone grappling with this new way of working. Sprints, velocity, delivery and even 'stand up' all come loaded with an implied sense of pace. Though if you look back at the origins of ‘agile’ in this context, and pull apart the manifesto, there isn’t one mention of speed at all.
Rethinking the definition
If being agile shouldn’t only be about speed, then what do we mean when we harp on about it? To complicate things for a start, there are two definitions when you look up agile. The first is where our practice gets rooted often: 'able to move quickly and easily’. The emphasis is on doing things at speed.
The second is a much more compelling definition for what we’re trying to do in our quest for change: 'able to think and understand quickly’. Thinking and understanding, before we move quickly. This is particularly important when we’re facing complicated challenges in meeting complex needs.
Teams within most traditional organisations decide quickly and implement slowly. So although these organisations appear to move slowly - they do so with a flurry of rapid decisions below the surface. A bit like the propellers beneath a cruise ship, frantically churning to shift the course of a huge vessel.
In contrast, I’m starting to believe 21st-century teams need to decide slowly and implement quickly (HT @Simon_30495 for the ah ha moment). Wes Dyer (engineer at Waymo) articulates this brilliantly when he says “make it correct, make it clear, make it concise, make it fast. In that order”.
Taking a more considered approach
So how can we make sure that our approach to agile encourages this? Moving away from a focus on speed and time-boxed activity for process sake, and instead encouraging teams to slow down the stuff decided beneath the surface? Here are a few areas that I've found might help:
- Ensure actions meet outcomes: to be more considered in our approach and reduce the rush to show progress by burning through a to-do list.
- Ensure leaders have a shared understanding (and know how to engage with the process): to afford the team(s) the space to operate across silos in new ways, rather than hold the expectation to see the same things delivered at a faster pace with half the team at half the cost.
- Make sure the cadence and cycles you implement are proportional to the aims, and are empathetic to the demands of the people you’re working with.
- Focus effort on adding value slowly in small steps: create more sustainable shifts as these compound over time. Start small, think big.
Let’s not forget that in trying to help an organisation change, we’re rewiring the connections to breakdown silos, and building networks to share and grow new capabilities. These things take time, and should be approached with empathy in a considered way.
An agile approach can help signal this change. It's a great forcing function when paired with user-centred design to create the conditions for sustainable change. Though sometimes we need to slow down before we speed up.
by KJ