Why Agile Matters in the Public Sector
For decades, government IT projects have followed the same pattern: years of planning, fixed budgets, rigid scopes — and systems that were obsolete by launch day. These waterfall-era structures were built for certainty. The problem is: citizen needs aren’t certain anymore. Technology evolves monthly. Policy shifts quarterly. Expectations change daily. To keep pace, governments must move from managing projects to nurturing products — living services that evolve continuously. It’s not just about methodology; it’s about mindset. Agile allows governments to learn faster, reduce risk, and deliver real value sooner — instead of betting everything on a final launch two years away.
Waterfall can be Agile too.
Sidestepping the subject of this article (will develop in a later one): Agile Beyond Methodologies – Why Even Waterfall Can Be Agile
There’s a common misconception in the project management community that Agile equals Scrum or Kanban. This purist view mistakes tools for philosophy. Scrum and Kanban are frameworks — concrete methodologies that offer structure for planning, executing, and improving work. Agile, by contrast, is not a framework at all; it’s a set of guiding principles expressed in the Agile Manifesto. These principles emphasize adaptability, collaboration, continuous improvement, and delivering value early and often.
Scrum and Kanban: Agile in Form, Not by Default
Scrum and Kanban are often identified with Agile because they operationalize its values — iterative progress, frequent feedback loops, and flexibility in scope. But simply using Scrum or Kanban does not automatically make a team Agile. Teams can perform sprints mechanically, fill out burn-down charts, and hold retrospectives without ever embodying the mindset of learning, adaptability, and user-centric value. In such cases, the process may be Scrum-shaped, but the spirit of Agile is absent.
Waterfall: A Methodology, Not an Opposite
Waterfall, on the other hand, is traditionally seen as the antithesis of Agile — linear, rigid, and sequential. Requirements are gathered, then design, development, testing, and delivery happen in distinct, non-overlapping phases. However, Waterfall is simply a project management methodology, not an ideology. It can be used with varying degrees of flexibility. The rigidity often associated with Waterfall is a matter of execution and mindset, not of the framework itself.
When Waterfall Can Be Agile
A Waterfall project can, in fact, be Agile in spirit. If a team working in a sequential environment:
- welcomes change requests when new insights emerge,
- maintains continuous communication with stakeholders,
- prioritizes customer outcomes over process compliance, and
- seeks to learn and improve between project phases,
then it is practicing Agile principles — even if it doesn’t iterate in sprints or maintain a Kanban board. For example, a defense or construction project might be required to follow a structured sequence of approvals and dependencies. Yet, within that structure, the team can still adopt Agile behaviors: incremental validation, early prototyping, feedback integration, and transparent collaboration.
Agility as a Mindset
Agility is therefore a mindset, not a method. It’s about how teams think, respond, and collaborate — not which ceremonies or artifacts they use. The real test of agility is not whether a project runs in two-week sprints, but whether it:
- adapts based on evidence,
- listens to the user continuously,
- improves how it works over time, and
- delivers meaningful outcomes, not just deliverables.
From this perspective, Waterfall can be Agile, and Scrum can fail to be. The distinction lies in attitude, not architecture.
Scrum and Kanban are valuable instruments of Agile delivery — but they are not Agile itself. Agile is a philosophy of responsiveness and value delivery, not a recipe book. Waterfall can also be Agile when managed with openness, learning, and user-centered intent. Ultimately, agility is not what you do — it’s how you think.
Back to Product-Oriented IT Delivery in Government: From Big-Bang Projects to Iterative Products
In the old world, the question was, “When will the project be done?”
In the new one, the better question is, “What did users learn this week?”
I’ve led teams on both sides of that divide. One of my earliest projects followed a classic Waterfall model — hundreds of pages of requirements, 18-month delivery plan, no user testing until the end. We hit every milestone, but by go-live, half the requirements were outdated and the other half misunderstood.
A few years later, on a digital learning modernization project, we flipped the model: start small, test often, release continuously. Within six weeks, we had a working prototype in the hands of users. Their feedback changed our priorities completely — we discovered pain points that no requirements document could have predicted.
That’s the core advantage of Agile in the public sector: you expose risk early and adjust before it becomes expensive.
Empowered, Cross-Functional Teams
Agile only works when you trust the people closest to the work. In traditional hierarchies, decisions climb ladders; in product teams, they happen where insight lives — inside multidisciplinary squads that include product, design, engineering, and policy expertise.
It’s important having the right mix of skills and authority from the start. As a Product and Project Manager, I’ve seen that success depends less on the framework (Scrum, Kanban, or DABL) and more on how much autonomy teams are given to experiment and decide. Empowered teams release smaller, safer increments. They learn continuously. And they build ownership — not compliance — into delivery.
Procurement Meets Product Thinking
One of the biggest challenges to Agile in government isn’t technology — it’s procurement. Traditional contracts assume fixed deliverables, not iterative learning. But real innovation needs room to change course. Product-oriented delivery reframes procurement from buying a system to investing in an outcome. It rewards progress toward citizen value, not adherence to the original statement of work.
What if? What if in one engagement, you work with procurement to fund sprints instead of monolithic milestones. That shift alone improves transparency, builds trust, and give executives a clear view of progress every two weeks. When the team discovers new opportunities, you could pivot without renegotiating an entire contract. The government still got accountability — but this time, it is tied to impact, not paperwork.
Data, Feedback, and Continuous Improvement
Agile thrives on evidence. Every iteration is an experiment: you build, measure, learn, and adapt. Government teams often fear releasing early because they assume citizens expect perfection. In reality, citizens just expect responsiveness. They want to see that their feedback leads to change. That’s why continuous delivery — small, safe updates — builds trust. It signals that the service is alive, maintained, and improving. Each release is a conversation with the public. Each improvement, however small, is proof that government is listening.
Servant Leadership in Agile Delivery
Agile isn’t just a team practice; it’s a leadership philosophy.
As a servant leader, my job is to remove barriers, not issue orders.
That means protecting teams from unnecessary bureaucracy, ensuring decision-makers are accessible, and championing a culture where experimentation is safe. When people aren’t afraid to surface risks or propose changes, innovation follows naturally.
Key Takeaways
- Think in products, not projects. Services evolve; success is continuous, not finite.
- Deliver smaller, sooner. Every iteration reduces risk and builds evidence.
- Empower multidisciplinary teams. Decisions made closest to users are the best ones.
- Rethink procurement. Fund outcomes, not deliverables.
- Lead through service. Remove blockers, celebrate learning, and trust your teams.
Final Thoughts
Agile and product-oriented delivery aren’t buzzwords — they’re how government regains relevance in a fast-changing world. When we replace rigid plans with continuous learning, teams stop guessing and start delivering. When we empower them to iterate in the open, citizens stop waiting and start trusting.
That’s the future of digital government: adaptive, transparent, and relentlessly focused on real outcomes.