Avoid High Modernism - Get Comfortable With Complexity in Agile Transformations

Avoid High Modernism - Get Comfortable With Complexity in Agile Transformations

Avoid High Modernism - Get Comfortable With Complexity in Agile Transformations

All the state simplifications that we have examined have the character of maps. That is, they are designed to summarize precisely those aspects of a complex world that are of immediate interest to the map- maker and to ignore the rest. To complain that a map lacks nuance and detail makes no sense unless it omits information necessary to its function. A city map that aspired to represent every traffic light, every pot- hole, every building, and every bush and tree in every park would threaten to become as large and as complex as the city that it depicted.’ And it certainly would defeat the purpose of mapping, which is to abstract and summarize. A map is an instrument designed for a purpose. We may judge that purpose noble or morally offensive, but the map it- self either serves or fails to serve its intended use.

James C Scot, Authoritarian High Modernism [1]

Legibility and High Modernism

White Building 23

Exactly like a city map, an agile framework like Scrum or SAFe or LeSS tries to abstract and summarize practices that have been found useful in a certain context. The nuances and details of the context that made those practices work are omitted in the process of abstraction, otherwise the map would become too hard to comprehend.

However, this is where the challenge lies.  The oversimplification often ignores the ground realities of a complex world.  This “legibility” which James C Scott introduces in his book Seeing like a State continues to influence governments, enterprises and even individuals in how they think and act.

The Twentieth century high modernism which Scott describes continues even in the 21st century too. It has similar modes of failure patterns. These patterns are described beautifully by Rao in his article [2] :

Look at a complex and confusing reality

Fail to understand all the subtleties of how the complex reality works

Attribute that failure to the irrationality of what you are looking at, rather than your own limitations

Come up with an idealized blank-slate vision of what that reality ought to look like

Argue that the relative simplicity and platonic orderliness of the vision represents rationality

Use authoritarian power to impose that vision, by demolishing the old reality if necessary

Watch your rational Utopia fail horribly

Agile Transformations Failure Patterns

Let us look at this from the lens of how Agile transformations are typically fashioned (often, not always)

  • Look at a complex and confusing reality. For example, software deliveries that are struggling or business that is failing to meet expectations of customers.
  • Fail to understand all the subtleties of how the complex reality works. While failures are definitely visible, the reality is never black  or white. The system has many nuances to comprehend why certain areas of the business are struggling while others continue to thrive.
  • Attribute that failure to the irrationality of what you are looking at, rather than your own limitations. The failures are often attributed in general to “lack of agile processes / mindset  / culture etc…”
  • Come up with an idealized blank-slate vision of what that reality ought to look like. Some XYZ agile framework is decided (either Scrum, SAFe or something tailored by a top notch consultants)
  • Argue that the relative simplicity and platonic orderliness of the vision represents rationality. The “vision” is sold to senior management as the silver bullet. It will roll them into the future or to the “new normal”
  • Use authoritarian power to impose that vision, by demolishing the old reality if necessary. The vision is sold/pushed on to the gullible workforce. New roles, new processes and the like…
  • Watch your rational Utopia fail horribly. The reality of the complex system kicks in.. The “high” eventually gives into reality of accepting whatever the teams manage to do. Everyone starts to say – Oh ! the framework was just the starting point !! And Starts to look for another framework or invent a new one.

Reality Serves Many Purposes

Rao states further,

reality that serves many purposes presents itself as illegible to a vision informed by a singular purpose. Any elements that are non-functional with respect to the singular purpose tend to confuse, and are therefore eliminated during the attempt to “rationalize.” The deep failure in thinking lies is the mistaken assumption that thriving, successful and functional realities must necessarily be legible. Or at least more legible to the all-seeing statist eye in the sky….Complex realities turn this logic on its head;…

The deep failure lies in the thinking that everything with the current reality that does not conform to the idealized blank-slate vision needs to be “rationalized” and change.  In creating that disruption, the new normal is a whitewash or often becomes worse than the current reality. This is especially true in organizations where change is pushed and not pulled.

So what do we do? Should we not use frameworks? Absolutely we should. Frameworks are models and models do serve a purpose, just like the maps. They do serve as an excellent starting point. However, once we are on our journey, a better understanding of the context is needed. Where you are and where you are heading to is far more important.

Google Maps

This is exactly what Google maps helps us do right. They are adjusting constantly and presenting us a new reality and updated map along the journey.

