Agility Is Not About Speed or Mindset

By now, many of us in the Agile community have come to realize that agility is not about speed—at least not in the simplistic sense of doing things faster or more efficiently. That kind of performance measurement belongs more to the realm of resource or functional management, and ultimately to HR, where performance is measured by throughput and task completion speed.

Yet a persistent belief remains: that Agile is primarily about people and their individual mindsets—that being Agile is simply a matter of how one thinks. Personally, I find this framing both reductive and misleading. I’ve learned a great deal from Dave Snowden, particularly his critique of the “mindset” concept.

Snowden argues that “mindset” is often treated as a fixed and engineerable mental model—something you can design, implement, and scale. But this fundamentally contradicts the complexity and contextuality of human cognition. He warns that enforcing a uniform “Agile mindset” leads to homogenization and reduces the adaptive capacity of organizations.

Moreover, if we engage with the concept of embodiment, we understand that cognition is not confined to the brain. Rather, it is extended into our bodies, environments, tools, and social interactions. In this view, behavior does not emerge from internal mental models alone but from a rich interplay of external and internal contexts. Therefore, saying “Agile is a mindset” dramatically oversimplifies the deeply embodied and situated nature of human behavior.

Let me offer a simple analogy: consider how driving behavior changes when someone moves from one country to another. In some countries, traffic may seem chaotic, while in others, it is tightly regulated with clear constraints. A person moving to a highly regulated environment doesn’t need mindset training to drive differently. Their behavior shifts automatically—because the system of rules, constraints, and social norms around them has changed. The context drives the adaptation, not an internal reprogramming of beliefs or values.

This principle holds across all social systems. The debate is not limited to Agile transformation; it is central to any effort involving behavioral change in complex environments.

Culture Change Is Not in the Individual Mind Alone

When someone says, “Agile is a cultural change,” or “We need to shift the culture,” I often become cautious. Why? Because culture is not just about what people think. It’s about how people interact, how decisions are made, and how behavior emerges in response to structural constraints.

As Snowden emphasizes, attempting to engineer cultural change through mindset reprogramming is not only ethically dubious but practically ineffective at scale.

We are not responsible for changing people’s minds or cultures. We are responsible for changing the collective way of working—the interactions, structures, and constraints that shape behavior.

So What Can We Do? Looking for Emergence

To effect meaningful change in complex systems, we must understand the conditions under which emergence occurs—a core principle in complexity science.

Emergence arises when:

• There are many autonomous agents (people, roles, tools).
• These agents engage in rich, local interactions.
• No single actor has a full view or centralized control of the system.

Human systems are even more complex, as they involve multiple identities, histories, and contexts. And crucially, culture is not designed—it emerges as a collective property of this complex network of interactions.

The Role of Actants: Constructors, Constraints, and Actors

In complexity-informed transformation, we focus on actants—a term used to describe any entity (not just people) that affects the system. This includes:

• Constructors: process and rituals that shape behavior (e.g., team norms, Scrum ceremonies, architecture). Constructors enable transformations.
• Constraints: Boundaries that shape or limit behavior (e.g., compliance rules, WIP limits). constraints can contain or connect.
• Actors: The agents who operate within the system.

These actants do not operate in isolation; they modulate the system and shape the emergent behavior of the system.

To build coherence in Complex System like organization, we must contextualize and align these elements:

• Empower actors to make local interactions.
• Design constraints that enable rather than restrict.
• Evolve constructors to support adaptability and emergence.

As Dave Snowden puts it: coherence is not about control—it’s about finding patterns that are stable enough to act upon without assuming full predictability.

From Mindset to Actants: A Shift in Agile Transformation

Rather than focusing on vague abstractions like “mindset” or “culture,” we should focus on configuring the actants of the system to enable change. If we want to enable change and create a wave of transformation, we must work on actants. This is where Snowden’s AIMS framework becomes powerful:

• Actants
• Interactions
• Monitors
• Scaffolding

Let’s elaborate on Interactions, Monitors and Scaffolding.

Interactions in AIMS

Definition: Interactions are local, real-time exchanges between actants that produce emergent patterns. These interactions are not orchestrated from the top—they occur organically.

 Purpose:

• Enable emergence through rich, diverse engagements.
• Foster adaptation and coherence through dialogue.
• Observe and influence the system through lived experience.

 Agile Examples:

• Daily stand-ups are not just for status updates—they are real-time coordination points.
• Pair programming and cross-functional sessions foster shared understanding.
• Informal chats or Slack channels often hold more adaptive value than formal reviews.

Monitoring in AIMS

Definition: Monitoring is the continuous observation of patterns and emergent behaviors within a system. It’s not about fixed KPIs, but about detecting weak signals, shifts in behavior, and emerging coherence.

 Purpose:

