Why AGILE is not THE answer
A few weeks ago I wrote about how companies using Wardley Maps (well) for strategy, execution and organisational improvement often seem to be operating a decade or more ahead of others in the game. I discussed how the ‘Pioneer-Settler-Town Planner’ model in the Wardley Maps method (organising around different attitudes or cultures) had long contradicted Gartner’s “best practice” of having a ‘bi-modal’ approach to team structure and how Gartner had recently come round to also adopting a ‘tri-modal’ like ‘Pioneer-Settler-Town Planner’ approach itself (albeit more than a decade late).
This time I want to focus on another “best practice” that’s actually been holding many businesses back, but that anyone using Wardley Maps has known for a decade or more and that’s ‘Agile is NOT the answer to all your organisation’s problems’. Fortunately, the business community is slowly starting to catch onto this as well. As a recent article the Harvard Business Review magazine points out (“Agility Hacks” Nov-Dec 2021) describes it:
“In the past 20 years, the agile approach to improving products, services, and processes has swept the business world. It calls for organisations to adopt small, empowered, cross-functional teams, break initiatives or challenges into small modules, and develop solutions using rapid prototyping, tight customer-feedback loops, and quick adaptation. Rooted in software development, agile has spread to many other functions, and some companies have turned much of their organisation, including the C-suite, into agile teams”.
This is why most of the terms in this paragraph will be familiar to you, even if you’re not sure what some of these nice sounding terms (“small, empowered, cross-functional teams”, “break … challenges into small modules”, “rapid prototyping, tight customer-feedback loops, and quick adaptation”) mean in practice. But the HBR article continues:
“Although agile can benefit the parts of a business that must be nimble — those that manage shifting customer relationships, explore new markets, and develop new products quickly and responsively, for example — it is less effective for operations or functions that require consistency and efficiency rather than agility”.
In other words, Agile is NOT a silver bullet. It’s not the all-singing, all-dancing one-click solution to all your organisation’s ills and ailments that some management consultants sell it as being. And your business success will NOT be defined by the cost or scale of your ‘Agile transformation’ which some business leaders, especially those with the extra deep pockets needed to hire the “best” Agile gurus, hope for. (Reminder: the reason there are so many ‘gurus’ in the business word is too few people know how to spell ’charlatan’ — h/t R.Holdsworth).
Yet those who use Wardley Maps have known the fallacy of the ‘one-size-fits-all’ myth for a decade or more now and have been acting appropriately. Rather than do the increasingly expensive ‘Agile dance’ they’ve become adept at using multiple methods. So, let me show you with the aid of one map the myth (and danger) of thinking that business success comes from ‘going Agile’. (If you’re new to Wardley Maps then this short video ‘How to Read a Wardley Map’ will quickly bring you up to speed). On the map below we’ve super-imposed where common methods like Agile, Lean and Six Sigma are strong (and will work well) and where they’re weak (and where use of them can actually be damaging or even dangerous).
This map shows that Agile is actually a great method on the left hand side of the map in the ‘unchartered’ space where you may have a new ‘concept’ or the ‘genesis’ of a new product or service. That’s because here your ideas, or very-early-stage products, are going to go through a lot of change as you try to improve them and make them understandable or useable for others. But these changes cost time and money and you need to keep those costs of changes down, otherwise it will bankrupt your creation before it has had the chance to see the light of day. That’s why Agile focuses on “rapid prototyping, tight customer-feedback loops, and quick adaptation” — as you’re still learning what’s needed and how to do it, while spending too much time or money to do this (when you still don’t know if it’s going to be immediately shot down on first contact with a customer) is not a mistake many organisations can afford to keep making. This is the context where Agile works extremely well.
However, as you move to the right on the map, towards ever-increasing industrialisation — where there’s more certainty about what the ‘thing’ is, what it’s for and how to make or deliver it — the less your idea, product or service will change. What becomes more important here is incremental improvement through learning new things: how to satisfy more demand for it and how to produce it more effectively, with less waste, so it’s profitable (even in the face of more suppliers who are in competition with you). You may have bigger teams here working on slower release schedules, but focused more on getting it right first time (rather than the ‘moving fast and breaking things’ beloved of Agilistas) as you have established customers relying on your product to, for example, manage their banking online. These users won’t tolerate a failed update as easily as early adopters do for a new an exciting gaming app or program. Therefore, you need different approaches and Lean is more appropriate here than Agile as it’s more focused on learning and reducing waste.
But everything that doesn’t die continues to evolve and finally your idea, product or service, which was once a thing of wonder, becomes boring and industrialised — something widely understood and used in the marketplace — and the tolerance for it failing now is entirely unacceptable: think of nuclear power stations or transport infrastructure — how tolerant would we be if these components failed tomorrow? That’s because components on the right of the map (which, in the context of your organisation, may be payroll accounting or the wifi network for example) are meant to be stable, reliable components which the work you do is built on (i.e. people need to be paid and connected to do their jobs). Failure is not an option here, therefore you’re going to need to use methods like Six Sigma here to make sure your technology infrastructure doesn’t keep switching off, or outsource your accounting to specialists who have developed reliable systems and processes to make sure wages are paid on time and accurately.
Conversely, if you tried to impose Six Sigma methods on your innovation teams (on the left of the map in the uncharted space) the rigidity of its processes will likely kill your ideas before they hatch (which is why 3M abandoned it). But in the right context it works and the same goes for Lean and Agile too. The key therefore is to be able to see the context before you make decisions about which methods to adopt and for that you’re going to need a map. Maps will help you avoid the ‘tyranny of one’ — believing there’s one magic solution that will work everywhere: Just because Six Sigma reduced the cost of running an industrialised product doesn’t meant you should apply the same approach to new product development; and just because Agile methods worked great for developing a new app doesn’t mean you should “Go Agile!” everywhere in your organisation. You have to use methods that are appropriate for the context and, in any organisation of a reasonable size, that means using multiple methods at the same time.
So, it’s great that the HBR is talking about this now, but this is something those who use Wardley Maps have known about for over a decade. This principle (“Using Appropriate Methods”) is just one of 40 universal skills and habits in the Wardley Maps method that all organisations should be adopting if they want to operate smartly in the modern business world. Many of these principles are common sense (ex, ‘use a common language’ so people can ‘challenge assumptions’ and ‘learn about what’s being considered’ are the first three principles). Others only become common sense after you’ve learned them. Every organisation I’ve worked in or worked with would benefit from adopting, at least, the phase 1 principles (in the table below) and that’s something we can you do in just 20 hours, so get in touch if you’d like to learn more about that.
In conclusion, maybe it’s a case of ‘better late than never’ that the wider business community (led by whatever’s popular in the Harvard Business Review) is finally catching up and realising that Agile is not a silver bullet to all organisational problems. But consider all the time, money and efforts that have gone into ‘Agile Transformations’ at businesses around the world over the last decade or more. Consider all the good people and practices that were pushed out of organisations because they weren’t deemed ‘agile enough’ by the new gurus. Consider the opportunity costs involved in herding everyone, like cats, down a path most of them knew wasn’t THE ‘killer app’ they needed (but they lacked maps to explain why this doesn’t work in their context). So, isn’t it time it time you armed yourself with maps to prevent the waste of time, resources and energy of blindly following the next big thing (“coming soon!”) from the management consulting industry? If so visit us at powermaps.net and start learning how you too can start to get ahead of the curve rather than always playing catch up.
