How to learn and adapt without losing strategic direction, operational coherence, or enterprise control

Agile change management combines concurrent initiatives with reflection, adaptation, and progressive development across the GLCM layers.

Organizations rarely implement change under stable conditions. Agile change management provides a way to work with that uncertainty.

Customer needs develop. Technology changes. Employees discover process limitations that were not visible during design. A new regulation alters priorities. One initiative depends on a decision being made by another. Operational teams learn what works only after they begin applying the change.

Traditional planning remains valuable, but leaders cannot always design the entire change path in advance.

Agile change management organizes change through shorter, evidence-informed learning and decision cycles while preserving strategic purpose, accountability, and operational responsibility.

Agility does not mean changing direction whenever someone raises a concern. It does not remove the need for governance, planning, or clear outcomes. It means shortening the distance between operational experience, organizational learning, and the next responsible decision.

This becomes especially important when an organization is managing several change initiatives at the same time. Local teams need enough flexibility to learn and adapt. The organization also needs to understand how those adaptations affect shared capacity, connected processes, customers, and enterprise priorities.

What agile change management means

Agile change management applies iterative thinking to organizational change.

Instead of treating an approved plan as a fixed sequence of activities, leaders:

work with shorter planning horizons;
make assumptions visible;
divide implementation into meaningful increments where possible;
involve affected employees and operational leaders;
gather evidence from actual use;
reflect on what is happening;
adjust the next step;
preserve clear decision authority.

The intended outcome remains visible, but the route can change as the organization learns.

Agile change management is particularly useful when:

the solution is still developing;
implementation conditions are uncertain;
stakeholder needs differ;
early operational experience can improve later decisions;
the change can be introduced in meaningful increments;
leaders can respond to evidence quickly enough to matter.

Many agile principles originated in software development. The Principles behind the Agile Manifesto, for example, emphasize customer value, collaboration, sustainable pace, adaptation, and regular reflection. These principles can inform organizational change, but applying them does not require turning every transformation into a software project.

Agile change management does not mean applying Scrum terminology to organizational change. It means using disciplined learning to determine the right next step.

Agility requires direction and governance

Agility is sometimes misunderstood as freedom from structure.

Without direction, local teams may adapt toward different outcomes. Without governance, unresolved dependencies can remain hidden. Without operational coordination, several reasonable local decisions can produce an unreasonable enterprise result.

Disciplined agility requires stable reference points.

These usually include:

strategic purpose;
intended organizational and customer outcomes;
accountability for results;
regulatory, ethical, safety, and financial constraints;
decision rights;
operational responsibilities;
relevant evidence;
connections with other initiatives.

Within those boundaries, teams may be able to adapt:

the sequence of activities;
communication and participation methods;
the design of training and support;
the size and timing of implementation increments;
workflows and tools;
local implementation practices;
assumptions guiding the next learning cycle.

The question is not whether everything should remain stable or everything should remain flexible.

The practical question is:

What must remain stable enough to provide direction, and what should remain flexible enough to respond to evidence?

The GLCM provides a structured but flexible change system

The GRIFFOX Layer Cake Model™ provides five connected layers for organizing a change initiative:

Foundation and Experience
Framework
Implementation
Recalibration
Goal

These layers are not rigid phases with identical durations. They identify areas requiring management attention.

A familiar process adjustment may need only a brief review of its organizational foundation. A new operating model may require an extended discovery period. A pilot may move rapidly into implementation. A regulated transformation may require formal approval and stable controls at several points.

Different workstreams may also be operating at different layers. One unit may be testing implementation while another is still clarifying its local framework.

The GLCM creates enough structure to maintain coherence while allowing teams to focus on the questions that matter now.

Three features make the model especially relevant to agile change management:

Reflection occurs at every layer.
Recalibration creates a deliberate decision point.
The model is recursive, allowing earlier assumptions or design choices to be revisited.

Agile change management at the Foundation and Experience Layer

The Foundation and Experience Layer examines the context into which the change will enter.

It includes:

organizational culture;
previous change experience;
existing capabilities;
current processes and systems;
readiness;
available capacity;
leadership conditions;
concurrent initiatives;
customer and employee experience;
internal and external constraints.

An agile approach does not treat the initial understanding of this foundation as complete. It begins with the best available picture and identifies what still needs to be learned.