• Detect weak signals early.
• Sense changes in the system early.
• Identify patterns that are emerging naturally.

 Agile Examples:

• Observing the quality of retrospectives
• the diversity of voices in planning
• Noticing informal leadership emerging in stand-ups.

Scaffolding in AIMS: Support Without Imposition

Scaffolding refers to temporary structures designed to support new behavior without enforcing rigid rules.

Unlike constraints, which define the boundaries of what is possible or permissible, scaffolding is developmental. It is designed to support learning, exploration, and adaptation. Once the desired behavior or pattern becomes stable or self-sustaining, the scaffolding can be removed or reshaped.

A temporary structure that helps something grow or emerge, and can be removed once it’s no longer needed.

 Purpose:

• Enable safe-to-fail experimentation.
• Create space for novel practices to emerge.
• Provide support that is removed as systems mature.
• To support autonomy while maintaining coherence.

 Agile Examples:

• Working agreements.
• Retrospectives and learning reviews.
• Innovation sprints
• Pair programming

Scaffolding differs from constraints:

• Constraints limit action. They are structural boundaries that define what is allowed or not and also often persistent.
• Scaffolding enables action and development. It is supportive infrastructure that helps something new emerge and it is temporary which enables behavior.

These scaffolds are not permanent mandates. They are contextual tools that help teams grow into new ways of working. As teams mature, scaffolds can be removed, replaced, or evolved.

Types of Scaffolding in AIMS:

1. Steel Scaffolding

• What it is: A strong, rigid structure used temporarily during construction.
• Purpose: Provides solid support while something is being built, then removed once the structure is stable.
• Agile Example: A strict Scrum framework used with a new team. It gives structure and discipline early on, but can be relaxed or adapted as the team matures.

2. Bamboo Scaffolding

• What it is: A more flexible, craft-based structure requiring skill to build.
• Purpose: Offers support but allows more movement and adaptation.
• Agile Example: A Kanban system tailored by the team. It’s flexible and evolves with team needs, but requires experience to maintain effectively.

3. Nutrient Lattice

• What it is: A medical scaffold placed over a wound to help skin regrow, which dissolves over time.
• Purpose: Supports regeneration and healing, then disappears.
• Agile Example: A coaching engagement that helps a team recover from dysfunction. The coach gradually steps back as the team becomes self-sustaining.

4. Placement Lattice

• What it is: Similar to a nutrient lattice, but leaves behind filaments that integrate into the body.
• Purpose: Supports healing and leaves behind lasting support structures.
• Agile Example: Introducing a practice like retrospectives that becomes embedded in team culture even after external support is gone.

5. Shadow or Dark Scaffolding

• What it is: Informal structures that evolve over time, often unnoticed.
• Purpose: Emergent support systems that can’t be designed in advance.
• Agile Example: Slack channels, informal mentoring, or community-of-practice groups that arise organically to support learning and collaboration.

6. Keystones

• What it is: A central piece in an arch that holds everything together. If removed, the whole structure collapses.
• Purpose: Provides critical stability, often invisible until it’s gone.
• Agile Example: A team lead or senior developer whose presence holds the team together. Their departure reveals how much depended on them.

Understanding which type of scaffolding is needed at which phase of team development is key to enabling growth and resilience.

Each type of scaffolding serves a different purpose depending on the maturity of the team, the complexity of the environment, and the desired outcomes. In Agile transformation:

• Use steel scaffolding to establish discipline in new teams.
• Shift to bamboo scaffolding as teams gain confidence and autonomy.
• Apply nutrient or placement lattices to support healing or cultural embedding.
• Recognize and nurture shadow scaffolding as a sign of healthy emergence.
• Identify keystones and ensure they are not single points of failure.

The River Metaphor: A Systemic View of Change

Imagine an organization as a river—a living, flowing system. This metaphor offers a powerful lens for understanding how change happens in complex environments, especially in Agile transformations. Rather than trying to control individual elements (like a single water droplet), we must work with the systemic structures that shape flow and behavior.

Let’s explore this metaphor through the lens of the AIMS framework:

Actants: The Elements in the Flow

In the river:

• Actants include the water, rocks, sediment, fish, and plants—all the entities that interact within the system.
• In an organization, actants are people, tools, roles, technologies, and even ideas.

These actants are not isolated—they are interdependent and context-sensitive. Change does not happen by altering one actant in isolation; it happens through shifts in the relationships between them.

Interactions: The Currents and Eddies

In the river:

• Interactions are the currents, whirlpools, and ripples—the dynamic exchanges between water and terrain, between fish and flow.

