The Role Language Pruning Plays in Agile Transformations

26 May

“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




2. 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
3. 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.
4. 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
5. Joyce, W.W. "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9.
6. 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.
7. This is a simplification for brevity. For more detail refer to Agile 101
8. See Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch for a good discussion about Agile’s progress at that time
9. 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.
10. Uludag, Ömer & Kleehaus, Martin & Caprano, Christoph & Matthes, Florian. (2018). Identifying and Structuring Challenges in Large-Scale Agile Development Based on a Structured Literature Review.
11. Max-Neef, Manfred A. (1991) Human Scale Development. Apex Press, NY

Image credits:

Waterfall diagram from W.W. Royce’s paper referenced below

Fitness landscape my own mash-up

Thank you!

Your details have been submitted and we will be in touch.

Enhance your productivity, sign up to our newsletter

See our Privacy Policy for more details. You can unsubscribe at any time.

Problem submitting!

- {{formError.message}}

Submitting, please wait


Thank you!

Your details have been submitted and we will be in touch.