Overcoming resistance to Agile transformation in large Public Sector organisations

Changing how a large public sector organisation delivers digital services is rarely as simple as introducing Agile practices. The principles may be straightforward, but applying them within an established organisation brings a much more complex set of challenges.

Teams may be working within governance structures designed around long-term planning and formal approvals. Leaders may need confidence that delivery remains controlled. Practitioners may have experienced previous transformation programmes that promised significant change but delivered limited improvement. And, most importantly, users still need services that work effectively while the organisation changes how those services are designed and delivered.

Our consultancy supported a large public sector organisation through this type of transformation. The objective was not simply to introduce Agile terminology, ceremonies or tooling. It was to understand why teams were struggling to adopt new ways of working, identify where organisational and service constraints were getting in the way, and work with teams to establish a more user-centred and outcome-focused approach to delivery.

The work demonstrated an important principle that has shaped our approach across public sector programmes: resistance is often useful information. When people question a proposed change, the answer is not always to push harder. Sometimes the right response is to understand what the resistance is telling you.

Project Overview

The organisation was undertaking a significant programme of digital change across a complex public service environment. Multiple teams were involved in designing, developing and operating services, with different levels of Agile experience and different responsibilities across the wider service.

The organisation had already recognised the value of Agile delivery and wanted to move towards a more iterative approach. However, adopting the terminology and practices of Agile was not enough to change how work was actually being planned, governed and delivered.

Our consultancy was brought in to help understand the barriers and establish a practical approach to transformation that could work within the organisation’s existing environment.

The engagement brought together business analysis, service design, user research and delivery expertise. Rather than treating these disciplines as separate activities, we used them together to understand the relationship between organisational processes, technology, delivery teams and the people using the service.

The work took place over several stages, beginning with research and discovery before moving into service and delivery design, collaborative working with teams, and the development of practical recommendations and ways of working.

The focus throughout was deliberately pragmatic. The organisation did not need a theoretical Agile model. It needed an approach that could improve delivery while recognising the realities of public sector governance, accountability, legacy technology and organisational change.

“The consultancy team quickly became part of the service team rather than operating alongside it. They took the time to understand how we worked, built strong relationships across the programme and brought their expertise into the team without imposing a prescribed way of working.”

Service Owner

The Problem

The initial challenge appeared to be resistance to Agile.

Some teams were reluctant to change established processes. Some stakeholders were concerned that iterative delivery could reduce visibility or control. There were questions about how Agile approaches would work alongside formal governance and approval processes. Others were uncertain about what the change meant for their roles and responsibilities.

It would have been easy to characterise these issues as a cultural problem. That would also have been the wrong diagnosis.

Our work showed that much of the apparent resistance had rational foundations.

People were responding to uncertainty. They wanted to understand how decisions would be made, how priorities would be established, how progress would be demonstrated and how risks would be managed. Teams that had spent years working within established processes could not simply be asked to abandon them without understanding what would replace them.

There was also a wider service challenge. Delivery decisions were not always connected clearly enough to user needs and evidence. Work could become focused on producing outputs rather than understanding whether those outputs were improving the service.

This mattered because Agile transformation is ultimately not about changing the mechanics of delivery. It is about improving the organisation’s ability to identify problems, learn from evidence and deliver better outcomes.

If the transformation focused only on delivery teams, there was a risk that teams would adopt new ceremonies while the surrounding system remained unchanged.

The real question therefore became: what is preventing people from working in a more iterative, user-centred and outcome-focused way?

Research and Discovery

We began by listening.

User research and stakeholder engagement were central to the discovery phase. We spoke to people across the service, including delivery teams, operational colleagues, subject matter experts, governance stakeholders and decision-makers.

The purpose was not to ask whether people supported Agile. A question such as “Do you think Agile is working?” tends to produce opinions rather than useful evidence.

Instead, we explored how work actually happened.

We looked at how teams understood user needs, how problems entered the delivery process, how priorities were established, where decisions were made, how work moved between teams and where governance created delays or uncertainty.

We also explored people’s experiences of the existing service and delivery environment. What information did they have when making decisions? Where did they lack confidence? What happened when priorities changed? Where did teams have autonomy, and where did they depend on decisions elsewhere in the organisation?

This was where the combination of user research, service design and business analysis became particularly valuable.

User research helped us understand the experiences, behaviours and needs of people interacting with the service and the organisation. Service design allowed us to place those experiences within the wider service ecosystem. Business analysis helped us understand the processes, rules, dependencies and organisational constraints that shaped what teams could actually deliver.

We mapped the current service and delivery landscape to identify relationships between users, teams, processes, systems and governance.

The mapping exercise created a shared picture of the problem. It also changed the conversation.

Instead of discussing whether a particular team was “doing Agile properly”, stakeholders could see where the wider system was making effective delivery difficult.

For example, a team might have been expected to work iteratively but still needed to navigate a decision-making process designed around large batches of work. Another team might have been encouraged to prioritise according to user need while depending on upstream systems that could not change at the same pace.