In Agile organizations:

• Interactions are the daily stand-ups, code reviews, collaborative design sessions, and informal conversations.
• These are local, real-time exchanges that generate emergent patterns—the heart of agility.

Healthy interactions are diverse, frequent, and contextual. They are where learning, adaptation, and coherence emerge.

Monitoring: Reading the River

In the river:

• Monitoring is like watching the water level, measuring flow speed, or noticing changes in clarity or temperature.

In Agile transformation:

• Monitoring means observing patterns in team behavior, detecting weak signals of change, and tracking emergent coherence.
• It’s not about rigid KPIs, but about sensing the system: Are teams collaborating more? Are new practices emerging? Are tensions rising?

Monitoring allows leaders to respond in real time, not with control, but with curiosity and care.

Scaffolding: Shaping the Flow Without Blocking It

In the river:

• Scaffolding includes temporary dams, canals, or levees—structures that redirect, slow, or amplify the flow without stopping it.

In Agile:

• Scaffolding includes working agreements, retrospectives, innovation sprints, or pair programming.
• These are temporary, enabling structures that support new behaviors and allow safe experimentation.

Scaffolding is not permanent. It is contextual, adaptive, and removable once the system stabilizes.

The Core Insight

If you want to change the river, you don’t try to change a single water droplet. You work with:

• The banks (constraints),
• The flow (interactions),
• The structures (scaffolding and constructors),
• And the ecosystem (actants).

You can amplify the flow, dampen it, or redirect it—but you cannot stop it or turn it into something else entirely. The meaning of the river—its identity—remains.

This metaphor beautifully illustrates the ethos of Agile transformation:

Work with the system, not against it. Shape the conditions for emergence, rather than forcing change from above.

ASHEN Framework: Embedding Knowledge in Transformation

Agile is fundamentally about knowledge work. That’s why knowledge management is central to Agile transformation.

Dave Snowden’s ASHEN framework is a powerful tool for knowledge mapping. It helps organizations shift from key-person dependency to knowledge dependency, which is essential for sustainable transformation. This shift reduces reliance on individual actors—over whom we have little or no control—and instead focuses on the knowledge ecosystem.

As Snowden reminds us, “Knowledge can only be volunteered; it cannot be conscripted.” This means we cannot force people to share what they know—we must create the right conditions for knowledge to emerge and flow.

“ASHEN helps create a key shift in organizational thinking from key-person dependency to knowledge dependency. This essential step of depersonalization is critical to effective knowledge practice. It is the shift from Only Linda can do X to X requires this combination of artifacts, skills, heuristics, experience and natural talent and, at the moment, only Linda has them. The former statement has only crude solutions, the latter permits greater sophistication and the potential of lasting solutions and sustainable management action. It achieves this by using language that describes the situation at the right level of granularity to permit action without excessive analysis.”

— Dave Snowden, The ASHEN Model: an enabler of action, Knowledge Management

ASHEN Explained:

Here’s how each of the five ASHEN elements functions as a perspective or question:

• Artifacts – The explicit, codified knowledge in the organization: documents, tools, databases, templates.
• Skills – Competencies that can be taught and measured: facilitation, coding, negotiation.
• Heuristics – Rules of thumb or informal practices used in decision-making: “If it takes more than a day, break it down.”
• Experience – Tacit knowledge gained through lived events: launching a product, surviving a crisis.
• Natural Talent – Innate abilities that are hard to teach but critical: intuition, empathy, systems thinking.

Mapping ASHEN to AIMS

These two frameworks—AIMS and ASHEN—complement each other beautifully. Together, they provide a multi-dimensional lens for designing and guiding transformation:

• Artifacts → Constraints / Constructors: Define boundaries and tools.
• Skills → Constructors / Actors: Enable capability and autonomy.
• Heuristics → Interactions / Experience: Guide decision-making.
• Experience → Actors/ Stories: Inform learning and adaptation.
• Natural Talent → Actors: Leverage unique human potential.

Applying ASHEN in Practice

ASHEN is not just a typology—it’s a method for eliciting knowledge. But it must be contextualized. Simply asking someone “What do you know?” is meaningless. A better question is:

“When you made that decision, what knowledge did you use?”

To apply ASHEN effectively, ask contextualized questions:

• What artifacts were needed to get the job done?
• What skills were required? Who has them? How were they acquired?
• What heuristics or habits made it easier?
• What experience was necessary in terms of time and context?
• What natural talent was involved? Who has it? How can we nurture it?

This approach helps surface the real knowledge landscape—not just what’s written down, but what’s lived and embodied.

