Agile-induced cognitive dissonance and the role of language pruning
“It’s time to move beyond a rigid hierarchy, siloed business units, crippling bureaucracy and an increasingly unwieldy matrix. Agile organizations combine the efficiencies of scale with the speed, flexibility and resilience to compete and win in today’s world.” — McKinsey & Company
“While being the product of a culture, a language is also a generator of culture. Hence, if the language is poor, the culture is poor.” — Manfred Max-Neef
The ‘Agile Enterprise’ is rapidly emerging as the dominant post-bureaucratic operating model. Every major management consultancy is promoting it and thousands of organisations have embarked on Agile transformations.
However, there can be considerable resistance. Agile methods often clash with executive’s ingrained beliefs. Consequently, they refute its benefits and exercise their political muscle to protect the status quo.
Change agents often attribute this resistance to the ‘wrong mindset’. The result: people with decades of expertise, but who ‘don’t fit’ the ‘Agile way of working’, become casualties.
But executive resistance is usually more to do with cognitive dissonance: the psychological discomfort felt when we try to process information that is inconsistent with our beliefs.
Let’s explore the roots of this dissonance, as well as an easy way to reduce it.
What Agile solves
Agile was created to solve a very specific problem (the clue is in its name).
The Manifesto for Agile Software Development was authored by 14 thought-leaders who assembled in 2001 to consolidate their thinking around lightweight development methods.
They were trying to solve what is commonly referred to as the Waterfall problem, articulately described by Dr. Winston W. Royce in 1970:
The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed … Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required … The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a l00-percent overrun in schedule and/or costs.
By the mid 1990’s, software development was in crisis. Software was beginning to ‘eat the world’. IT was evolving faster than a typical waterfall cycle could keep up with. Over 30% of projects were abandoned before completion, over 50% were riddled with cost blowouts and time overruns, and the opportunity costs were extreme. When solutions eventually did ship, they were often met with intense customer dissatisfaction.
The Agilists adeptly tackled the issue by crafting principles and practices that decomposed software projects into a series of iterative steps. They delivered value incrementally with intimate customer and stakeholder involvement throughout development.
Agile enabled a way of developing software that co-evolved with the user’s needs. It enabled solutions to ‘climb’ to product/market fitness peaks, even if the landscape was changing.
It was highly successful and delivered significantly better outcomes than waterfall. Agile methods then migrated to other functions such as general product development, marketing, and HR.
How Agile became an aspiration
In order to solve the waterfall problem, Agilists didn’t just change the process of software development, they changed the way people worked.
Compared with bureaucratic ways of working, Agile was a quantum leap. People worked in highly autonomous, non-hierarchal teams. They were fervently customer-centric. They communicated and collaborated brilliantly. They worked hard but sustainably. They were highly disciplined. They proactively engaged stakeholders. They had the energy of a start-up and wowed anyone who came in contact with them.
Naturally, business leaders were delighted with the outcomes. They wanted more ‘Agile energy’ throughout the enterprise and asked: how do we scale it?
Enter the era of “Agile Transformation” and “Agile-at-Scale”.
The problem with ‘scaling’ Agile
The manifesto was never designed to be an enterprise operating model. But there was a buzz and zeal about Agile and it was often hyped as some sort of golden hammer — a tool that could fix every operational problem.
However, Agile methods can’t do that. Far from it. Not all products can be incrementally delivered like software can, and not all business units need to act like start-ups. Guinness customers, for example, would be far from delighted if the brewers started ‘iterating’ the flavour of the much-loved 18th-century stout.
When executives are issued the dictum to ‘become more Agile’, their dissonance often has good cause. A recent review found no less than 79 challengescommonly faced when trying to scale Agile. These include: coordinating multiple teams that work on the same product, managing dependencies with other teams, dealing with the increasing workload of key stakeholders, establishing a common scope for different stakeholder groups, building the trust of stakeholders in Agile practices, and dealing with decreased predictability.
These are complex organisational challenges. They can not be solved by simply adopting an ‘Agile mindset’. They require knowledgeable and experienced executives to work on it. The type of executives often ousted during transformations.
What we have is a language problem. ‘Agile’ is too abstract, too loaded.
Chilean economist Manfred Max-Neef (who I once had the great pleasure of doing some work with) asserts, “what characterises a poor language is that it has too many words behind which—knowingly or unknowingly—we hide our ignorance”.
He advocates pruning key words in order to force us into higher degrees of clarity:
“The principle behind the act of pruning should be clear to anyone who has been interested in orchids. Through pruning we will achieve more and better from less. Fewer branches and leaves will allow more light to be absorbed and thus produce better fruits”
Try this experiment: prune the word ‘Agile’.
Eg., if trying to increase autonomy, talk about distributing decision rights; if trying to break down silos, talk about improving communication networks; if trying to improve culture, talk about designing better rituals; etcetera.
Everything that Agile promises can be discussed without using the word ‘Agile’. Doing so will decrease dissonance and increase wisdom.
I will be exploring many Agile topics in future transmissions. Please subscribe here.
The Business Agility Institute has a new journal that explores related topics: Emergence. The print edition is very nicely produced.
Waterfall diagram from W.W. Royce’s paper referenced below
Fitness landscape my own mash-up
Orchid by Capri23auto via Pixabay
For example, during ING Netherland’s Agile transformation, managers below level 1 had to reapply for a position. 25% were not reselected despite being ‘heroes’, well known for their expertise. Transformation at ING (A): Agile
Cognitive dissonance can cause us to misperceive or misinterpret information, to reject or refute it, to seek support from those who agree with us, and attempt to persuade others to accept our point of view. See Harmon-Jones, Eddie & Mills, Judson. (2019). An introduction to cognitive dissonance theory and an overview of current perspectives on the theory.
The Waterfall model for software development is incorrectly attributed to Royce, but Royce articulated the problem really, really well. Barry W. Boehm (1987). "Software Process Management: Lessons Learned from History" in ICSE '87 Proceedings of the 9th international conference on Software Engineering pp 296-298
Joyce, W.W. "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9.
In 1994 The Standish Group reported a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns is just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars. Mulder, Hans. (1994). The Chaos Report.
See Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch for a good discussion about Agile’s progress at that time
To be clear, most consultancies did not advocate this. Agile hype reverberated around the mediasphere like all other forms of misinformation. For a rational consultant’s perspective see: Agile at Scale, How to go from a few teams to hundreds by Darrell K. Rigby, Jeff Sutherland, and Andy Noble. 2018, Harvard Business Review.
Uludag, Ömer & Kleehaus, Martin & Caprano, Christoph & Matthes, Florian. (2018). Identifying and Structuring Challenges in Large-Scale Agile Development Based on a Structured Literature Review.
Max-Neef, Manfred A. (1991) Human Scale Development. Apex Press, NY