Measurements in Agile transformations are similar to that. Too often though done with a disregard for understanding of complex systems – leading to the failures. We end up using paper maps in a digital complex world. To design the right measures, we need to get the thinking aligned first with our complex reality.

John Burgoyne describes two competing schools of thought in measurement [3]. They are Control Vs Leave us alone.

On one end of the spectrum, there is the belief that what gets measured gets managed. … this side would argue we need to determine quantitative metrics to understand and track our progress, and then collect data that allow us to manage interventions against those metrics. This way of thinking, dominated by top-down accountability, can be characterised as “measurement for control”, where all we need to do is control an intervention well enough and do enough of it, and we will be able to achieve impact….those at the top of the hierarchy set performance measures and manage those at lower levels to hit those measures….On the other end of the spectrum, there is the belief that metrics alone cannot capture complex reality and that we should blindly rely on professionalism and [public sector] ethos to do a good job. …, it is impossible to attribute quantifiable impact to any single intervention. This side would argue that measurement is a pointless and often harmful endeavor, as it can hold people accountable for things beyond their control, leading to gaming and perverse incentives. This way of thinking can be characterised as “leave us alone”, where there is a lack of accountability mechanisms and ways of measuring.

Measurement Mindset

Leaning towards either of these approaches is not helpful and often detrimental. We need a better appreciation for complex systems. What this essentially means is doing measurements with a mindset that John details in the article as the third option – measurements for learning.

  1. Data collection is fine, as it is through data that can try to probe and make sense of our evolving complex world.
  2. Given the non-linear cause and effect relationships in a complex world, holding people accountable for metrics beyond their control is often not helpful
  3. Validated learning is fundamental to the metrics. This is crucial to have insights from the experimentation and interventions that are done as we adapt and respond.


Wearable 9

To have measurements that are built for “probe-sense-respond”, we need to have the right mindset of measurement for learning. The complex world needs this more than measurements that just categorize (simple systems) and analyze (complicated systems). We need to get past this thinking of simple/complicated and start treating complex systems as complex systems. The same frameworks then might get us far better results. The measurements will provide us insights to adapt in the right manner – once we get past the linear thinking.

Agile coaches and transformation leaders should encourage enterprises to get comfortable with complexity and develop systems thinking to avoid the high modernism patterns. Instead of trying to force fit the beautifully complex world into a linearity, they should revel in its messiness and move forward. We have a far better shot at business agility with that.


Thanks to @TheaSnow from the Centre for Public Impact, Australia and New Zealand. Her article inspired me to write this one. [4]


[1] Scott, J., 2021. Chapter 3. Authoritarian High Modernism. [online] De Gruyter. Available at: <https://www.degruyter.com/document/doi/10.12987/9780300128789-005/html> [Accessed 27 May 2021].

[2] Rao, V., 2021. A Big Little Idea Called Legibility. [online] ribbonfarm. Available at: https://www.ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/> [Accessed 27 May 2021].

[3] Centre For Public Impact (CPI). 2021. Measurement for Learning: A Different Approach to Improvement. [online] Available at: <https://www.centreforpublicimpact.org/insights/measurement-learning-different-approach-improvement> [Accessed 27 May 2021].

[4] Impact of Social Sciences. 2021. The (il)logic of legibility – Why governments should stop simplifying complex systems. [online] Available at: <https://blogs.lse.ac.uk/impactofsocialsciences/2021/02/12/the-illogic-of-legibility-why-governments-should-stop-simplifying-complex-systems/> [Accessed 27 May 2021].

Share this article

Leave your comments

Post comment as a guest

terms and condition.
  • No comments found

Share this article

Hrishikesh Karekar

Agile Expert

Hrishikesh is a Director, Financial Services BU at Capgemini. He has 19+ years of experience in IT software industry playing high responsibility roles as Agile Transformation Lead, Agile Coach, Program Manager, Delivery Manager, Technical Project Manager, Technical Lead & Software Engineer. Hrishikesh is passionate about building high performing teams, taking individuals and teams on a journey of excellence and satisfaction. His vision of Agile is not just about implementing effective, efficient and lean processes, but transforming people’s mindsets – to deliver better ROI and real business benefits. Hrishikesh holds a Bachelor of Engineering, Production Engineering from VJTI, University of Mumbai.

Cookies user prefences
We use cookies to ensure you to get the best experience on our website. If you decline the use of cookies, this website may not function as expected.
Accept all
Decline all
Read more
Tools used to analyze the data to measure the effectiveness of a website and to understand how it works.
Google Analytics