Agile management question

What do we need to understand before committing to the next meaningful step?

Useful practices and artifacts

Depending on the initiative, teams may use:

a change hypothesis;
a discovery cycle;
an assumption backlog;
a current-state picture;
a change landscape;
an affected-unit map;
a capacity and dependency review;
baseline evidence;
customer or employee journey information;
initial risk hypotheses.

A change hypothesis might state:

If we simplify customer onboarding and give service teams access to consistent customer information, customers should need fewer avoidable contacts and employees should spend less time correcting incomplete cases.

The hypothesis makes the expected connection between action and outcome visible. It can then be tested and revised.

Reflection at the Foundation Layer

Reflection questions include:

Which assumptions are supported by evidence?
Which parts of the current-state picture remain uncertain?
What have previous initiatives taught us?
Which teams are already carrying significant change?
Are we overlooking a cultural or operational constraint?
Which customer or employee perspectives are missing?
Has the context changed since the initiative was proposed?

A short discovery sprint can support this work. Its purpose is not to produce false certainty within a fixed number of days. It is to reduce uncertainty enough to make the next decision responsibly.

Agile change management at the Framework Layer

The Framework Layer establishes how the initiative will proceed.

It can include:

principles and methods;
roles and responsibilities;
decision rights;
governance;
measures and evidence;
tools;
communication and participation;
training and support;
implementation boundaries;
review and escalation arrangements.

Agile change management does not require every future detail to be finalized before implementation. It requires a framework strong enough to support responsible action and flexible enough to improve as evidence develops.

Agile management question

What is the minimum workable structure required to begin responsibly?

“Minimum” does not mean incomplete governance, weak risk controls, or unclear accountability. It means avoiding unnecessary detail about decisions that cannot yet be made well.

Useful practices and artifacts

Possible artifacts include:

a prioritized change backlog;
a decision-rights map;
governance guardrails;
an initial outcome and measurement plan;
an implementation roadmap;
a pilot or experiment design;
an operational-impact map;
a communication and participation plan;
an escalation path;
a definition of what is ready for implementation.

A change backlog should contain more than communication and training activities. It may also include:

unresolved operational questions;
dependencies;
capability requirements;
customer concerns;
process changes;
decisions;
risks;
evidence needs;
stabilization work.

Reflection at the Framework Layer

Teams should ask:

Does the framework support the intended outcome?
Are decision rights sufficiently clear?
Can local teams adapt within understandable boundaries?
Are governance requirements proportionate to the risk?
Are the selected measures relevant to the decisions ahead?
Does the framework connect project work with operational ownership?
Which parts of the approach should be tested before wider implementation?
Are we creating unnecessary administrative work?

The PMI Agile Practice Guide similarly presents agility as framework-neutral and encourages fit-for-purpose choices across predictive, agile, and hybrid approaches.

Agile change management at the Implementation Layer

The Implementation Layer is where the organization begins working differently.

Plans meet actual systems, workloads, customer needs, established routines, and organizational relationships. This is where hidden assumptions become visible.

An agile approach uses meaningful increments, pilots, experiments, or staged implementation where these are operationally responsible.

Agile management question

What can we implement and observe safely enough to improve the next decision?

The increment should be meaningful. Completing a communication activity may demonstrate that information was distributed. It does not necessarily reveal whether employees understand the change or whether the new process works.

Useful increments might include:

testing a workflow with one customer group;
piloting a process in one location;
applying a new decision rule to a defined case type;
introducing one system function before a wider release;
testing a management routine with selected teams;
rehearsing exception handling before launch.

Useful practices and artifacts

Possible artifacts include:

an implementation-cycle or sprint goal;
a prioritized work board;
a pilot plan;
scenario-based practice;
an operational demonstration;
a feedback record;
an issue and dependency log;
an evidence summary;
an updated change backlog;
a learning journal.

The U.S. Government Accountability Office’s Agile Assessment Guide describes incremental development and continuous evaluation in the context of software delivery. Organizational change can apply a similar learning logic while considering the wider effects on people, culture, operations, and governance.

Reflection at the Implementation Layer

Reflection should examine:

What did we expect to happen?
What actually happened?
What worked under real operating conditions?
Where did employees create workarounds?
Which customer or operational consequences appeared?
What surprised us?
Which problem can be resolved locally?
Which issue involves another Change Unit?
Which finding challenges the framework or foundation?
What should we do next?

