One of the challenges of agile is the word ‘agile’. Even now, the word puts some people off. They get, understandably, sceptical about the jargon, dismissing otherwise helpful insights as yet another digital fad.
Meanwhile, other people end up embracing nothing but the jargon, without the substance underneath. They start standing up for their meetings and think this will deliver better outcomes for their customers or users.
This is an important issue for digital transformation which, after all, is much more about transformation than it is about digital. i.e. good digital transformation is all about culture, and that means it relies on engaging people, communicating clearly on issues of substance, and persuading.
A. Boil it down to basic principles
So how do you do agile without the distraction of ‘agile’?
One approach that can be helpful is to focus less on the word itself and more on two irreducible principles for how good products/services are designed.
- You should always build solutions quickly and simply at first — just get something workable finished. Then, show it to your customers/users to see what they think, and change it enthusiastically in response.
These rules capture many of the upsides of agile without the jargon.
They also have the nice property of being both right and revolutionary. They’re right in that, when you apply them well, they lead to better products and services. But they’re also revolutionary, in that they’re the opposite of how most traditional organisations function, so although they sound simple, applying them well is really, really hard.
B. History also helps
The second approach I find useful, as a way of avoiding an unproductive debate about agile terminology, is to bring in some of the history.
If you can give a good account of why agile makes sense today, it helps you focus on the substance, and it also reassures people that the ideas aren’t a fad. To do this, you need to show that material things have changed in our economy and that these changes privilege more iterative/adaptable ways of working.
So what has changed in the world to make agile methods more effective?
My sense is that the answer to this question has two parts, both of which stem from technological changes that have taken place since c.1994.
First, the economics of service delivery have changed.
In the old, pre-digital world, organisations could typically reach thousands of people with one instance of their product or service, and updating these products or services was a costly and imprecise business.
To change a product or service was expensive, requiring retooling, repainting, or relaunching. It was also highly imprecise — even after you made changes, you couldn’t be all that sure they had been worthwhile.
In 2018, things are different. With digital technologies, even a small organisation can reach millions of people with a single instance of their product or service.
Meanwhile, revisions are cheap and, with good analytics, instantly informative. You can tweak a few lines of code and test the new version live (perhaps even alongside the old version). You can then learn, instantly and with statistical rigour, if your changes have worked. (And, if they don’t, you can even revert to the old one.)
This simple change in the economics of service delivery means that iterative methods, in which you build something quickly so that you can start changing it sooner, are much more economically attractive than they used to be.
Second, real-world testing now matters more than it used to.
We could leave it there. But I think it’s important not to overlook a second, subtler shift, which explains why real-world testing — and, therefore building a workable product/service as early as you can — now matters more than it used to.
At root, this comes down to two mega-trends in our economy: the shift from hardware to software and the shift from an economy based on manufacturing to one based on services.
If the archetypal outputs of the old economy were physical objects like cars, appliances, and clothing, the archetypal outputs of the new economy are digital services like search engines, social networks, and banking apps.
This changes what you need to know in order to create valuable things.
Let’s take the early days of industrialism as a starting point. It’s pretty clear that, right back at the start of the industrial age, knowledge of engineering was paramount over knowledge of user experience. Who cared if your loom/steam engine/high-speed steel was a pleasure to use? The value of innovation lay mainly in whether it worked.
Later, in the age of mass-production, the balance shifted. If you’re making a mass-market consumer product, of course it still has to work in an engineering sense — but it also has to be gracefully designed. That’s why the 20th century was captured by the idea of combining form and function. And it’s why the iconic products of this era, from the Coca-cola bottle to the iPhone, are lauded for being both well-engineered and beautiful. They’re a delight to use.
Today, the case for graceful, usable, beautifully-designed products/services — beyond those that are purely well-engineered — is surely more powerful than ever.
Of course, that is not to say that engineering matters any less. The goal of all good products/services is still that holy grail: a fusion of form and function.
But now, more than ever, you simply cannot get away with overlooking — even for a second — the design/user-testing side of things. The age in which you could occasionally get away with shoddy UX is dying, if it’s not dead already.
Why? Again, for a really simple reason: because badly-designed digital services are literally worthless. They have no value whatsoever, in a way that isn’t quite true for a badly designed hammer or washing machine.
In fact, badly designed digital services often actually destroy value. If you don’t believe me, just call O2’s voice-activated customer service line, as my partner did the other day. She phoned them with a query about her bill and, by the time she got through, she was so furious she cancelled her contract.
Agile without ‘agile’
To get the benefits of agile, then, it can be helpful to downplay the word in favour of underlying principles and reasoned arguments about why these methodologies and mindsets work.
Two trends explain the need for more iterative/adaptable methods in service design. One is a change in the economics of product/service design. The other is a subtler shift in the kind of knowledge you need to build valuable things.
Together, these trends explain why people who develop products/services today, whether in charities, government, or businesses, should focus more obsessively on user needs and should build workable stuff more quickly than they used to.
Agile is not, in other words, a fad. It’s a new way of organising people to do good work, reflecting real changes in the way our economy functions.