The problem with the service lifecycle

One of the things that GDS is most well known for is the coining of the Agile delivery phases.

Arrow going left like a timeline, with sections labelled Discovery, Alpha, Beta and Live

But this image of services coming out of nowhere is just not true to life. I’m not the first to notice this – Michael Brunton-Spall and Matt Edgar among others have some great thoughts on this. But here’s my take…

Government services are very rarely completely new. Most projects in government are improvements on services that have been Live services for years, sometimes even centuries.

It’s actually more like…

Arrow going round in a clockwise cycle, labelled Discovery, Alpha, Beta and Live

At some point, problems with a Live service get bad enough to trigger a new Discovery. A team is put in place to go and work out if the problem is real, understand the nuances of it, and then move into Alpha to test possible solutions. Eventually, a whole new ‘service’ goes Live, but really it’s just a new version of the service. It could use a new channel (like this new-fangled thing called the Internet) or it could just be designed to be easier to use or more efficient than the old version. We’ve saved money, but not radically transformed into something markedly better.

The fact that we see the cycle as a linear, flat arrow means that we get stuck in this loop of Live and death where the service is incrementally improved, but rarely radically reimagined.

The jumping off point

Same image as before, with another arrow coming out of the Live portion of the cycle

When a service is Live, just before we start a new Discovery, we have the opportunity ask big, fundamental questions. We need to ask both“What problem are we trying to solve?” and “Is it still the right problem?”

In Government, this means working with Policy professionals to really understand, and even challenge, the policy intent. It also means working with Operations to make sure we really understand the current situation and are trying to solve the right problem.

The cycle should be a spiral

A spiral with the Discovery, Alpha, Beta, Live labels as before

Imagine instead of a cycle, a progressive spiral, going outwards and upwards. The quality of the service improves as the scope of it expands. This happens all the time, and our processes are all designed around this progression being Business as Usual. We take into account what’s come before us, but we also challenge it.

A summary of the three images. Linear: Out of nowhere, new services are born. (Doesn’t actually happen, but we pretend it does.) Cyclic: New tech saves money, but no real improvement. (Shouldn’t happen but does, and we don’t acknowledge it.) Spiral: Radical improvement by challenging of scope. (This is what we facilitate when we do a good job.

Our job is to facilitate the progressive spiral

There’s a lot we can do to change our mindset to that of the progressive spiral. Not least of those is to change our processes, for example how we do Standards Assurance. That’s the bit of GDS that I currently work in, so I’ll be posting again soon about some ideas we’re going to test around this.

For now, I’d be really interested to see how this idea lands for people. I know it’s pretty heady and conceptual so might not be for everyone, but I’d love to hear it if it sparks anyone’s imagination.

p.s. The progressive spiral idea is quite heavily influenced by The Buddha’s teaching on conditionality, if you’re interested.