By using the ASHEN framework in alignment with AIMS, you can gain a deeper understanding of the actants that are modulating your system. The ASHEN questions help you uncover the underlying artifacts, skills, heuristics, experience, and natural talent that influence behavior. This, in turn, gives you greater visibility into the actants—specifically the constraints, constructors, and actors—within your environment. With this insight, you can more effectively define contextual actions for transformation, not by forcing change, but by identifying where to amplify or dampen emergent patterns.

Wardley Mapping: No One-Size-Fits-All, Contextualizing Actions.

While I won’t go into the full detail of Wardley Mapping here, I’ve found it to be a powerful strategic tool—especially when thinking about Agile transformation and knowledge work. Wardley Mapping helps us visualize the landscape and business climate in which we operate. It considers evolutionary maturity—how components of a system evolve over time—and helps us align strategy with context.

Wardley Maps break down the evolution of activities, data, knowledge, and practices into four stages:

• Genesis – Novel, experimental, high uncertainty.
• Custom Build – Tailored solutions, still evolving.
• Product/Rental – Standardized offerings, reusable.
• Commodity – Highly industrialized, automated, or outsourced.

This evolutionary view is essential when applying frameworks like ASHEN and AIMS, because it reminds us that context matters. The same practice or method may be appropriate in one phase and completely ineffective in another.

Wardley Mapping helps us understand:

• What we are doing (value chains),
• Where those components are in terms of evolution (from Genesis to Commodity),
• And how to act accordingly.

Key Insight: Different components require different methods. What works in one part of the system may be completely inappropriate in another.

How This Aligns with AIMS and ASHEN:

Wardley Mapping reinforces the principles of AIMS and ASHEN:

• AIMS helps you monitor and scaffold behavior based on how actants interact.
• ASHEN helps you understand what knowledge is needed and where it resides.
• Wardley Mapping helps you place those insights in context—so you can choose the right approach for the right component at the right time.

Together, these frameworks help you move from one-size-fits-all transformation to context-aware, adaptive strategy.

Practical Example: AI Product Development:

Imagine a company building a new AI product:

• AI Model Development is in the Genesis phase → Use Agile, prototyping, and safe-to-fail experimentation. → Focus on natural talent, heuristics, and emergent learning.
• API Layer is in the Product phase → Use Lean to optimize flow and reduce waste. → Focus on skills, artifacts, and standardization.
• Cloud Infrastructure is in the Commodity phase → Use standardized processes, automation, and cost control. → Focus on artifacts and constraints, minimize variability.

Trying to apply Scrum to all three would be inefficient—and potentially harmful. Instead, we must contextualize our methods based on where each component sits in its evolutionary journey.

The Sloth Is Agile: A Final Reflection

Agility is not about rushing. It’s about contextual adaptation and sustainable coherence. Even the sloth, often labeled lazy, exemplifies agility—because it optimally adapts to its environment with minimal energy expenditure. That, too, is agility.

Summary: Designing for Coherence

To lead a successful Agile transformation:

• Don’t attempt to rewire people’s minds.
• Design for emergence using actants.
• Use AIMS to scaffold and monitor adaptive behavior.
• Use ASHEN to manage and distribute knowledge.
• Apply Wardley Mapping to align method with context.

The Patchwork Rug and the Loom: A Cultural Analogy for Coherence

Agility is not a destination or a mindset—it’s a systemic condition where coherence emerges and evolves.

At the top of this article, you may have noticed the image of a Persian patchwork rug (فرش چهلتکه). This traditional art form is more than just decoration—it’s a powerful metaphor for how coherence emerges in complex systems.

Each patch in the rug represents a different personality, story, or context. These patches are not uniform, but they are connected through constraints (the stitching) and constructed through a process that brings them into a coherent whole. The person weaving the rug is not inventing the design from scratch—it is emergent, shaped by history, tradition, and context.

And what holds it all together during the weaving process? The carpet loom (دار قالی). The loom is like scaffolding in the AIMS framework: it provides temporary structure that supports the creation of something coherent. Once the rug is complete, the loom disappears—but its influence remains in the final form.

Just like in Agile transformation, we don’t force uniformity. We work with diversity, context, and history—using scaffolding to support emergence, not control it.

Acknowledgment

This article has been deeply influenced by my ongoing study of the work of Dave Snowden, particularly his contributions to complexity thinking, knowledge management, and the development of the Cynefin framework, AIMS, and ASHEN. His insights have helped me reframe how I understand Agile transformation—not as a linear process or mindset shift, but as a contextual, emergent journey shaped by interactions, constraints, and collective sense-making.

Final Reflection

Agility is not about speed, performance metrics, or enforcing a mindset. It is about working with complexity, honoring context, and designing for emergence. The message is clear:

There is no one-size-fits-all.