This reflection may occur within a sprint review, retrospective, operational review, team conversation, or another suitable format.

Agile change management at the Recalibration Layer

Reflection happens throughout the GLCM. The Recalibration Layer has a more specific purpose.

It integrates evidence and turns learning into a deliberate decision.

A retrospective may identify a problem. Recalibration determines what the organization will do about it.

Agile management question

What does the evidence require us to continue, change, pause, or reconsider?

Possible decisions include:

Keep the course
Adjust within the current layer
Expand the next increment
Narrow the next increment
Change the sequence
Provide additional support
Wait consciously
Return to an earlier layer
Escalate an enterprise decision

Useful practices and artifacts

Possible artifacts include:

retrospective findings;
a qualified signal picture;
updated assumptions;
a decision record;
revised priorities;
a capacity review;
an updated risk and dependency picture;
a recommendation for the next cycle.

Within the GLCM, a signal is information interpreted in relation to a relevant management question, context, baseline, objective, risk, or decision.

A signal picture brings related signals together. It should show patterns, contradictions, uncertainty, and material exceptions rather than reducing everything to one average or status color.

Reflection at the Recalibration Layer

Leaders should ask:

Are we measuring what matters?
Are we combining operational data with lived experience?
Are we confusing completed activity with progress?
Are we responding to one incident or a recurring pattern?
Which assumptions remain valid?
Has the level of risk changed?
Can the current team make the required decision?
What requires cross-unit or enterprise authority?
What is the next responsible step?

Recalibration keeps agility connected to accountability. It prevents teams from changing direction informally without explaining what they learned or why the adjustment is justified.

Agile change management at the Goal Layer

The Goal Layer concerns the intended outcome, its operational integration, and its sustainability.

Agile change management should not end when a pilot works, a sprint closes, or a project delivers its scope.

Leaders need to determine whether:

the intended outcome occurred;
the change created meaningful value;
operational ownership is established;
employees can sustain the new way of working;
customers experience the intended improvement;
benefits remain visible over time;
new risks or burdens appeared elsewhere;
the result should be retained, expanded, corrected, or retired.

Agile management question

Did the change create sustainable value, and what has the organization learned?

Useful practices and artifacts

Possible artifacts include:

an outcome review;
benefits evidence;
an operational-ownership record;
a sustainability assessment;
customer and employee evidence;
lessons for future initiatives;
an updated organizational foundation.

Reflection at the Goal Layer

Questions include:

Did we achieve the intended outcome?
Which results were different from what we expected?
Can operations sustain the change without temporary project support?
Who carries ongoing responsibility?
Should the approach be expanded?
What should be corrected or discontinued?
Which capabilities, dependencies, or risks now exist?
What must become part of the Foundation and Experience Layer for the next initiative?

This connects agile change management with change evaluation after project completion.

Reflection cycles occur at every layer

Reflection should not be delayed until formal implementation reviews.

Each GLCM layer uses reflection for a different purpose:

GLCM layer	Purpose of reflection
Foundation and Experience	Test assumptions about context, capacity, readiness, culture, and previous experience
Framework	Review whether methods, roles, measures, governance, and decision rights remain workable
Implementation	Compare the intended change with what employees, operations, and customers experience
Recalibration	Integrate evidence and make a deliberate course decision
Goal	Evaluate outcomes, sustainability, benefits, and lessons for the next foundation

The GOV.UK Service Manual describes retrospectives as regular opportunities to discuss what is and is not working and to assign actions. That practical structure can be used beyond software teams.

A reflection cycle might ask:

What did we intend?
What happened?
What evidence do we have?
What does it mean?
What should we continue?
What should we adjust?
Who has the authority to decide?
What will we observe next?

Reflection becomes useful when it changes understanding, action, or a decision.

How sprints and agile artifacts support the GLCM

A sprint is a timebox. A GLCM layer identifies the management questions requiring attention.

They are connected, but they are not interchangeable.

A sprint can concentrate work within one layer. It can also include limited activities from several layers when that serves a coherent learning objective.

For example, a four-week pilot might include:

confirming one Foundation assumption;
applying part of the Framework;
implementing a limited process change;
observing operational effects;
making a Recalibration decision.

The sprint should have a meaningful purpose.

