This thing called agile might kill us all

My current gig is working for a big high street bank. The brief is to redesign the ‘end to end mortgage experience’. The timescale is to reach a business case, with a roadmap of delivery waves to achieve minimum viable product, within 6 weeks. There are so many aspect of this that are fascinating. It’s worth breaking them out.

What’s most interesting is that service design has moved on again. I though agile service design was leading edge. But agile transformation through service design is what we’re doing here. Let me try and define this.

Agile transformation through service design is the iterative investigation of the following set of assets.

Target Customer Experience (TCX) – the experience the organisation needs to provide that will encourage profitable behaviours from customers. They want loyalty and self-service so they can reduce head count costs and increase revenue – who doesn’t. This is the traditional environment where service design works. Service design orchestrates all the different types of design across all the different channel, to make it easy for customers to exhibit these behaviours- to self-serve and fall in love with the branded service. So we make it simple to apply for and manage a mortgage online. From a service design perspective this is on a spectrum of simple to relatively complex. You get your insight, you design your multichannel concepts, you test them. So far so good. But then we meet asset 2 in the agile transformation mix, which takes us into complex.

Target Operating Model (TOM) – the capabilities you need within the organisation to deliver the TCX. Now, TOMs have been a staple part of the transformation diet for many years, but in agile transformation they support a new purpose. In the olden days they were all about reducing the cost of supply – you shaved some cost of the call centre by putting it in India, you reduced Average Handling Time on each call, you shut down some branches etc. But the TCX is the new kid on the block and it dictates something different. It says – ‘these are the touchpoints we need, to get what we need from our customers and to keep them happy. What are you ops people going to do to realise them?’. It’s a big power shift. The designers are telling the business analysts what the requirements are, ideally based on empirical customer data (analytical or research based). This is not easy for many organisations to stomach, but once they do, I’d argue they are won over by it. Because it makes sense on a very basic human level. Problem is it makes no sense to an organisation based on silos of power – more on that later.

Okay – stay with me – agile transformation asset 3…

Roadmap – once you know what capabilities you need across people, process, IT and infrastructure, you then need to work out when you can get them. If you’re a service designer in an agile transformation environment, you will have likely given up at the TOM stage above, because that is tough enough. If you’ve made it this far, it’ll feel like the seventh circle of hell… This is the trade-off zone, and IMHO designers struggle here. Their vision being so obviously perfect (and it is!), that they find it hard to handle the operational change reality which is marked by one word – LEGACY. Legacy habits, systems, protocols, policies – you name it. This is where patience is a virtue. You get 20% of what you want in TOM 0.1, which gives you TCX 0.1 – this is your minimum viable product. This is what you gun for and go all out on. Done well, it gives you a backdraft to slide straight on to TCX 0.2 or… gasp, maybe even TCX 1.0. Hush, just maybe……

Okay – so you’ve survived it across Hades. The three headed dog is behind you. Now we hit agile transformation asset 4.

Business case – at the end of the day every part of your TCX is a change and therefore a cost to the business, which needs to stack up against a measurable benefit. This is service design’s weak link. Yes – we all get the visceral reality that customer-centred services are more profitable – but someone at some point will want to see the numbers, or they will ask you to leave the room. The interconnect of TCX > TOM > Roadmap is all in the purpose of achieving a business case, which allows you to spend money to GET YOUR IDEAS OFF THE WALL and into reality. In fact spin this all on its head. You need to put your business case as a hypothesis right at the start, before you even embark on your TCX. Agile transformation through service design is customer-centred, but it is above all else, business-focused.


I find myself in a quandry. I am intellectually stimulated by all these shifts. It is the right thing to be happening to service design and participating in its germination is very stimulating. But it is also very over stimulating in other ways, as it is breaking some big boundaries and shifting some consderable agendas. Both in my head, the heads of those around me, and the collective heads of the organisational cultures working on it. Like all things revolutionary it spills blood. It is equal parts edge-of-seat exhilarating and terrifying.

Three reflections on this feeling I’d like to share:

