Many organisations want to become more agile: faster to respond to customers, better at delivering value and more resilient to change. Adopting Scrum or Kanban in a few teams is relatively easy. Changing how a whole organisation plans, funds, structures and leads its work is much harder. That wider change is usually called an agile transformation. This guide explains what agile transformation means, why it often stalls, established models for leading change and a practical roadmap for leaders.
Key takeaways
- An agile transformation changes how an organisation works, not just which framework its teams use.
- Transformations often stall when teams change but leadership, structures, funding and measures do not.
- Change models such as Kotter's eight steps and ADKAR offer useful structure for leading change.
- Start small with a real pilot, learn from it, then expand.
- Treat the transformation itself as empirical: inspect progress regularly and adapt the approach.
What is an agile transformation?
An agile transformation is a deliberate effort to change how an organisation works so that it can respond to change and deliver value more effectively. It usually involves teams adopting frameworks such as Scrum or Kanban, but a real transformation goes further:
- Leadership: leaders shift from directing work to setting goals and enabling teams.
- Structure: teams are organised around products and customers rather than functions or projects.
- Funding: money follows long-lived products and teams rather than one-off projects.
- Planning: plans are updated regularly based on evidence.
- Measures: success is measured by outcomes and flow, not by adherence to a plan.
- Culture: experimentation, transparency and learning become normal.
For the leadership side of this change, see our complete agile leadership guide.
Why transformations stall
Agile transformations commonly run into the same problems:
- Teams change, leadership does not. Teams adopt Scrum, but decisions, priorities and approvals still work the old way.
- New words, old behaviour. Project managers are renamed Scrum Masters and plans are renamed backlogs, with no real change.
- A fixed, top-down rollout. A detailed transformation plan imposed on every team, ironically the opposite of agility.
- Structures that create dependencies. Teams cannot deliver anything without several others.
- Project funding. Teams are assembled and disbanded project by project, so they never mature.
- Measuring the wrong things. Counting how many teams "do Scrum" instead of whether customers are better off.
- Impatience. Real change takes years; declaring success or failure after a few months rarely helps.
Change models that help
Kotter's eight steps
John Kotter of Harvard Business School described eight steps for leading organisational change, first in a 1995 Harvard Business Review article and then in his 1996 book Leading Change:
- Establish a sense of urgency
- Form a powerful guiding coalition
- Create a vision
- Communicate the vision
- Empower others to act on the vision
- Plan for and create short-term wins
- Consolidate improvements and produce still more change
- Institutionalise new approaches in the culture
Kotter later updated his thinking in his book Accelerate, describing the steps as happening concurrently and continuously rather than strictly in sequence, which fits well with agile ways of working.
ADKAR
ADKAR, developed by Jeff Hiatt of Prosci, focuses on change at the level of individuals. It describes five outcomes people need to reach: Awareness of the need for change, Desire to support it, Knowledge of how to change, Ability to put it into practice and Reinforcement to sustain it. It is useful for understanding why particular people or groups are struggling with a change.
The Agile Fluency Model
Diana Larsen and James Shore described the Agile Fluency Model, which suggests teams develop agile capability in zones, such as focusing on value, delivering reliably and optimising for business results, each needing different investments. It reminds leaders that "being agile" is not one state, and that the right target depends on what the organisation needs.
A practical roadmap for leaders
1. Start with why
Be clear about what problem the transformation is solving: slow delivery, poor quality, frustrated customers, losing talent? A specific reason makes it easier to choose where to start and how to measure progress.
2. Change yourself first
Leaders' behaviour shapes everything else. Learn the frameworks, attend Sprint Reviews, delegate decisions and respond calmly to bad news. Teams watch what leaders do far more closely than what they announce.
3. Start with a real pilot
Choose one or a few teams working on something that matters, with leaders willing to support them. A pilot on unimportant work proves little. Give the pilot teams real authority, a clear Product Owner and protection from conflicting demands.
4. Build stable, cross-functional teams
Organise teams around products or customer journeys, with the skills to deliver end to end and small enough to stay nimble. Keep them together long enough to learn how to work well. See how to lead multiple Scrum Teams for scaling.
5. Remove organisational impediments
Pilot teams will quickly uncover policies and processes that slow them down: approvals, handoffs, reporting requirements. Fixing these is the leaders' job and often the most valuable part of the transformation.
6. Shift from projects to products
Where possible, fund long-lived product teams rather than temporary projects, and review funding regularly based on outcomes. This lets teams build knowledge and ownership over time.
7. Measure what matters
Track outcomes and flow: customer satisfaction, time from idea to delivery, quality, and team health. See Kanban metrics explained for flow measures.
8. Expand based on evidence
Spread what works to more teams, adapting it to each context. Let teams that have succeeded help others, rather than rolling out a single template.
9. Make it stick
Align hiring, performance management, career paths and funding with the new way of working. If these stay unchanged, old habits return.
Treat the transformation as empirical
An agile transformation should itself follow agile principles. Instead of a fixed multi-year plan, keep a backlog of transformation improvements, order it by value, work in short cycles and review progress regularly with the people affected. Scrum's pillars of transparency, inspection and adaptation apply to the change effort as much as to product work.
Roles in a transformation
- Executive sponsors: set direction, remove barriers and model the behaviours they want.
- Agile coaches: help teams and leaders learn new ways of working.
- Scrum Masters: help their teams and the wider organisation understand and use Scrum; the Scrum Guide includes leading, training and coaching Scrum adoption among their responsibilities.
- Product Owners: make product decisions with genuine authority.
- Managers: develop people, design teams and fix organisational problems.
See what does a Scrum Master do? and our complete Product Owner guide.
Measuring progress
Avoid measuring the transformation by activity, such as the number of people trained or teams using Scrum. Better signs of progress:
- Customers receive value sooner and more often
- Quality improves and fewer problems reach customers
- Teams make more decisions themselves
- Time from idea to delivery falls
- People report that it is easier to raise problems and try new ideas
- Organisational impediments raised by teams are resolved faster
A worked example: the first year
As an illustration, here is how a mid-sized organisation might approach its first year:
- Months 1 to 3: leaders agree the reason for change, which is slow delivery of customer features. They learn Scrum and Kanban basics, choose one product area for a pilot and form two cross-functional teams with a single Product Owner.
- Months 4 to 6: the pilot teams deliver working Increments every two weeks. They raise impediments, including a slow release approval process and people split across too many projects. Leaders fix the approval process and reduce multi-project assignments for pilot team members.
- Months 7 to 9: leaders measure time from idea to delivery for the pilot area and compare it with before. They share results, including what did not work, and choose two more product areas to start.
- Months 10 to 12: members of the pilot teams help the new teams get started. Leaders begin changing how budgets are allocated, moving some funding from projects to long-lived product teams.
At each stage, the leaders inspect progress and adapt the approach, rather than following a fixed plan.
Supporting middle managers
Middle managers often experience the biggest change. Tasks they used to own, such as assigning work and tracking progress, move to self-managing teams. Without support, they may feel their role is disappearing and resist the change. Leaders can help by explaining clearly how the manager role evolves, towards developing people, designing teams and removing impediments, by offering training and coaching, and by involving managers early in shaping the transformation.
Communicating during a transformation
- Explain the why repeatedly. People need to hear the reason for change many times, in different forms.
- Be honest about uncertainty. Admitting what is not yet known builds more trust than confident promises.
- Share real results. Invite people to Sprint Reviews of pilot teams so they see change for themselves.
- Listen as much as you speak. Create regular forums for questions and concerns.
Handling resistance
Resistance is normal and often useful: it can reveal genuine problems with the approach. Rather than overriding it, ask what people are worried about. Common concerns include losing status, losing control, not having the skills for new ways of working, or doubting that the change will last. Each needs a different response: clarity about roles, training, involvement in decisions, or visible leadership commitment. ADKAR can help identify which stage someone is struggling with.
Funding and budgeting in more depth
Traditional annual budgets fix spending a year in advance, often tied to detailed project plans. That clashes with agile work, where plans change as teams learn. The Beyond Budgeting movement, described by Jeremy Hope and Robin Fraser in their 2003 book Beyond Budgeting, argued for replacing rigid annual budgets with more adaptive approaches. Organisations adopting agile ways of working often:
- Fund long-lived product teams or value streams rather than individual projects
- Review funding regularly, for example quarterly, based on outcomes and evidence
- Use rolling forecasts instead of fixed annual plans
- Give Product Owners and product leaders more authority to decide how funds are used within their product
Funding changes are usually slow and involve finance teams, but they are one of the strongest signals that a transformation is real.
Common leadership mistakes
- Delegating the transformation entirely to coaches or a transformation office. Leaders must change too.
- Rolling out one template to every team. Different teams need different approaches.
- Demanding fast, visible results. Short-term wins matter, but deep change takes time.
- Ignoring middle managers. Their role changes most, and without support they may resist.
- Keeping old measures. Utilisation targets and fixed-scope deadlines undermine agile behaviour.
- Declaring victory too early. The first successful teams are the start, not the end.
Build your skills
Scrum Leader Plus covers coaching multiple teams, cross-team dependencies and organisational change. The exam is taken online on ExamVault by CertExpert with three attempts included, and the certificate and digital badge are valid for two years. See the certification page for current learning paths and prices. Our CAL 1 guide explains another widely known leadership certification.
Frequently asked questions
What is an agile transformation?
A deliberate effort to change how an organisation works, including leadership, structure, funding, planning and culture, so it can respond to change and deliver value more effectively.
How long does an agile transformation take?
It varies widely with the organisation's size and starting point. Meaningful change in a large organisation usually takes years, with improvements visible along the way.
Why do agile transformations fail?
Common reasons include leaders not changing their own behaviour, renaming roles without changing work, top-down rollouts, project-based funding and measuring activity instead of outcomes.
Where should an agile transformation start?
With a clear reason for change and a real pilot: one or a few teams working on something important, with strong leadership support.
What is Kotter's eight-step model?
John Kotter's approach to leading change, from creating urgency and a guiding coalition to anchoring new approaches in the culture.
What is ADKAR?
A change model developed by Jeff Hiatt of Prosci, describing five outcomes individuals need: Awareness, Desire, Knowledge, Ability and Reinforcement.
Do we need a scaling framework?
Not necessarily. Many organisations succeed with a few simple practices. Frameworks can help but should be adapted to your context.
What role do leaders play?
A central one: setting direction, changing their own behaviour, designing teams, removing impediments and aligning funding and measures with agile ways of working.