A useful organizational-change sprint includes:

a clear management or learning question;
an identifiable operational context;
a meaningful increment;
relevant evidence;
defined decision boundaries;
scheduled reflection;
a decision about what happens next.

Without these elements, shorter cycles may simply create faster activity.

Agile artifacts should also earn their place. A backlog, board, review, or retrospective is useful when it improves visibility, cooperation, learning, or decisions. It becomes waste when teams maintain it only to demonstrate that they are working in an agile way.

The recursive structure supports adaptation

The GLCM is recursive rather than strictly linear.

New evidence can justify movement within or between layers.

For example:

An implementation problem may reveal an incomplete Framework.
Conflicting responsibilities may require a new decision-rights design.
Employee reactions may challenge an assumption in the Foundation and Experience Layer.
Customer evidence may require reconsidering the intended Goal.
A capacity conflict may require a different implementation sequence.
A completed outcome may create new capabilities and constraints for the next initiative.

Returning to an earlier layer does not mean that the entire initiative has failed. It means the organization has learned that an earlier assumption or design decision requires attention.

Recursion allows leaders to correct the relevant part of the change without automatically restarting everything.

It also connects one initiative with the next. Every achieved outcome changes the organization. New capabilities, experiences, systems, dependencies, trust, fatigue, and lessons become part of the Foundation and Experience Layer for future change.

Focus on the right next step

Agile change management does not require leaders to know the entire future path. It requires enough clarity to choose the next responsible step.

Within a layer, teams may decide to:

gather more evidence;
test an assumption;
clarify a responsibility;
simplify an artifact;
involve an additional perspective;
adjust a workflow;
change a communication approach;
reduce the size of an increment;
increase support;
delay an activity;
prepare an escalation.

This flexibility is valuable because different problems require different responses.

A team experiencing unclear responsibilities may need a Framework decision. A team facing an unworkable process may need an Implementation adjustment. An organization discovering that the original outcome is no longer relevant may need to revisit the Goal.

Agility improves when teams can identify which layer contains the question they need to resolve.

Operational Integration across Change Units

A local team can adapt effectively and still create problems elsewhere.

Consider three initiatives:

A customer-service system rollout
A process redesign
An organizational restructuring

Each initiative works in short cycles and responds to local feedback. All three depend on the same operational managers, subject-matter experts, and training capacity.

The system team changes its release date. The process team adds new workshops. The restructuring team brings forward role announcements.

Each decision may make sense within its initiative. Together, they may overload the affected departments and create inconsistent expectations.

This is why agile change management across concurrent initiatives requires Operational Integration.

Operational Integration makes visible:

shared capacity;
cross-unit dependencies;
sequencing conflicts;
cumulative customer effects;
competing operational demands;
unresolved decision queues;
periods when teams need stability.

A Change Unit retains responsibility for implementation within its context. Operational Integration does not remove local autonomy. It connects local decisions where consequences cross boundaries.

The required degree of integration should remain proportionate.

A contained initiative affecting one team may require little enterprise coordination. A transformation spanning several processes, locations, technologies, or customer groups needs a wider operational picture.

For a deeper explanation, see Operational Integration in Change Management.

Local agility and enterprise agility are different

Agility operates at more than one level.

Initiative learning cycle

A team:

identifies a question;
plans a meaningful increment;
implements;
observes;
reflects;
adjusts.

Enterprise learning cycle

The organization:

collects contextual signals from initiatives and Change Units;
connects patterns across operations;
evaluates capacity, dependencies, risk, and strategic alignment;
prepares decision options;
makes enterprise decisions;
returns direction to projects and operational units.

The Change Office can help integrate signals, identify recurring patterns, and prepare options. It does not replace enterprise authority.

Enterprise Change Governance decides questions involving organizational priorities, shared capacity, sequencing, major risk, and strategic direction.

For more about the supporting role, see The Change Office: Connecting Change Activity with Enterprise Decisions.

Agile teams need timely decisions. If evidence reaches leadership only after several reporting cycles, the organization may have local agility without enterprise agility.

Managing concurrent initiatives requires more than an enterprise backlog

An enterprise backlog can improve visibility, but a list of projects is not enough.

Leaders also need to understand:

