Can Agile Work in Local Government?

Agile has been part of the local government technology conversation for more than a decade. Most councils have tried it in some form. Stand-ups, sprints, backlogs, product owners. Some teams report success. Others quietly move on after a few painful attempts.

This raises a question that is rarely asked directly.

Can Agile actually work in local government, or is it fundamentally misaligned with how councils operate?

The honest answer is that Agile can work in local government, but only under conditions that are difficult, and in many councils unlikely, to create. Understanding why requires stepping back from frameworks and ceremonies and looking at what Agile really is, what it assumes about organisations, and how those assumptions compare with the operating reality of councils.

A brief history of Agile and what it actually is

Agile did not begin as a transformation program or a delivery framework. It emerged in the late 1990s as a reaction against heavyweight, plan-driven software delivery approaches that were producing systems that were technically correct but no longer relevant by the time they were delivered.

Practitioners began experimenting with shorter delivery cycles, closer collaboration with users, and the ability to adapt as new information emerged. These approaches shared an intent rather than a common process.

In 2001, this thinking was captured in a short set of values and principles that became known as Agile. Importantly, Agile was never intended to be prescriptive. It described a way of working under uncertainty, not a method to be implemented.

At its core, Agile is about:

• Learning early rather than discovering problems late

• Delivering value incrementally rather than all at once

• Adapting plans as understanding improves rather than defending early assumptions

• Making work, priorities, and constraints visible

• Involving the customer early and often.

Agile was conceived for small, stable teams with fast decision-making, close access to users, and a high degree of autonomy. As Agile moved into large organisations, and later into government, many of those assumptions stopped holding.

That is where the friction begins.

The organisational culture Agile depends on

Agile is often treated as a delivery method. In practice, it is heavily dependent on organisational culture. Without the right cultural conditions, Agile tends to degrade into ceremony without impact.

For Agile to work as intended, organisations need:

• A learning-oriented mindset that values feedback over certainty

• Psychological safety so teams surface problems early

• Meaningful autonomy within clear boundaries

• Leadership that enables delivery rather than controls it

• Cross-functional collaboration rather than silo optimisation

• Tolerance for ambiguity and evolving plans

• Transparency of work, priorities, and constraints

• Stable teams with protected delivery capacity

• Respect for real constraints rather than pretending they do not exist

None of these are trivial. All of them cut across how many councils are structured, governed, and led.

This does not mean councils are poorly run. It means Agile assumes cultural conditions that rarely arise organically in bureaucratic environments.

Cultural prerequisites versus local government operating conditions

The table below contrasts the cultural conditions Agile depends on with typical local government realities, and highlights what would need to change for Agile to be viable.

Cultural prerequisite for Agile	Typical local government operating condition	What would need to change
Learning over certainty	Strong expectation of predictability, control, and foresight	Acceptance at an Executive and Council level of variable scope, budget and/or schedule.
Psychological safety	High public, political, and audit scrutiny	Leaders must be prepared to protect teams from blame and emphasis learning and benefits of Agile.
Team autonomy	Hierarchical delegations and role rigidity	Autonomy must be explicitly delegated within clear boundaries
Enabling leadership	Accountability reinforces command-and-control instincts	Leaders act as constraint managers and unblockers
Cross-functional collaboration	Strong functional silos and professional boundaries	Temporary cross-functional delivery groups with clear mandates. Willingness to backfill SMEs during projects.
Tolerance for ambiguity	Legislative, policy, and political certainty expected	Ambiguity allowed within stages, not across entire programs. Acceptance of variable scope, budget and/or schedule.
Transparency of work	Transparency is formal, retrospective, and document-heavy	Lightweight, real-time visibility that still supports audit.
Stable teams	BAU, incidents, and escalations interrupt delivery	Explicitly protected delivery capacity
Respect for constraints	Constraints often implicit or political	Constraints treated as explicit planning inputs

