“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 transformations1.
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 casualties2.
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 beliefs3.
Let’s explore the roots of this dissonance, as well as an easy way to reduce it.
The problem 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 problem4, 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.
5
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 dissatisfaction6.
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 development7.
How Agile became an inspiration
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 problem9.
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 challenges10 commonly 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.
Language pruning
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”11
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.
Posted by John Dobbin.
Post Bureaucracy
References:
Image credits:
Waterfall diagram from W.W. Royce’s paper referenced below
Fitness landscape my own mash-up
Author: John Dobbin
Originally published on
SoftEd.
For more resources, visit
SoftEd’s learning hub.