After two decades of helping government organizations adopt agile practices, I can tell you with confidence: the methodology isn't the hard part.
Scrum, Kanban, SAFe — these frameworks are well-documented, widely taught, and conceptually straightforward. Any team can learn the ceremonies, adopt the artifacts, and follow the prescribed cadence. And most do, at least initially.
The problem is that following agile practices and being agile are fundamentally different things.
The Cultural Challenge
Government organizations face unique cultural barriers to genuine agile adoption:
- Risk aversion — Public sector leaders are accountable to elected officials, oversight bodies, and the public. The cost of failure is political, not just financial.
- Hierarchical decision-making — Many government organizations have deeply embedded approval chains that conflict with agile's emphasis on team autonomy.
- Procurement constraints — Traditional government procurement favours fixed-scope, fixed-price contracts that are fundamentally at odds with iterative delivery.
- Workforce stability — Unlike the tech sector, government teams rarely have the luxury of hiring for agile experience. Transformation must happen with existing staff.
These aren't excuses — they're design constraints. And any agile transformation approach that doesn't account for them is setting up for failure.
What Actually Works
In our experience delivering agile transformation programs for organizations including BC Housing and several federal departments, we've identified three principles that separate successful transformations from performative ones:
1. Build Trust Before Building Process
Before introducing any agile framework, invest time in understanding the organization's culture, fears, and aspirations. Run workshops that let teams articulate what's working, what's broken, and what they wish could change.
This isn't a waste of time — it's the foundation everything else builds on. When people feel heard, they're more willing to try new approaches.
2. Start Where the Energy Is
Don't mandate agile adoption organization-wide. Find the teams that are already frustrated with the status quo — the ones who know something needs to change. Start there.
Early wins with willing teams create demonstrable proof points that make the broader case for transformation far more compelling than any executive mandate.
3. Adapt the Framework, Not Just the Team
Agile frameworks were designed for software development companies. Government isn't a software development company. That doesn't mean agile principles don't apply — it means the practices need to be adapted thoughtfully.
At BC Housing, we developed a modified delivery framework that preserved agile's core principles (iterative delivery, continuous feedback, team empowerment) while accommodating the organization's governance requirements, union agreements, and reporting obligations.
The Measurement Problem
Here's an uncomfortable truth: most agile transformation metrics are vanity metrics. Velocity, sprint burndown, story points delivered — these measure activity, not outcomes.
What government leaders actually need to know:
- Are we delivering value to citizens faster?
- Are teams more engaged and less burned out?
- Are we making better decisions with available information?
- Are we learning from failures and adapting?
These are harder to measure, but they're the only metrics that matter.
Looking Forward
The public sector's adoption of agile practices will continue to accelerate — not because it's trendy, but because the traditional waterfall approach to project delivery has a well-documented failure rate that no government can afford to sustain.
But sustainable agile transformation requires patience, cultural sensitivity, and a willingness to adapt methodology to context rather than the other way around. The organizations that get this right will be the ones that fundamentally change how government delivers value to the people it serves.