Designing in legacy – for those of you who have been kind enough to listen to me in the past, I’ve said before that designers can no longer get away with just setting a vision on the wall. They have to get actively involved with taking it off the wall. And that starts DURING THE DESIGN PROCESS. Service design needs to happen in collaboration with the people who run LEGACY. It doesn’t mean you have to let them drag you back (though inertia and atrophy will be rife),  what it does mean is that YOU have to take THEM with you. A good idea that works on legacy is 1,000% better than a perfect idea that doesn’t work on legacy. I am repeating myself, but it bears repeating.

Language – I felt compelled to introduce the TCX thing into common parlance (as common as I could get it) about a year ago because I wanted to align to the generations old term TOM. And also I wanted to abandon the many conflicting practices that contributed to it – systems thinking, service design, behavioural science, gamificaiton, experience design, UX, CX, simplification – you name it, your large scale service provider has it. And like any good set of religions they bicker over their differences, but fundamentally they share more than they differ. That’s what I use Target Customer Experience to describe – a set of practices that create the conditions for profitable customer behaviours. Under the bonnet we need to do lots of work to settle on language – personas, journeys, experience architectures, epics, waves etc etc the list grows each day. I used to bemoan going to the service design conferences as people always discussed language, but now I see they have a point. I am sat in rooms trying to do agile transformation and language is getting in the way at every turn.

Agile – it is a genuinely alarming way to work for many people. It requires people to put themselves in a very vulnerable working environment. To expose their thinking in a fast paced environment, where everything (including your precious ideas) are in prototype. You know how at school it was always about getting the right answer and in your career it was about delivering a polished result? Well here it’s about good enough. In many ways this is GREAT. Perfection is the enemy of good. BUT, it goes against culture and people can feel very exposed.

(Note: someone needs to write a Marxist evaluation of agile. Yes the outcome is better and it’s all very sexy and new and ‘oh so right’, but I suspect the cost on the worker is high as essentially it speeds production and works the asset of production (you and me) harder.)

Power – agile transformation through service design is inherently political and therefore a challenge to established power structures. One, service design cuts across organisational boundaries, because (as I’ve said in a previous post) that’s what customers do. They are ruthlessly horizontal in a way that vertically silo’d organisations really struggle with. Two, agile is ruthless in its slaying of sacred cows because it has to prioritise ruthlessly, based on the as-pure-as-you-can-get empirical customer and operational data. It doesn’t matter that you have served 20 years and risen to the highest point of hierarchy, your idea is measured on the same criteria as call-centre agent 1,746. I don’t yet have a third.

So service design is evolving beneath our feet. This is a good thing, but it comes at a price – for me, for you, for the organisations we work in. I think it’s worth it, but not every day. Some days I feel plain strung out. Some days I feel like agile has been sent to save us all. Some days I feel like agile is here to kill us all. Either way it is here.

3 thoughts on “This thing called agile might kill us all”

  1. Fascinating read. Thank you!

    I can’t help feeling though that if people are using “agile” to mean doing the same process only faster, even at the risk of burning out their people, then they’re Doing It Wrong.

    > Agile processes promote sustainable development.
    > The sponsors, developers, and users should be able
    > to maintain a constant pace indefinitely.

    This is the real challenge to peddlers of TOMs and the like: agile transformation isn’t a one-off thing that you do to get from A to B, it’s a continuous culture of iterative improvement.

    Agile organisations succeed through sensing, not planning. They are in touch with their _actual_ customer experience (not just some brand fantasy), they _truly_ understand their operating model (clue: it won’t look like a flow chart), and they have the capacity to make very frequent adaptations in response to customer needs.

    Get those things right and we wouldn’t need to do “change” programmes at all, which should come as a relief to all concerned.

    This is The Last Target Operating Model You’ll Ever Need™ 🙂


    1. Hi Matt. Long time no see. I agree with you entirely. I think my response is schizophrenic for this reason. Like any labour, there is some pain at the point of birth, but it’s short term and then you get a long term better thing. I think I’m reacting to the organisation giving birth to something very new, which is not straightforward. Though I completely see that it’s right. The challenge to any organisation is bridging the gap from non-agile to agile. Just take one of your examples: Moving from planning to sensing. This, in and of itself, is a massive change for a command and control organisation. Spinal injections may be required 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s