Introduction
With the rise of large-scale Agile transformations, organizations often create roles and frameworks intended to accelerate their journeys toward agility. One such role is the Tribe Agile Coach; a position designed to operationalize a global Agile blueprint, establish structures, and lead transformations across complex enterprises. At first glance, this sounds like a natural evolution of an Agile implementation. However, a closer look reveals a profound tension, if not outright misalignment, between what such roles entail and the foundational principles and values of the Agile Manifesto. This blog post examines the responsibilities of a Tribe Agile Coach role and contrasts them with Agile’s core values and principles
The Agile Manifesto was born out of practitioners’ desire to break free from bureaucratic processes and put people first. It is a statement of values and principles, not a prescriptive set of rules. Yet, in many large organizations, the role of the “Agile Coach” has emerged as the person responsible for enforcing standardized blueprints, defining structures, and ensuring compliance. The twelve principles behind the Agile Manifesto emphasize continuous delivery, welcoming change, frequent delivery of working software, close cooperation, trust and support, face-to-face conversation, working software as the primary measure of progress, sustainable development, technical excellence, simplicity, self-organizing teams, and regular reflection and adjustment.
In essence, Agile is about empowerment, flexibility, collaboration, and continuous learning—not about rigid blueprints and top-down mandates.
This blog post critically examines the misalignment between such a role and the Agile Manifesto by addressing five key questions: Should an Agile coach
- Reinforce effective Agile transformation across the organization?
- Define and establish agile structures, roles, and processes?
- Ensure that all teams are following the Agile blueprint and any exceptions in processes, tools, or roles are documented?
- Implement the organization-wide shift from ‘Project-to-Product’?
- Be responsible for the implementation of a DevOps culture, rethinking organizational structures, and governance to enhance speed, quality, safety, and learning?
Let’s delve into each of these, always returning to the core values and principles of Agile.
Should an Agile Coach Reinforce Effective Agile Transformation across the Organization?
The Temptation of Reinforcement
Many organizations want to accelerate their “Agile transformation.” They envision a coach as the enforcer of change, responsible for ensuring everyone is “doing Agile.” This often becomes a top-down initiative.
The Agile Manifesto’s Perspective
The Agile Manifesto values individuals and interactions over processes and tools. Transformation is most effective when it is grown, not forced. The coach’s task is to foster understanding, encourage experimentation, and create safe environments for teams to learn and adapt. The transformation becomes real when teams own it, not when it is imposed upon them.
The Pitfalls of Reinforcement
- Compliance over commitment: When coaches are tasked with reinforcing transformation, compliance becomes the goal rather than genuine agility.
- Agile as a checklist: Teams may perform ceremonies without understanding the purpose, leading to “cargo cult Agile.”
- Loss of autonomy: Teams lose the freedom to adapt Agile to their context.
What’s the Alternative?
Agile coaches should be catalysts, not enforcers. They inspire, guide, and support. The transformation is not something to be reinforced from outside, but something that emerges from within, through trust, experimentation, and learning.
Should an Agile Coach Define and Establish Agile Structures, Roles, and Processes?
The Lure of Structure
It’s tempting to believe that if you define the right structures, roles, and processes, agility will follow. Many organizations want a “blueprint” so they can scale Agile predictably.
The Agile Manifesto’s Perspective
The Manifesto is not a process framework. It encourages self-organizing teams and values responding to change over following a plan. Teams should be empowered to define their own ways of working, within broad principles.
The Risks of Top-Down Structures
- Stifling innovation: Prescribed structures limit a team’s ability to experiment and improve.
- One size fits none: What works for one team may not work for another.
- Teams become passive: If structures are always provided, teams never develop the muscle to architect their own solutions.
What’s the Alternative?
Coaches should facilitate the emergence of structures—helping teams discover what works for them, not imposing a solution. The best Agile environments are those where roles and processes are co-created by the people doing the work.
Should an Agile Coach Ensure All Teams Are Following the Agile Blueprint and Any Exceptions Are Documented?
Blueprints are by nature prescriptive. They are designed to be followed, and deviations are treated as exceptions that must be explained and documented.
Individuals and teams become secondary to the global framework. There is a risk of teams becoming mere executors of centrally defined processes, rather than empowered agents shaping their own ways of working.
The Illusion of Control
Standardization is attractive in large organizations. Defining and enforcing a single “Agile framework” and requiring teams to document exceptions seems like a rigid way to ensure consistency and manage risk.
The Agile Manifesto’s Perspective
The Manifesto values individuals and interactions, customer collaboration, and responding to change. It encourages adaptation, not conformity.
The Manifesto encourages emergent processes shaped by those closest to the work. It values flexibility over rigidity and adaptation over enforcement. By cantering on a prescriptive blueprint, the Agile Coach role risks undermining this foundational principle.
The Dangers of Enforcing Frameworks
- Agile in name only: Rigid frameworks lead to “Agile theatre”—the appearance of agility without the substance.
- Documentation as bureaucracy: Documenting exceptions becomes a bureaucratic exercise with little value.
- Suppressed learning: Teams are discouraged from trying new things if every deviation must be justified and tracked.
Consequences
- Stifled innovation: Teams may hesitate to experiment or adapt if it means straying from the blueprint.
- Loss of ownership: Teams feel less responsible for their process, leading to lower engagement and motivation.
- Coaching becomes policing: The coach’s job shifts from enabling to enforcing.
What’s the Alternative?
Coaches should encourage teams to experiment and adapt. The purpose of frameworks is to serve the team—not the other way around. Standardization should be a last resort, not a first principle.
Should an Agile Coach Facilitate the Organization-Wide Shift from ‘Project-to-Product’?
The Shift Explained
“Project-to-Product” is a move towards long-lived, cross-functional teams responsible for a product’s lifecycle, rather than temporary project teams. Although this shift appears aligned with many Agile principles, in reality it is at odds with a dynamic and flexible workforce. Projects are by definition temporary, and at the end of the project the team may be dismantled, and the team members move to other (project) teams or leave the organisation.
The Agile Manifesto’s Perspective
Agile values continuous delivery, customer collaboration, and self-organizing teams. Moving from project to product can support these values—but only if it is done in a way that respects team autonomy.
The Coaching Dilemma
- Facilitator, not commander: The coach’s role is to help teams and leaders understand the benefits of product thinking and to guide the transition, not to mandate it.
- Context matters: Each team’s path will be different. Imposing a single approach undermines agility.
What’s the Alternative?
Coaches should facilitate dialogue, help teams understand the “why” behind the shift, and support the organization in experimenting with new ways of working. The goal is learning and adaptation, not compliance.
Should an Agile Coach Be Responsible for the Implementation of a DevOps Culture, Rethinking Organizational Structures, Governance, to Enhance Speed, Quality, Safety, and Learning?
The DevOps Challenge
DevOps and Agile share many values: collaboration, automation, and continuous improvement. Implementing DevOps requires cultural and structural change. However, an efficient DevOps process leads to standardisation and will act as an Agile inhibitor.
The Agile Manifesto’s Perspective
The Manifesto encourages technical excellence, sustainable development, and simplicity. However, it does not prescribe roles or governance models.
The Risks of Assigning Responsibility
- Ownership confusion: If the coach is responsible for DevOps, what are teams and leaders responsible for?
- Top-down mandates: Rethinking structures and governance should be a collaborative process, not a directive.
What’s the Alternative?
The coach can be a guide, helping the organization understand DevOps principles and co-creating change. But responsibility should be shared, with teams and leaders owning the transformation.
Conclusion: Rediscovering the Spirit of Agile
The Agile Manifesto was a response to the rigidity of traditional software development. It is ironic, then, that many Agile transformations have become equally rigid, enforcing blueprints and structures at the expense of empowerment and adaptability. The Manifesto was a call to put people, collaboration, and learning at the centre of software development. Sometimes, the Agile Coach role defined in large organizations risks turning Agile into a bureaucratic exercise: enforcing blueprints, policing frameworks, and owning transformations from above. A role responsible for prioritizing operationalization of a central blueprint, establishing governance, and enforcing compliance drifts from the spirit of Agile. Instead of enabling teams, it risks policing them. Instead of fostering learning, it risks creating bureaucracy.
True Agile coaching is about enabling—helping teams take ownership of their journey, fostering experimentation, and building environments where learning flourishes. The best coaches are humble guides, not enforcers.
True agility is messy, emergent, and human. It cannot be imposed from above. The role of the Agile coach is to walk alongside teams, not to stand above them. It is to foster experimentation, not to mandate compliance.
Teams and organisations that follow the spirit and values of the Agile Manifesto must resist the temptation to industrialize Agility. They should trust people over processes, collaboration over contracts, and adaptation over adherence. Real Agility is based on ethics; the organisation must respect its employees, trust in the wisdom of teams, the power of collaboration, and the value of continuous adaptation. Anything less is Agile in name only. Agility, in the end, is not a blueprint. It is a journey—one that every team must make for themselves.
