Why corporate Australia is rolling back its Agile at Scale transformation
Who could possibly argue with a management method that brings clearer accountabilities, faster decision making, improved innovation and faster speed to market? ‘Agile at Scale’ has purported to deliver just that – but practice shows that it doesn’t always deliver on its promise.
Over the past decade, CEOs across Australia have increasingly been embracing the idea that adopting Agile at Scale would enable their organization to achieve superior levels of performance. Agile at Scale however is a flawed idea that has been executed with a fervor bordering on religious to damaging effect. Now, corporate Australia is quietly rolling it back.
The Agile method was originally codified in the ‘Manifesto for Agile Software Development’ in 2001 by a team of 17 software engineers. The Agile Manifesto specifies: “Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan.”
Famously, in October 2012, Henrik Kniberg and Anders Ivarsson published ‘Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds’. This paper became a touchstone for the Agile movement. Over the last ten years, many of Australia’s leading institutions, from banks and telcos to retailers, have attempted to adopt these principles in their large-scale operating environments.
The concept of Agile is not new. Warren Bennis dubbed the term ‘Adhocracy’ in 1968 as an organisational form that lacks structure where multi-disciplinary teams self-organize to solve complex tasks.
The concept of Agile, by itself, is also not wrong. Organizations need flexible, empowered teams that can deliver rapid, iterative results, especially in areas such as IT application development, software development, new product development and general change programs.
Agile at Scale is flawed
But the concept of Agile at Scale, especially when applied across a large, legacy enterprise, is structurally flawed. First, most functions of most organisations in most sectors, are not amenable to working in an Agile environment. For example, an enterprise account leader, an accountant in the finance department, or a category lead in procurement, do not benefit from working in an Agile environment.
There is a job to do, a task to perform, which requires individual work effort, as part of a broader team or function. It doesn’t need scrum masters or product owners or daily stand-ups – these all just add overhead costs and organisational confusion.
Second, Agile methods work best in smaller operating environments, not sprawling organizations with thousands or tens of thousands of people. Spotify had a little over 300 people in three cities when it released its original paper. Today, it has almost 10,000 people and it no longer works in its original Agile at Scale model.
Third, Agile requires people to be comfortable working with a high degree of ambiguity, and despite what many workers may say, most prefer a high degree of structure.
But the biggest issue with Agile has been its heavy-handed roll-out. Many CEOs have launched top-down programs supported by HR and consultancies to dogmatically embrace a new language, relabelled roles, and new processes.
Many Agile at Scale programs focused too much on the method versus outcomes, and teams became almost religious about definitions and agile ceremonies. Oftentimes, teams got a license to move forward with half-baked ideas, and too many projects went nowhere. The idea of “fail fast,” sounds good, but once projects were up and running, many organizations kept funding bad projects.
And ironically, though Agile promotes flexibility, Agile structures became rigid, which is not surprising given these are very large organizations, some of them over 100 years old.
The effects
This unique combination of a flawed idea executed with a heavy-hand has resulted in many institutions who have been more harmed than helped by Agile at Scale, especially in three key aspects.
First, in an effort to empower teams and decentralize decision making, some large Agile programs have undermined leadership authority, especially CXO leadership. One business unit leader quipped, “I am measured more on whether I have adopted Agile ways of working than I am by the bottom-line performance of my business.”
Second, restructuring very large groups of people is always very difficult. However, restructuring into an entirely new organizational nomenclature, where the words sound like corporate jargon, and the definitions are fuzzy, is enormously confusing. That confusion can lead to disengagement and low morale.
Third, Agile practices require significant overhead, including new roles like scrum-masters and Agile coaches, frequent meetings and a shift in processes. This all adds layers of complexity and increased operating costs.
Transitioning to other ways of working
What are companies doing about it? The first step is to contain it. Agile is a good idea, inside certain areas. Namely IT, product development and change initiatives. Put Agile back in its box, and drop the Agile sanctimony.
Next, dismantle Agile from functions and areas that don’t need it, which is most of the organization. Organisational structure should follow strategy, not the other way around. Ensure clear organizational accountabilities are in place to deliver the corporate strategy.
Lastly, accept that large organizations are extremely complex, take longer than start-ups to do something new, and that there is ultimately no way to eliminate the need for functions or business units. Organizational elements must ultimately ladder up to the top, and leadership needs to be able control performance, especially in very large organizations.
About the author: Adam Dixon is the ANZ Managing Partner of global management consulting firm Kearney. He works with CEOs, leadership teams and boards on large scale transformations.
