What Agile Frameworks Actually Do to Your Organization
A mapping tool for seeing what agile frameworks do to your organization — where constraints sit on the grid, who controls them, and whether they can change.
Agile frameworks promise flexibility. But what do they actually do to an organization’s ability to change?
Agile Software Development is a human system. The contexts, the people, and the work itself produce the knowledge needed to know what the standard should be. Prescriptions designed for digital systems don’t transfer cleanly, and solutions only emerge through people working and collaborating. Mapping the constraints is a way to make that visible.
If you’ve ever tried to modify a practice in a team that’s “doing Scrum”: moving a stand-up, changing how backlog refinement works, adjusting sprint length. And you hit resistance not from the team but from the framework itself. The framework has made that practice harder to change. Not because the practice is inherently difficult to modify. Because the framework has placed it in a position where changing it feels like breaking the rules.
There’s a simple way to see this.
The Mapping Idea
Take any constraint an agile framework introduces, and place it on a grid with two axes:
- Cost to change — how expensive or difficult would it be to modify this thing?
- Time to change — how long would it take to shift it, even with effort?
The grid looks something like this:
High cost ┤
to change │
│ FIXED BEDROCK
│ (hard to change, (almost
│ requires effort) immutable)
│
│
│ VARIABLE VISCOUS
│ (moderate effort, (resistant,
│ can shift) slow-moving)
│
│ ↑
│ drift, norms,
│ unwritten rules
│
Low cost │ GASEOUS SHIFTING
to change │ (shifting easily, (slow but volatile —
│ easily reformed) nothing to anchor)
│ →
└──────────────────────────────────────────
Short Long
Time to change →The grid has a four-quadrant structure, but the right edge is its own thing. Practices at the extreme right are low-cost to change but change slowly — drift, cultural norms, unwritten rules. They’re volatile in a way that can’t be controlled, because they shift at the speed of the system around them, not at the speed of anyone’s decision.
The same constraint can sit in different positions depending on the organization. In one company, a stand-up format might be a “liquid” — changeable on a team’s own authority. In another, it might be “bedrock” — standardized across the organization and effectively immovable without leadership approval.
Mapping constraints onto this grid reveals a balance. It’s not just a description of what is hard to change. It’s a description of the balance between global standardization and local adaptability that an organization has struck. Sometimes that balance is explicit and deliberate. Sometimes it happened by accident.
This mapping is also a useful exercise for teams to try in their own context. Working through the categories and marking where each constraint sits can surface conversations that don’t usually happen.
What Agile Frameworks Move
The components that any agile framework introduces, modifies, or constrains:
- Meetings & cadences — stand-ups, retrospectives, planning, demos, refinement
- Roles & responsibilities — Scrum Master, Product Owner, Developer; what each role owns and decides
- Teams — team size, composition, whether teams are independent (Scrum) or structured into release trains (SAFe)
- Customer interfaces — how customers participate (or don’t)
- Tools & artifacts — Jira configuration, boards, named deliverables like Sprint Backlog or PI Objective
- Process & practices — sprints vs. continual flow, WIP limits, technical practices
- Metrics — velocity, Service Agility Dashboard, program metrics
- Values — what the framework says matters
- Objectives & strategy — OKRs, prescribed objectives, risk handling
When mapping a framework’s impact, you’d take each of these categories, mark where each sits on the grid before adoption, and then mark where it sits after. The difference is the framework’s effect on the organization.
Where Constraints Live: The Ownership Layer
There’s a second dimension to this map that doesn’t get drawn explicitly: ownership. As cost and time to change increase, constraints tend to move out of the team’s control. At the high end, constraints are chosen by management or imposed by frameworks. At the low end, they’re better left to teams to decide.
┌─────────────────────────────────────────────────────────────────────────────┐
│ │
│ HIGH COST/TIME TO CHANGE │
│ (Standards - bedrock, fixed, viscous) │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ OWNERSHIP: Management / Enterprise / Framework │ │
│ │ │ │
│ │ • Team structures (ARTs, value stream boundaries) │ │
│ │ • Roles and responsibilities (Product Owner, Scrum Master, RTE) │ │
│ │ • Cadences (sprint length, PI cadence) │ │
│ │ • Tools (Jira configuration, reporting structure) │ │
│ │ • Values (organization-wide) │ │
│ │ • Cross-team coordination patterns │ │
│ │ │ │
│ │ The team cannot change these without escalation. │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ LOW COST/TIME TO CHANGE │
│ (Volatile - liquid, gaseous, variable) │
│ │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ OWNERSHIP: Teams / Individuals │ │
│ │ │ │
│ │ • How a stand-up is run │ │
│ │ • What practices to try (pairing, mobbing, TDD) │ │
│ │ • Local tooling choices (within the team's scope) │ │
│ │ • Daily workflow patterns │ │
│ │ • Team norms and interaction styles │ │
│ │ │ │
│ │ The team can change these directly. │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Some of this is appropriate.
Cross-team coordination needs standards. Organizational strategy needs alignment. You can’t have ten teams each doing PI Planning differently and expect them to synchronize. Coordination, strategy, and cross-cutting concerns are legitimate reasons to put constraints in the high-cost zone.
The trap is putting everything there.
Organizations adopting frameworks often push everything up. They standardize the stand-up format, the definition of done, the retrospective structure, the backlog format, the branching strategy, the testing approach, the release process. They treat the framework as a complete answer and remove the team’s ability to make local decisions.
This looks like alignment. It feels like maturity. But it removes the team from having any control over how they work, which removes their ability to adapt, which removes the agility that the framework was supposed to provide.
The test for where a constraint belongs:
For any constraint a framework prescribes, ask: does any team other than this one need to know or care about how this team does this thing?
If no — it’s a team-level decision. Keep it in the low-cost zone. If yes — it’s an enterprise-level decision. Standardize it.
The frameworks that violate this principle (by standardizing team-internal practices) push more constraints than necessary into the high-cost zone and remove more autonomy from teams than the coordination problem requires.
The principle:
- Put constraints at the enterprise level when they require cross-team coordination, strategy alignment, or organizational coherence. If ten teams need to release together, the release process is enterprise-level. If the org has one strategy, objectives are enterprise-level.
- Leave constraints at the team level when they only affect how the team works internally. If no other team needs to know, the team should decide.
- The mistake is treating team-level decisions as if they were enterprise-level decisions. Standardizing the stand-up format is treating a team-internal practice as if it required organizational coordination.
Ownership and cost-to-change are linked but not identical. A constraint can have high cost to change because it’s at the enterprise level — not because of any inherent complexity. Once management has standardized something, changing it requires management action. The cost is institutional, not technical.
This is why framework adoption is so often a one-way ratchet. Once a standard is in place, moving it back down to team ownership requires the same kind of institutional effort that putting it there required. The grid shows the state. The ownership layer shows who can change it. Both are needed to understand what a framework has done to an organization.
The Trade-offs: A Closer Look
It’s easy to assume that high cost and time to change is always bad, that mutability is good and fixedness is bad. The reality is more nuanced.
Items with high cost and time to change have real value. They create clarity. Everyone knows what to expect, which reduces decision fatigue. They enable coordination at scale, because multiple teams can synchronize around shared patterns. They provide organizational cover. “We do Scrum” is easier to defend than “we’ve designed a practice we think works.” And they offer stability under stress. When decisions are pre-made, teams don’t have to negotiate them during a crisis.
The downside is that standards can calcify. A good standard from three years ago can become a bad standard, and once something is in the bedrock zone, it’s expensive to move, even when the environment has shifted. “We do it because that’s the standard” replaces judgment with compliance. Standards become identity, and shedding them feels like losing part of who you are.
Items with low cost and time to change offer a different set of trade-offs. They enable adaptability, so practices can shift as conditions change. They support local optimization, where each team finds what works for their context. They stay current and avoid the trap of a good practice becoming a bad one.
The downside is inconsistency. Every team does it differently, which creates decision fatigue, coordination friction, and onboarding challenges. Measurement is harder when nothing stays still long enough to observe. And without a shared pattern, there’s no organizational cover for individual choices.
The Pros and Cons of Standards vs. Volatility
┌─────────────────────────────────────────────────────────────────────────────┐
│ │
│ HIGH COST/TIME TO CHANGE │
│ (Standards - bedrock, fixed, viscous) │
│ │
│ ┌─────────────────────────────────┐ ┌─────────────────────────────────┐│
│ │ PROS │ │ CONS ││
│ │ │ │ ││
│ │ • Clarity: everyone knows what │ │ • Inflexibility when the env- ││
│ │ to expect │ │ ironment changes ││
│ │ • Reduced decision fatigue │ │ • "We do it because that's the ││
│ │ (one less thing to negotiate) │ │ standard" replaces judgment ││
│ │ • Cross-team coordination is │ │ • Hard to shed: standards ││
│ │ easier with shared patterns │ │ become identity ││
│ │ • Comparability: you can │ │ • Sunk cost in training, ││
│ │ measure and improve │ │ tooling, culture ││
│ │ • Organizational cover: │ │ • Loses local adaptation: ││
│ │ reduces burden of justification│ │ one-size-fits-all ││
│ │ • Onboarding: faster for new │ │ • Standards calcify: a good ││
│ │ members │ │ standard from 3 years ago ││
│ │ • Stability under stress: │ │ becomes a bad standard ││
│ │ decisions are pre-made │ │ • Suppresses innovation: hard ││
│ │ │ │ to try something new ││
│ └─────────────────────────────────┘ └─────────────────────────────────┘│
│ │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ LOW COST/TIME TO CHANGE │
│ (Volatile - liquid, gaseous, variable) │
│ │
│ ┌─────────────────────────────────┐ ┌─────────────────────────────────┐│
│ │ PROS │ │ CONS ││
│ │ │ │ ││
│ │ • Adaptability: can change as │ │ • Inconsistency: every team ││
│ │ conditions shift │ │ does it differently ││
│ │ • Local optimization: each team │ │ • Decision fatigue: every ││
│ │ finds what works for them │ │ change requires deliberation ││
│ │ • Innovation: easy to try new │ │ • Hard to coordinate across ││
│ │ approaches │ │ teams ││
│ │ • Stays current: practices │ │ • Measurement is harder: ││
│ │ evolve with the environment │ │ nothing stays still long ││
│ │ • Avoids calcification: a bad │ │ enough to measure ││
│ │ practice can be changed │ │ • Lack of organizational cover: ││
│ │ │ │ harder to justify choices ││
│ │ │ │ • Inconsistency erodes trust: ││
│ │ │ │ "why does their team do it ││
│ │ │ │ differently than ours?" ││
│ └─────────────────────────────────┘ └─────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────────────────────┘These aren’t simply opposite trade-offs. They’re different kinds of costs and benefits. The high-cost side gives you efficiency and coordination but at the price of adaptability. The low-cost side gives you adaptability and local fit but at the price of consistency and reduced friction.
The worst position to be in is high cost and time to change for things that should be low — standards that calcified around practices that no longer fit. That’s the “we do it because that’s the standard” trap. The best position is being intentional about which side of the matrix each practice sits on, knowing that sometimes you want bedrock (shared values, coordination cadences, cross-team interfaces) and sometimes you want liquid (team practices that should adapt to local context).
A standard isn’t inherently good or bad. It becomes good when it’s chosen deliberately and reviewed periodically. It becomes bad when it becomes invisible — when no one remembers why it exists or whether it still fits.
Reading the Table Through Agile Values
The trade-offs in the table look different depending on which lens you read them through. In some domains (aviation, pharmaceutical manufacturing) you want a strong bias toward the high-cost side. Standards, predictability, and consistency are the whole point. The volatility side is a bug, not a feature.
In agile software development, the original values and principles bias the other way. The manifesto’s “individuals and interactions over processes and tools” and “responding to change over following a plan” sit firmly on the low-cost side of the grid. The twelve principles reinforce this, favoring local decision-making and team autonomy over organizational prescription.
Read through this lens, the “PROS” column of the low-cost/time side reads as the original intent of agile. The “PROS” column of the high-cost side (clarity, coordination, organizational cover) reads as the trade-offs the manifesto was pushing back against. If most of the constraints a team faces sit in the high-cost quadrant, the manifesto is no longer guiding their work. They’ve traded the values they claimed to adopt for the certainty of standards.
But this lens is not the only one. A healthcare organization, a financial trading platform, a government agency, a manufacturing floor: these may rightly bias toward the high-cost side. Safety, regulation, and auditability are real requirements.
The point of the table is to be deliberate about which side each constraint sits on, given the domain and the values you’re trying to honor.
The Direction of Movement Matters Too
The grid describes where a constraint sits. There’s another question the grid doesn’t directly answer: how did it get there, and can it ever move?
Even good standards carry risk if they can’t change.
A standard that delivers clarity, coordination, and organizational cover is genuinely useful. But a standard that can never be changed is a liability waiting to happen. The moment the environment shifts (new tooling, new customer expectations, new regulations, a change in team size or structure) that standard stops being a benefit and becomes an obstacle. If changing it requires the same institutional effort that putting it there required, the organization will live with a bad standard for a long time.
This is true even for genuinely good standards. The risk is that no one can tell when a standard has become bad, because the cost of questioning it is so high.
The riskiest position is starting in bedrock.
When a new practice or way of working is introduced as a standard — when it begins its life in the high-cost, long-time quadrant of the grid — it carries the most risk. There is no evidence that the practice works in this organization. There is no experience of what it looks like in different contexts. There is no feedback loop that would tell you, quickly, whether the practice is fit for purpose. The standard has all the weight of an institutional commitment and none of the evidence that the commitment is justified.
Good standards tend to emerge the other way: a new way of working starts small, gets tested by a single team, builds evidence, and only then gets promoted. The benefits of this organic promotion:
- The standard has evidence behind it. It wasn’t chosen because a consultant recommended it. It was chosen because it worked in practice.
- The organization knows what the standard actually requires. It has seen the practice in different contexts and has learned how to support it.
- The standard can be downgraded if it stops working. Because it started small and grew, the organization has experience in not treating it as a standard.
- The standard carries less risk of calcification. It was once a team-level decision that proved its value. That history makes it easier to revisit when conditions change.
The grid describes a state. The direction a constraint came from, and the direction it can still go, describes whether that state is sustainable. Constraints that moved up the grid through evidence are resilient. Constraints that were placed at the top from the start are fragile.
Summary
Mapping agile constraints onto a grid of cost to change and time to change gives us a way to see the real impact of an agile framework. Not as a list of practices to adopt, but as a transformation of the landscape an organization operates in.
A framework moves constraints. It changes their cost and time to change. It shifts the balance between global standardization and local adaptability. This shift has consequences, sometimes good, sometimes bad, often invisible until the organization needs to change something it can no longer change easily.
The grid shows the state of a constraint. State alone doesn’t tell the full story. Three dimensions together describe what a framework has done to an organization:
Where a constraint sits. The grid. Cost to change on one axis, time to change on the other. Standards and volatile practices occupy different quadrants, and the framework determines which side most of them land on.
Who controls it. Constraints in the high-cost zone are owned by management, the framework, or cross-team coordination. Constraints in the low-cost zone are owned by the team. The trap is treating team-internal decisions as if they were enterprise-level decisions, and removing the team’s ability to make local calls.
How it got there, and whether it can move. Standards introduced as standards carry the most risk. Institutional weight without evidence, no downgrade path, no experience of treating them as revisable. Standards that emerged from team-level practice and were promoted based on experience are more resilient. A constraint’s history is part of its fragility.
Four things worth taking away:
First, frameworks are not neutral. They change what is hard to change. You should know what trade you’re making.
Second, standards have value. Stability, clarity, coordination, and organizational cover are real benefits. The question is which things should be standardized and which should stay mutable.
Third, the worst outcome is a standard that calcified. A good practice from the past that became a bad practice in the present, and that no one can change because it’s now “the way we do things.” The antidote is to periodically examine the standards, to ask whether each one still fits its purpose, or whether it’s become bedrock when it should be liquid.
Fourth, the riskiest standards are those introduced as standards. New practices should start small, build evidence, and be promoted to standards only when the organization has seen them work. Standards placed at the top of the grid from the start have weight but no track record.
The point of mapping is to make these choices visible, so the people doing the work can have better conversations about how to work — and, when it makes sense, work without the framework at all.
The grid doesn’t tell you what to do. It tells you what your framework has done. The rest is judgment — but now the judgment has a map.
Malcolm Bastien
Enterprise Agile Coach
Enterprise Agile Coach helping leaders in Fintech, Banking, and HealthTech build fast flow through systems thinking and aligned autonomy, empowering teams to deliver high-performance results at scale.