Government Procurement and Agile (Part 1)

In the previous piece of this series, I made the case that Agile is about much more than holding daily standups, running sprint planning, or picking up the latest project management software. It lives and dies by the underlying architecture. When your systems are tightly coupled, even a minor change turns into a massive coordination effort across multiple teams, systems, and departments. Under those conditions, delivering software iteratively becomes an uphill battle—no matter how dedicated your team is to Agile principles.

As I was reflecting on that, another reality hit me: even before architecture gets a chance to tie a team's hands, something else has usually already set the trajectory: Procurement.

It’s not a topic that gets anywhere near as much spotlight as software architecture or Agile frameworks. Yet, in my experience, it has just as much say in whether an Agile project can actually behave... well, agile.

Before going any further, let me clear one thing up: this isn't a knock on procurement professionals.

Government procurement exists for good reason. It’s designed to ensure fairness, transparency, healthy competition, accountability, and the responsible stewardship of taxpayer dollars. Those principles shouldn't be tossed aside, and nothing here is meant to suggest otherwise.

Instead, these are simply observations from someone who has spent years in the trenches—implementing, integrating, supporting, and modernizing government systems long after the contract ink has dried.

Looking back at those projects, one question keeps popping up: How many so-called Agile projects stop being agile before a single line of code is written?

The Illusion of Certainty

Traditional procurement relies on a simple, understandable premise: you can minimize risk by making as many decisions as possible up front.

Requirements are exhaustively documented. Deliverables are defined. Schedules are locked in, budgets are approved, and contracts are signed. By the time development finally kicks off, the project looks rock-solid and carefully planned.

And to be fair, there’s real value in that discipline. Public agencies have a duty to prove accountability; we can’t run government procurement on vague ideas and good vibes.

The trouble is that software development rarely plays by those rules.

Business priorities shift. Policies get updated. Laws change. Users discover critical needs they never dreamed of during the initial requirement workshops. New integration requirements pop up as neighboring systems evolve. Sometimes, the entire organization restructures mid-project.

None of this is unusual—it’s just the reality of building technology.

Yet, standard procurement processes still operate on the assumption that our most critical decisions should be made when we know the absolute least about the project.

Over the years, I’ve come to think of this as fake certainty. Everything feels secure because it’s on paper. Every requirement has an ID number, every deliverable has a definition, and every milestone has a date.

But documentation isn't wisdom. A 200-page specification doesn't eliminate risk; it just captures our best guess at a single moment in time. Reality has a habit of teaching us lessons we couldn't have anticipated when the contract was signed.

Was It Ever Really Agile?

I’ve lost count of how many times I’ve heard someone say, "We tried Agile, but it just didn't work for us."

Whenever I hear that, my first reaction is always to ask: Was the project actually Agile in the first place?

If a government tech project starts with a fixed scope, fixed budget, fixed timeline, predefined deliverables, and a formal change-control process for anything slightly outside the original spec, those decisions might make total sense from a procurement standpoint. But they aren't Agile.

Agile relies on the idea that teams learn as they build. It expects priorities to shift once users actually get their hands on working software. It treats adaptation as the default, not an emergency that requires a formal contract amendment.

If every meaningful course correction requires procurement reviews and lengthy approvals, you might be running Scrum ceremonies and using the terminology, but the contract governing your work is still purely predictive.

That doesn't mean the project will fail. It just means we shouldn't blame Agile when it does. In reality, Agile was never given permission to enter the room.

Falling for the Shiniest Option

There’s another pattern I see time and again, and it has nothing to do with the engineering team. It happens way earlier.

Tech evaluations often open with brilliant vendor demos. The user interfaces are slick, the workflows look effortless, and the executive dashboards are incredible. Every feature promises to solve a headache the agency has wrestled with for a decade.

Vendors should put their best foot forward—that’s their job. What worries me is what happens next.

Too often, the most critical engineering questions get pushed down the road until after a favorite candidate has already been crowned:

• How will this actually talk to our legacy systems?
• Does it play nice with our identity architecture?
• Can it expose clean, modern APIs?
• How painful are upgrades going to be down the line?
• Will it force us to reshape our business operations, or can it adapt to us?
• What are future customizations going to cost?

By the time those technical conversations happen, the organization is already emotionally and strategically invested in the shiny product. The conversation subtly shifts from "Is this really the right fit?" to "How do we force this to work?"

Those are two very different places to start.

Buying Relationships, Not Just Software

If my career has taught me anything here, it’s that public institutions rarely just buy software.

They buy long-term relationships. They buy support models, licensing structures, integration philosophies, and future flexibility—or future gridlock. The software itself is only a fraction of the deal.

Some of the heaviest costs don't show up during initial implementation. They surface years later when you try to connect another system, automate a new workflow, modernize your tech stack, or pivot to meet a new legislative mandate.

Those long-term traits are much harder to evaluate in a vendor demo, but they almost always dictate whether a procurement turns out to be a genuine success or a long-term trap.

Architecture Still Wins

In the previous article, I talked about how Agile thrives on modular, loosely coupled systems. That exact principle applies to procurement.

When you build a modular architecture, your procurement strategy can become modular, too. Instead of trying to replace massive enterprise platforms in one high-stakes move, agencies can procure targeted capabilities and services that plug into an existing ecosystem.

Smaller procurements mean lower risk and better competition. They let organizations adapt incrementally rather than betting millions on a single, massive decision they hope stays relevant for the next decade.

Architecture and procurement are far more intertwined than most people realize.

Looking Ahead

None of this is to say that government procurement is fundamentally broken. The core problem is that procurement and Agile are built for different goals.

Procurement prioritizes fairness, accountability, transparency, and fiscal responsibility. Agile prioritizes learning, rapid adaptation, and continuous delivery of value.

These goals don't have to be mutually exclusive, but they do create constant friction. In my experience, government projects often inherit constraints during procurement that quietly strip away their agility long before the first line of code is written.

Acknowledging this tension isn't a critique of procurement—it's just being honest about what it takes to deliver technology in the public sector.

In the next article, I want to move past the diagnosis and focus on practical solutions: If governments genuinely want the benefits of Agile, how can procurement evolve without sacrificing the transparency and accountability the public deserves?

Editor's Note: This article is the third 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. Read the first article here.