There is no getting around the hype surrounding Agile, the organisational concept originally codified by software developers in 2001. Powered by the demands of a fast-changing consumer landscape in recent years, Agile’s reach has stretched beyond software development and now extends to customer relations as well as product and service development.
The Agile school of thought holds that reorganising business activities around cross-functional, self-managed teams, each with a clear purpose and focused on specific customer needs, leads to improved performance outcomes and customer-centric innovation.
Most of what’s been written about Agile assumes that the methodology can be adapted to any organisation. But our analysis found that some companies are better suited to Agile than others. Those who aren’t a good fit and yet shoehorn themselves into the model risk burning money as well as upending organisational culture with little to show for their effort. GE can tell you that. The company’s years-long, unsuccessful attempt to implement Agile under then-CEO Jeff Immelt ended in 2017, when 30 percent of its market capitalisation had evaporated. Agile is a tool that should never become an end in itself.
Our research, described in a recent working paper, outlines characteristics of organisations and tasks best suited to Agile. It also highlights some often overlooked factors that should be considered before your organisation commits itself to Agile. Here are a few fundamental questions to ponder.
Can you make your business processes modular?
Agile works best in companies whose output results from modular, sequential tasks, or whose products are made up of parts that lend themselves to bottom-up innovations built on practical experience with customers.
Take Dutch homecare organisation Buurtzorg. Teams of 10 to 12 nurses with few interdependencies are each assigned to a specific neighbourhood (“Buurtzorg” literally means “neighbourhood care”). Each patient is cared for by one or two nurses at most, and team members decide how best to do the work, determine schedules, assign roles and optimise team outcomes in the area they are responsible for.
The model is costlier per hour than the traditional one (where nurses are dispatched to execute specialised tasks at lower cost per hour but spend less time with the patient), but Buurtzorg patients require only half as much care. It also rates highly on quality and user satisfaction. The model has been widely held up as the way forward for homecare everywhere.
What about more complex environments? For example, can a bank’s output be broken down into small independent modules given the regulations, interdependencies and legal risks involved? In 2015, faced with constantly changing consumer behaviour and growing demand for online digital services, Dutch banking group ING turned to Agile with the aim of developing multichannel services quickly. It replaced the hierarchical structure of its headquarters with 350 squads of 8-10 people grouped in 13 so-called tribes. Each tribe has a clear purpose or project, like payment systems, and end-to-end responsibility. The transformation enabled ING to rapidly upgrade services or introduce new ones like credit cards with features aimed at specific customer groups. Headquarters had become a software development hub.
What kind of innovation are you looking for?
Developmental initiatives that tap multiple functional departments to better serve customers, rather than routine day-to-day operations, are the kinds of challenge Agile was originally meant to facilitate. If you overhaul your products or services once every five years, Agile processes may not help.
Saab Aeronautics developed its Gripen E fighter jet by implementing these practices at every level and in every discipline from software and hardware to fuselage design. More than 1,000 engineers were grouped in 100 teams, each of which was given the autonomy to develop the best implementation for its particular contribution. Teams were self-organised and had technical ownership. Gripen E is now touted as being good enough to beat Russia’s Sukhoi jets without the very expensive stealth technology competitors like the United States rely on.
In comparison, when the product is not as easily adapted as online services and less amenable to improvements the Agile approach may be counterproductive. Take Tesla for example. Tesla has tried to reinvent the way cars are produced and maintained by reconceptualising the role of software for cars using Agile methods, as well as adopting a highly automated manufacturing process in which each subsystem is handled separately. The company started to produce its Tesla 3 model before it was fully developed, and this resulted in delays in production, confusion and higher costs as the interfaces between subsystems kept changing.
The reality is that the hardware in a car is increasingly integrated and will become even more so as new design and engineering demands emerge. For example, engine cooling is no longer a separate subsystem from headlights; cooling airflow is routed through headlights to allow for brighter, smaller and more aerodynamic light sources. In such a world, Agile teams would struggle to continue to add value as coordination needs explode – unless firms can re-modularise production.
Any decision about going Agile should be based on an assessment of your organisation’s innovation goals and the nature of your business activities. An interesting case study of Agile adoption outside tech-related activities comes from OCP, the Moroccan phosphate mining and fertiliser manufacturing giant. In 2016, the 100-year-old company introduced an Agile approach called the “Movement”. It succeeded in spawning new entrepreneurial ventures and achieving breakthrough process improvements in specific operations in mining and fertiliser production, whereas initiatives that were too broad, such as an effort to rejig HR, failed to take off.
Can you outsource agility?
Organisations unsuited for Agile, take heart: You can still reap some of the method’s benefits by proxy. Your company’s core technologies and application development skills can get a renewed lease of life via your Agile partner’s new markets, access or manufacturing capacity. Alternatively, technology alliances and targeted acquisitions can feed your innovation pipeline.
Semiconductor device manufacturer STMicroelectronics, for instance, developed a core competence in mixed-signal (digital and analogue) processing chips that it applied in quick succession to many fields by partnering with other firms. With Hewlett Packard, it was able to develop a solution for printer cartridges; with Seagate, miniature disk drives; with Nokia, mobile phones; and with Bosch, fuel injection systems, among many other applications.
Similarly, Corning lent its core speciality of glass competence to a range of applications, from Pyrex tableware and ovenware glass with Vitro to “Gorilla” glass for mobile phones with Apple and Samsung. In all application areas Corning entered quickly and early with partners, and then disengaged when the business matured, and its technology became less distinctive.
Can you balance opportunities and talent?
Beyond the initial question of “how well does Agile fit with what we do?”, a forward-looking CEO will also consider the longer-term requirements of an Agile organisation. To be effective, the new organisation will need to balance the range and flow of new opportunities with the availability of competent people and teams over time. Ideally, in the spirit of lean innovation, resources ought to be fully utilised but not spread too thin.
Nokia offers a cautionary tale. The once-dominant mobile phone company launched an innovation drive in the mid-2000s to develop a litany of products and bring them to market quickly, but it simply did not have, nor recruit, enough software engineers. The inevitable result was poorer product quality and delayed launches which destroyed customer loyalty and severely damaged the brand.
Conversely, if there are too many talented Agile teams chasing few real opportunities, one ends up with a case of “spinning your wheels” – a lot of effort with no real result. To avoid such a scenario, W.L. Gore re-established a corporate strategy group in 2015 and recentralised strategy development as the markets for its membranes matured and new opportunities became increasingly scarce. It had become more important for the company to strengthen strategy-making in its existing businesses and applications and develop a more integrated corporate approach to strategy rather than innovate.
It bears repeating that Agile is a means to an end, not an end in itself. It’s a natural fit for traditionally customer-facing domains that would benefit from incremental innovations, such as healthcare and financial services. But it is also making headway in industries that are more engineering centred, including cars, airplanes and mining. Whichever industry you are in, rushing headlong into Agile without due consideration could hobble rather than improve your business.
Edited by:Lee Seok Hwai
About the research
Research by Dr. Myles Sweeney led to Dynamic Systems Maturity Theory (DSMT)which is a scientific means for understanding and improving Organisation Systems. How they function? Why they perform at a specific level? The Nature of their Culture, Agility and the Learning & Development Process. It is operationalized in the Organisation Capability Maturity Framework and its three Reference Models (Organisation, Team & Digital Maturity Indices). It explains an Organisations Agility and the Maturity Assessments identify constraints to Agility and provide guidance and roadmaps for improving Agility.
Leave a Comment
20/02/2021, 07.26 am
It seems to me the authors have an incorrect understanding of what "Agile" is:
- "organisational concept originally codified"
- "the methodology"
Can something be both a concept and a methodology? When looking at the dictionary I would say it is very unlikely. And here lies the original flaw of this, and other like this, article.
First, there is no such thing as "the Agile methodology". If you think there is, please share it with me I am very willing to read it. The manifesto full title is "manifesto for agile software development" where agile (small a) is an adjective. Because it is hosted on the domain agilemanifesto.org and is shorter and easier to say and memorize, it has led to people calling it the "Agile manifesto", where the adjective becomes a proper noun, with a big A to differentiate it from the adjective. As Dave Thomas described some years ago, this is the root of the dangerous and wrong, and often not really agile, misunderstanding that Agile is a thing in itself, "codified" as written here, something created with the intention of establishing it as a methodology to be blindly applied, implemented. Hence the number of failures or half-successes of those so-called "Agile transformations". And the number of papers using those to explain "Agile" does not work everywhere. Sadly the only thing not working is people understanding.
The reality is that there is no such thing as "the Agile methodology", there is no methodology named "Agile", the manifesto is not a methodology, it is not codified, and it was not written with the intention or even assumption that people would use it in this way. In fact, those people whose gathering led to the writing of the manifesto did not even intend to write it before they met. Their purpose was to discuss and exchange about their different approaches and what was then called "light methods". They were there to discuss how they, each in their own place and context, were trying to improve how they worked. Their discussions quickly shown that there were indeed commonalities between their distinct approaches. The four so-called values of the manifesto were defined in the first hours. Those values are, at least for those of the signatories I talked to, the most critical elements. Jeff Sutherland, co-creator of Scrum and one of the signatories, told me that for him, if he had to write a definition of "Agile", he would simply write the four values. The principles (please note they did not call them laws, or rules) were agreed later on. Once again, there are no rules, no methodology, even no method listed in the manifesto, only shared aspects that participants thought were critical to explain how their different approaches all enabled higher agility of/in their work.
As a result, there is no rule and no code, only things that made sense for them at that time, linked to software development. Now, this is all about thinking about how we can improve how we work. Arie Van Bennekum, another signatory, when I asked him what would be his definition of this "Agile" thing, told me he would only write two words: interaction and collaboration. If you know why and how the manifesto came to be, and you understand the shared mindset of those people who wrote it, then you understand this mindset can be applied to absolutely everything, from school to restaurants, from building fighter jets to art work. What won't work however, is to blindly apply "Agile" as a methodology, applying without thinking what has worked in software. This is the situation described in this article, but this "Agile" discussed here is not the "agile/agility" of the authors of the manifesto.