which Change Units are affected;
when demand reaches them;
which resources are shared;
which dependencies can delay several initiatives;
where local decisions create wider consequences;
which customer groups experience multiple changes;
which enterprise decisions are waiting;
when operations require stability.

This connects agile change management with change capacity and change saturation.

The question is not simply, “How many projects are active?”

The more useful questions are:

Where is change demand concentrated?
Which work must happen at the same time?
Which activities can be resequenced?
Where are several projects relying on the same assumption?
What can teams decide locally?
Which collision requires an enterprise decision?

What should remain stable and what may adapt

A practical agile change approach makes this distinction explicit.

Keep stable enough to guide the work

Strategic purpose
Intended outcome
Accountability
Ethical and regulatory boundaries
Safety requirements
Essential financial controls
Decision authority
Definition of value
Enterprise priorities

Allow adaptation as evidence develops

Implementation sequence
Size of increments
Communication formats
Participation methods
Training design
Local workflows
Support mechanisms
Experiment design
Planning assumptions
Evidence collection methods

Even stable elements may eventually need reconsideration. However, changing them usually requires a higher level of authority and stronger evidence than adjusting a local implementation practice.

When agile change management fits

Agile change management is particularly useful when:

the solution must develop through use;
implementation can be divided into safe increments;
teams can gather meaningful feedback;
operational conditions are uncertain;
stakeholder needs are still developing;
leaders can make timely decisions;
local adaptation can occur within clear boundaries;
the cost of learning early is lower than the cost of discovering problems after full implementation.

When to slow down or use a hybrid approach

A slower or more predictive approach may be appropriate when:

requirements are tightly prescribed;
partial implementation would create unacceptable risk;
a change is difficult to reverse;
safety or regulatory approval requires a defined sequence;
several technical components must become operational together;
evidence cannot be interpreted within a short cycle;
teams do not have the authority or support needed to act on learning.

A hybrid approach is often practical.

An organization may keep regulatory controls, essential milestones, architectural decisions, and safety requirements stable while using shorter cycles for:

employee engagement;
training;
communication;
workflow design;
customer testing;
local implementation;
support;
reflection.

The purpose is to choose the approach that fits the work and its consequences.

Questions for leaders

Leaders using agile change management across concurrent initiatives should ask:

What outcome must remain visible?
What must remain stable, and what may adapt?
Which GLCM layer contains the question we need to resolve?
What assumption are we testing?
What is the smallest meaningful next step?
What evidence will that step produce?
Are reflection cycles occurring at every relevant layer?
Does each sprint have a clear learning or management question?
Are agile artifacts improving decisions or creating administration?
Which Change Units will experience the next increment?
What other initiatives affect those units?
Which dependencies or capacity pressures cross boundaries?
What can the team decide locally?
What requires the Change Office or another coordinating function?
What requires Enterprise Change Governance?
How quickly can evidence reach the person with authority to act?
Are we measuring outcomes or only completed activity?
Does new evidence require adjustment within the current layer?
Should we wait consciously or return to an earlier layer?
What will this initiative add to the foundation for the next change?

Structured learning without enterprise fragmentation

Agile change management helps organizations work responsibly when the complete path cannot be known in advance.

The GLCM strengthens that approach by giving agility a structured home at every layer:

Foundation and Experience supports discovery and assumption testing.
Framework establishes adaptable methods and clear boundaries.
Implementation creates operational learning.
Recalibration turns evidence into deliberate decisions.
Goal connects change with outcomes, benefits, and sustainability.

Reflection cycles keep learning active throughout. Sprints and agile artifacts can make the work visible. The recursive structure allows leaders to revisit assumptions and focus on the right next step.

Operational Integration connects local adaptation across Change Units. The Change Office integrates patterns and prepares options. Enterprise Change Governance protects strategic direction, capacity, and accountability.

Together, these elements allow teams to learn and adapt without turning concurrent change initiatives into disconnected islands.

That is the purpose of agile change management: disciplined adaptation that remains connected to people, operations, strategy, and enterprise responsibility.

About the Author

Harald Lavric is the founder of GRIFFOX Consulting and creator of the GRIFFOX Layer Cake Model™. His work focuses on the connections among leadership, strategy, organizational change, operational responsibility, and enterprise decision-making. Drawing on more than three decades of experience in the German health-insurance system and work across public- and private-sector environments, he helps leaders make overlapping change more coherent and workable.