These were not individual failings. They were system-level constraints.

That distinction was important.

By grounding the discussion in evidence, we could move away from assumptions about culture and towards specific problems that could be addressed.

“What stood out was the way they brought user research and service design into conversations that could otherwise have been dominated by delivery constraints. They helped us understand the service from the user’s perspective and gave the team practical tools and evidence to make better decisions.”

Head of Digital Delivery

Design Approach

The design phase focused on creating a practical model for change rather than imposing a standard Agile framework.

We worked collaboratively with the organisation to identify where changes to processes, responsibilities, governance and team interactions could create better conditions for delivery.

A key part of this work was maintaining a clear connection to users.

It is possible to make delivery considerably more efficient without necessarily making the service better. We therefore kept user needs and service outcomes visible when considering changes to ways of working.

Research findings were translated into journeys, service maps and clearly articulated user needs. These provided a common reference point for teams and stakeholders and helped connect strategic decisions to the experience of the people ultimately relying on the service.

[Insert user journey showing pain points and opportunities here]

We also worked through the delivery lifecycle to identify where evidence could be introduced earlier.

Rather than waiting until a product or service was substantially developed before validating assumptions, teams were encouraged to test ideas earlier and use research to inform prioritisation and design.

This included bringing business analysis and service design closer together. Business analysis helped establish what the organisation needed to achieve and understand the operational and business rules involved. Service design helped ensure that those requirements were considered in the context of the complete user journey and wider service.

The result was a more connected approach to delivery.

Teams could understand not only what they were building, but why it mattered, which user need it addressed and what evidence would demonstrate whether the change had worked.

Governance was treated in the same way.

Rather than positioning governance as something that Agile teams needed to overcome, we explored what information decision-makers genuinely needed to make confident decisions.

This allowed us to consider how governance could become more evidence-based and proportionate while retaining the appropriate levels of assurance.

Work was broken down into smaller, more understandable decisions. Evidence from research and delivery was brought into conversations earlier. Risks and assumptions became more visible.

This created a more constructive relationship between delivery and governance.

The transformation therefore became less about removing control and more about improving the quality and timing of information used to exercise control.

“They were very deliberate about knowledge transfer. We were not left dependent on the consultancy once the engagement ended. They worked alongside our people, explained the thinking behind the approaches they introduced and left us with the confidence and capability to continue applying them ourselves.”

Programme Lead

Outcome and Impact

The most important outcome was a shift in the nature of the conversation around Agile.

The organisation moved away from treating Agile as a set of practices that teams needed to adopt and towards understanding it as a way of improving how decisions were made and how services responded to evidence.

The discovery work gave stakeholders a clearer understanding of the organisational barriers affecting delivery. Instead of broad concerns about “culture” or “resistance”, the organisation had a more specific view of the processes, dependencies and governance mechanisms that needed attention.

Teams gained clearer connections between user needs, service outcomes and delivery priorities.

The introduction of user research and service design into the delivery process also helped create earlier opportunities to test assumptions. This reduced the risk of investing significant time and resources in solutions before there was sufficient evidence that they addressed the right problem.

[Insert before-and-after delivery process diagram here]

The work also improved the relationship between delivery teams and governance stakeholders. By making evidence, risks, assumptions and progress more visible, teams were better positioned to explain their decisions and stakeholders had better information with which to provide assurance.

Where quantitative measures were available, these included improvements such as [X% reduction in time from identified need to validated solution], [X% reduction in rework] and [X% improvement in delivery predictability]. The organisation also established [X] repeatable practices for incorporating user research and service design into delivery.

These metrics are important, but they do not tell the whole story.

The broader outcome was increased organisational confidence.

Teams had a clearer understanding of how to work iteratively within their environment. Leaders had greater visibility of why work was being prioritised and what evidence supported decisions. Most importantly, user needs became a more consistent part of the conversation.

The transformation had started to move beyond Agile adoption towards better digital delivery.

Reflection

One of the clearest lessons from the project was that resistance should not automatically be treated as something to eliminate.

In a large public sector organisation, resistance can contain valuable information. It can reveal where accountability is unclear, where governance does not fit the way teams are expected to work, where dependencies are creating friction or where people do not yet have enough evidence to support a proposed change.

Listening to that resistance made the transformation more effective.

It also reinforced the importance of user research and service design in organisational change. Understanding people is not only relevant when designing the external service. It is equally valuable when designing the conditions in which that service is delivered.

The strongest Agile transformations are therefore rarely about Agile alone.

They bring together user needs, organisational objectives, service design, business analysis, technology and delivery. They recognise the constraints of the public sector without allowing those constraints to become an excuse for standing still.

Our role was not to arrive with a predetermined model and ask the organisation to adopt it. It was to work alongside its teams, understand the system they were operating within, identify where change would create the greatest value and help them develop a way of working that could last.

That is ultimately what successful transformation should achieve: not simply a different process, but an organisation that is better able to learn, adapt and deliver services around the needs of the people who use them.