This table alone explains why Agile feels unnatural in many councils. The gap is not skills or intent. It is structural and cultural.

The Agile principles versus council reality

Agile is often taught through its twelve principles. When examined carefully, most are not wrong for local government. But many assume operating conditions that councils do not have.

The table below assesses how the Agile principles align with the council environment and what adaptation would be required.

Agile principal theme	Typical local government operating conditions	What would need to change for this principle to hold
Early and continuous delivery of value	There are often an expectation of project completeness and an unwillingness to accept MVP.	Trust must be built between IT and the business that Minimum Viable Product does not turn into Maximum Viable Product.
Welcoming change, even late	Change constrained by approvals, delegations, budgets, and political sensitivity	Change must be time-boxed with explicit rules for what can evolve without re-approval
Frequent delivery	Releases constrained by vendors, legacy platforms, assurance, and change freezes	More investment in the deployment process. Ensure IT teams have enough resources to increase delivery cadence.
Daily collaboration with the business	Business SMEs are scarce and rarely empowered to decide alone	Replace Agile single product owner models with structured decision forums and clear and efficient escalation pathways.
Trusting motivated individuals	Risk aversion reinforced by public scrutiny encourages command and control structures.	Leaders must explicitly delegate authority and protect teams from blame.
Face-to-face communication	Hybrid work and record-keeping requirements dominate	Combine direct communication with lightweight, auditable decision records
Working solutions as progress measure	Compliance, security, accessibility, and records obligations are mandatory	Expand the definition of “working” to include public-sector assurance
Sustainable pace	BAU and urgent escalations interrupt delivery	Leadership must actively protect delivery capacity.
Technical excellence	Legacy platforms dominate and architecture is underfunded	Treat architecture and integration as delivery enablers, not overhead. Increase funding to allow a move away from legacy platforms.
Simplicity	Mandatory requirements and stakeholder additions are common. A tendency of stakeholders to see their own needs over the need of the whole business.	Explicitly distinguish mandatory obligations from discretionary scope. Structured decision forums and clear and efficient escalation pathways.
Self-organising teams	Authority is hierarchical and role-based	Limit self-organisation to sequencing, design, and problem-solving within governance
Regular reflection and adaptation	Processes are standardised and difficult to change	Focus retrospectives on small, governance-compatible improvements

What councils would need to change to make Agile work

Making Agile work in local government is not a training exercise. It is an organisational change program.

For Agile to succeed, councils would need to:

• Reframe Agile as a risk management and learning approach

• Redesign governance to allow iteration within approved boundaries

• Lock in funding early while allowing scope and schedule to evolve

• Make decision authority explicit and time-bound

• Make escalation pathways strong, clear and decisive

• Redesign Agile product owner concepts to reflect distributed authority

• Adapt procurement and vendor contracts to allow flexibility

• Protect delivery capacity from operational interruption

• Actively build psychological safety

• Redefine what “working” means in a public-sector context

• Enable cross-functional collaboration despite silos

• Invest in architectural and integration enablers

• Make constraints visible and legitimate rather than hidden

This is a significant body of work. In many councils, it would require changes to leadership behaviour, governance design, funding models, procurement practices, and organisational culture.

It is entirely reasonable to conclude that many councils will not be able, or willing, to make these changes at scale.

Conclusion

After more than a decade of experimentation, the evidence suggests that Agile is neither a silver bullet nor a failure. It is a context-dependent tool.

For some councils, Agile may be the right answer in limited, well-defined contexts. For many others, hybrid, incremental, or adaptive approaches may deliver better outcomes with far less organisational strain.

The real leadership challenge is not becoming Agile. It is designing delivery approaches that respect the realities of local government while still improving outcomes for communities.

That starts with workflow, governance, and decision-making far more than it starts with methodology.

Whether you can make Agile work for you or not it's worth remembering that you don't need scrums, Jira or story points to get the benefit of improved customer involvement, regular demos and releases, and a more empowering culture.