Reading Agile Adoption in Government Through a Practitioner's Lens

Recently, my good friend and fellow Agile practitioner JoAnna Kelly recommended Adopting Agile in State and Local Governments by Sukumar Ganapati, published by the IBM Center for The Business of Government [link]. I found it both insightful and thought-provoking.

The paper explores many of the challenges government organizations face when attempting to adopt Agile practices, including organizational culture, leadership support, governance, and procurement. Much of it aligned closely with experiences I have had throughout my career in local government technology.

Rather than reviewing the paper itself, I'd like to use it as a starting point for a broader discussion about what Agile adoption looks like inside government organizations.

Themes That Resonated With Me

One of the strongest observations in the paper is that Agile adoption is primarily a cultural transformation rather than a technical one. This may seem obvious, but it is a lesson many organizations continue to learn the hard way.

When government agencies decide to "go Agile," the initial focus is often on ceremonies and tools. Teams begin holding daily standups. Backlogs are created. Sprint planning sessions are scheduled. New project management platforms are introduced.

These activities are useful, but they are not the transformation itself.

The real challenge is changing how decisions are made, how work is prioritized, how risk is managed, and how much authority teams are trusted to exercise.

I have seen organizations that implemented every Agile ceremony correctly while continuing to operate under the same decision-making structures that existed before the transformation began. The meetings changed. The terminology changed. The underlying behaviors often did not.

The paper also highlights procurement as a significant challenge, and this is another area that resonated with me.

Traditional government procurement processes are designed to reduce uncertainty. They seek detailed requirements, fixed costs, clearly defined deliverables, and predictable outcomes.

Agile approaches begin with a different assumption: that not everything can be known in advance and that learning will occur throughout delivery.

Neither approach is inherently wrong. Both exist for valid reasons. The challenge arises when organizations attempt to combine them without acknowledging the tension that naturally exists between them.

Topics the Paper Prompted Me to Consider

While reading the paper, I found myself thinking about several topics that often receive less attention during Agile discussions.

The first is architecture.

Government organizations rarely start with a clean slate. Most operate environments that have evolved over decades. Systems have been integrated, expanded, customized, and connected to meet changing business needs.

Over time, those connections accumulate.

Applications become dependent on one another. Data is shared across multiple systems. Interfaces are built to satisfy immediate business needs. Processes emerge that depend on assumptions made years earlier.

Eventually, a seemingly simple change can require coordination across multiple teams, applications, vendors, and departments.

In those situations, the challenge is not that teams do not understand Agile principles. The challenge is that the underlying architecture makes agility difficult.

This is not a criticism. It is simply the reality of many mature government technology environments.

The paper focuses appropriately on organizational agility, but it also made me wonder whether technical agility deserves a larger role in the conversation.

Can teams truly deliver changes quickly and incrementally if the systems they support cannot?

Government and the Pursuit of Predictability

Another thought that surfaced repeatedly while reading the paper was that government organizations are often optimized for something different than Agile.

Governments are optimized for predictability and again, this is not a criticism.

Public institutions are responsible for taxpayer funds, public services, regulatory compliance, public records, payroll, emergency operations, and countless other functions that citizens depend upon every day.

Predictability matters.

Leaders need confidence that critical services will continue operating. Budgets must be managed responsibly. Risks must be understood and mitigated.

Agile, however, is built around adaptability.

It assumes that requirements will evolve. Priorities will shift. Teams will learn new information as work progresses.

The more I reflected on the paper, the more I wondered whether many government Agile initiatives are actually attempts to balance these two competing objectives.

Organizations want the adaptability that Agile promises. At the same time, they cannot simply abandon the predictability that public service requires.

That tension may explain many of the challenges that Agile transformations encounter.

Leadership and Uncertainty

The paper also prompted me to think about leadership expectations.

Many government leaders genuinely support Agile initiatives. They recognize the need to modernize processes and improve responsiveness.

At the same time, leaders often operate within accountability structures that require forecasts, budgets, schedules, and commitments.

This creates a difficult balancing act: Agile encourages learning and adaptation... Governance structures often require certainty and predictability.

Neither perspective is unreasonable. The challenge is finding a balance between them.

Perhaps one of the most important questions for any Agile transformation is not whether leadership supports Agile, but how much uncertainty the organization is prepared to embrace in pursuit of better outcomes.

An Important Contribution to the Discussion

One aspect I particularly appreciated about the paper is that it avoids presenting Agile as a simple process change.

The discussion recognizes that successful adoption requires changes in culture, leadership, governance, and organizational behavior. In my experience, that perspective is both realistic and necessary.

Too often, Agile conversations focus on frameworks, ceremonies, and tools while overlooking the broader organizational changes required to support them.

The paper avoids that trap and helps move the discussion in a more productive direction.

Continuing the Conversation

Overall, I found the paper to be a valuable contribution to an important discussion.

Its focus on culture, leadership, procurement, and organizational change aligns closely with many of the realities government technology teams face every day.

At the same time, it encouraged me to think more deeply about several related topics that deserve continued exploration.

• How much does system architecture influence organizational agility?
• How can governments balance adaptability with the predictability that public service demands?
• Can procurement processes support iterative learning without sacrificing accountability?
• What does Agile leadership look like in environments where certainty is often expected?

These are not simple questions, and I do not claim to have definitive answers.

What I do know is that after years working in local government technology, I have found Agile adoption to be far more complex than a methodology discussion.

It is ultimately a conversation about culture, governance, incentives, architecture, risk, and the unique responsibilities that come with serving the public.

The paper provides an excellent starting point. The conversation, however, is much larger than Agile itself.

And that is exactly why it is worth having.

Editor's Note: This article is the first in a series exploring Agile adoption, procurement, architecture, governance, and modernization within government technology organizations. The series was inspired by Adopting Agile in State and Local Governments by Sukumar Ganapati and expands on several themes discussed in that paper.