Enterprise Agility is a book by Sunil Mundra, Principal Consultant at ThoughtWorks, published in 2018, which makes the distinction that the entire Agile Industrial Complex has spent twenty-five years failing to make: the difference between doing Agile and being agile.
The distinction is not semantic. It is the difference between installing a framework and developing a capability. Between adopting Scrum ceremonies and building an organization that can sense change and respond to it. Between “we do two-week sprints” and “we can change direction when direction is wrong.” One is a process. The other is a property of the organism.
The book is correct. The book is clear. The book sits on shelves next to SAFe implementation guides, which is the organizational equivalent of storing the antidote next to the poison and reaching for the poison every time.
The Core Distinction
Mundra’s central argument is devastatingly simple:
Agile is a set of values, principles, and practices for building software. It lives in teams. It is expressed in ceremonies, artifacts, and roles. You can adopt it. You can certify people in it. You can buy it.
Agility is a property of an organization — the ability to sense change, respond to it, adapt, and thrive. It cannot be adopted. It cannot be certified. It cannot be bought. It must be grown.
The industry confused the two. It assumed that adopting Agile practices would produce organizational agility, the way installing a speedometer produces speed. The speedometer measures. It does not propel. Scrum measures. It does not propel. The propulsion comes from somewhere else entirely — from culture, leadership, structure, and the willingness to treat the organization as a living system rather than a machine.
“You’ve spent years optimizing process. Sprint length. Ceremony cadence. The precise angle of the Kanban board. You’ve facilitated a thousand retrospectives. You’ve watched organizations layer Scrum on top of SAFe on top of existing dysfunction and call it ’transformation.’”
— riclib, Mythology Driven Development — Substack Draft
The Living System
Mundra’s most consequential insight is that enterprises are not machines. They are complex adaptive systems (CAS) — living organisms that sense their environment, adapt their behavior, and evolve over time.
This contradicts a century of management theory rooted in Frederick Taylor’s scientific management: the idea that organizations are mechanisms to be engineered, where managers think and workers do, where efficiency is the supreme value, and where processes and methods should drive ways of working. Taylor’s model is a machine. Mundra’s model is a garden.
The distinction matters because machines and organisms respond differently to change:
| Machines | Living Systems |
|---|---|
| Redesigned from scratch | Evolved incrementally |
| Changed by engineers (managers) | Adapted by the system itself |
| Optimized for efficiency | Balanced between efficiency and resilience |
| Fail when parts break | Heal when stressed |
| Need blueprints | Need conditions |
Transformation Initiative treats the organization as a machine — redesigning it from scratch, violating Gall’s Law, and resetting any benefits that accrued from stability. Enterprise agility treats the organization as a living system — creating the conditions for adaptation and letting the system evolve.
The machine metaphor produces reorgs. The living system metaphor produces growth.
The Six Capabilities
Mundra identifies six capabilities underlying agility, drawn from David S. Alberts:
Responsiveness — Sensing that action is needed, determining what action to take, and taking it at the appropriate time. Not “responding to change over following a plan” (the manifesto). Responding to change before the plan knows it needs to change.
Versatility — Achieving desired outcomes under new and varying conditions, especially under stress. The ability to function when the environment changes in ways nobody planned for — which is always.
Flexibility — Generating alternate approaches when the original approach fails. Not agile-with-a-lowercase-a flexibility (changing priorities between sprints). Organizational flexibility — the ability to do the work a different way when the current way stops working.
Resilience — Recovering from setbacks by repairing, reconstructing, or creating something new. Not “fail fast” (the startup mantra). Fail, learn, rebuild — and emerge stronger than before.
Innovativeness — Creating approaches never used before to respond to circumstances never encountered before. Not “innovation lab” (the corporate theater). Actual invention, at the point of need, by the people closest to the problem.
Adaptability — Changing, eliminating, or creating organizational components — structure, processes, roles — when the current ones are impediments. This is Reorg done right: changing the organization because the organization needs to change, not because the pendulum is due to swing.
None of these capabilities are produced by adopting a framework. All of them are properties of a living system that has been given the conditions to develop them.
The Adoption Problem
Mundra catalogs the failure modes of Agile adoption with the precision of a pathologist:
-
Focus on “doing” Agile — Adopting the ceremonies without the values. Sprint planning without autonomy. Retrospectives without psychological safety. The form without the substance.
-
Adoption without addressing systemic issues — Installing Scrum on top of a command-and-control culture, a dysfunctional incentive structure, and a fourteen-level hierarchy, then wondering why the standups don’t work.
-
The “cookie cutter” approach — Applying the same framework to every team, every context, every problem. SAFe for a twelve-person team. The Spotify Model for a company that is not Spotify. One size fits none.
-
Leaders feeling threatened — Agile distributes decision-making. Leaders whose authority depends on centralized decision-making experience this as a threat, not an opportunity. The framework is adopted. The power structure is not.
-
Wrong expectations — Expecting agility to mean “faster delivery” rather than “better sensing and responding.” The board wants velocity. The organization needs adaptability. These are different things.
Each failure mode is a variation of the same mistake: treating agility as something you install rather than something you grow.
The Accidental Mentor
The lifelog’s connection to Enterprise Agility came through the accidental mentorship that defines the best professional relationships — the kind that begins when someone invites an author to talk about their book on Clubhouse and ends with a weekly book club that reshapes how the inviter thinks about organizations.
Sunil Mundra became an accidental mentor not through a formal coaching engagement or a consulting contract but through the oldest mechanism of knowledge transfer: reading a book together, out loud, with strangers who became a community. The book club met weekly. The author attended. The ideas propagated not through a transformation initiative but through conversation — which is, upon reflection, exactly how a complex adaptive system transfers knowledge.
The mentor did not know he was mentoring. The student did not know he was being mentored. The knowledge transferred anyway, because living systems do not require formal channels. They require proximity, repetition, and trust.
Seven years later, the student would build a one-person organization with one binary, one database, and the instinct to grow things rather than design them from scratch. The instinct has a name. The name is in the book. The book is on the shelf. The shelf is not dusty.
The Lizard Connection
The Lizard has never read Enterprise Agility. The Lizard does not read books about organizational theory, because the Lizard is a complex adaptive system of one, and a complex adaptive system of one does not need a book to explain how it adapts.
But the Lizard is enterprise agility — instinctively, pre-theoretically. The Lizard senses change (the code doesn’t compile). The Lizard responds (fix it). The Lizard adapts (simplify the architecture so it breaks less). The Lizard is resilient (delete what doesn’t work, rebuild what does). The Lizard innovates (one binary, no Docker, SQLite for everything). The Lizard is versatile (the same organism builds the backend, the frontend, the blog, and the wiki).
Six capabilities. One lizard. No framework.
Sunil Mundra wrote the theory. The Lizard is the proof.
Don’t Manage Change, Facilitate It
The book’s final chapter is its most subversive. Chapter 15 is titled “Facilitating Change” — not “Managing Change.” The distinction is deliberate.
Managing change implies control — a plan, a timeline, a Change Management Office. Facilitating change implies creating conditions — clearing obstacles, providing safety, letting the system adapt. Managing is mechanical. Facilitating is organic.
Mundra’s learnings from this chapter read like a Yagnipedia index:
- “People do not resist change” — they resist being changed without being consulted (see: Reorg)
- “Things will get worse before they get better” — the J-curve that every transformation ignores
- “Don’t copy frameworks blindly” — see: The Spotify Model, SAFe, every article in this encyclopedia
- “Sense of purpose over sense of urgency” — the opposite of every Town Hall announcement ever
- “Don’t manage change, facilitate it” — Agendashift, wearing a lab coat instead of a trenchcoat
Measured Characteristics
Pages in the book: ~350
Pages the industry read: the subtitle
Distinction between Agile and agility: 1 (critical)
Organizations that understood the distinction: few
Organizations that adopted SAFe anyway: most
Capabilities underlying agility: 6
Capabilities produced by installing a framework: 0
Complex adaptive systems in the book: 1 (the enterprise)
Complex adaptive systems in the lifelog: 1 (the Lizard)
Mentors who knew they were mentoring: 0
Students who knew they were being mentored: 0
Knowledge transferred anyway: yes
Book clubs that changed how someone thinks: 1
Weekly sessions: ~20
Frameworks recommended: 0
Conditions recommended: all of them
