Why Agile Requires Loosely Coupled Systems

You cannot build an Agile organization on top of an architecture that resists change.

One idea from Adopting Agile in State and Local Governments by Sukumar Ganapati particularly resonated with me. The paper notes that Agile works best when systems are modular and loosely coupled. It is mentioned almost in passing, but in my experience, this single statement deserves far more attention than it usually receives.

In fact, I would argue that it is one of the biggest reasons Agile transformations struggle in government.

Organizations often focus on ceremonies, frameworks, and tools. They train Scrum Masters, purchase Agile management software, and reorganize teams around products. Yet despite all of these changes, delivering even a small enhancement still requires months of planning and coordination.

Why?

Because the organization may be trying to practice Agile on top of an architecture that fundamentally resists change.

What Does "Loosely Coupled" Actually Mean?

A loosely coupled system is one where applications can evolve independently.

Each system owns its own data. Each system exposes well-defined APIs. Communication happens through stable interfaces or events rather than direct database access or custom file exchanges.

Most importantly, one team's deployment should rarely require another team to make changes at the same time. That independence is what allows small, incremental improvements.

Now compare that with what many government organizations have accumulated over decades.

A change to one application requires modifications in three databases, updates to nightly integration jobs, coordination with multiple vendors, adjustments to reporting systems, and careful scheduling because everyone depends on everyone else's implementation timeline.

Technically, each application still exists. Architecturally, they behave like one enormous application.

I often think of it like renovating an old building where every wall is load-bearing. Replacing a single window unexpectedly requires structural engineers, temporary supports, inspections, and work throughout the building. Eventually, people stop asking for improvements—not because they don't need them, but because every small change feels like a major construction project.

Tightly coupled software behaves the same way. Every dependency becomes another load-bearing wall.

The Cost of Tight Coupling

When every system depends on every other system, the cost of change increases dramatically.

A seemingly simple request, such as adding a field to a citizen record, can become a project involving multiple departments, database administrators, integration developers, testing teams, infrastructure staff, and external vendors.

None of these people are resisting change. The architecture simply requires everyone to move together.

I've sat in meetings where a seemingly simple enhancement was estimated at nine months... not because the business logic was particularly difficult, but because six independent systems had to be modified, tested, and deployed together. The code itself might have taken a few days. The dependencies took months.

Nobody in those meetings lacked talent or motivation. They were simply working within an architecture that required everyone to move together.

Eventually, organizations begin believing that software projects naturally take six months, a year, or longer.

Often they do... but not because of Agile, Scrum, or government bureaucracy alone. They take that long because every change creates a chain reaction across dozens of interconnected systems.

Agile Is About Reducing Coordination

One realization changed how I think about Agile.

Agile is often described as delivering software in short iterations, but I don't think that's its defining characteristic.

At its core, Agile is about reducing the cost of responding to change.

One of the biggest contributors to that cost is coordination. Every additional team that must approve, modify, test, deploy, or synchronize work makes change slower and riskier.

If a team can make a change, test it, deploy it, and release it without waiting for five other teams, agility naturally follows.

If every release requires enterprise-wide coordination, no sprint planning session can solve that problem.

Architecture determines how much coordination is necessary. Processes simply adapt to the architecture.

Government Has Unique Challenges

Government systems rarely start as greenfield projects.

They have decades of accumulated history. Financial systems. Human Resources. Permitting. Public Safety. Property Records. Elections. Utilities. Many of these systems were built at different times by different vendors using different technologies and different assumptions about integration.

Over time, organizations understandably connected them in whatever way solved the immediate business need.

• Shared databases.
• Nightly batch files.
• Direct SQL access.
• Point-to-point integrations.
• Custom exports.

Each solution solved a problem. Collectively, they created dependency.

Sounds too familiar?

This is not unique to government, but government tends to keep systems much longer than private industry, allowing these dependencies to accumulate over decades.

Decoupling Is a Journey

This does not mean organizations should stop modernizing until every legacy system is replaced.

Quite the opposite.

Every modernization effort presents an opportunity to reduce coupling rather than increase it.

• Instead of reading another application's database, expose an API.
• Instead of creating another custom export, publish an event.
• Instead of allowing multiple applications to own the same data, establish clear ownership.

None of these ideas are particularly new, but they are often treated as technical implementation details. In reality, they directly affect an organization's ability to respond to changing laws, citizen expectations, security requirements, and business priorities.

Architecture is organizational agility made visible.

Final Thoughts

When organizations say they want to become more Agile, they often begin by changing processes. That is understandable because changing meetings is much easier than changing architecture.

But lasting agility rarely starts with standups or sprint planning. It starts by reducing dependencies. The less coordination required between systems and teams, the faster organizations can respond to change.

Perhaps that is the most important lesson hidden within Ganapati's observation: Agility is not just a way of managing projects. It is an architectural property of the systems we build.

Which raises another important question.

If loosely coupled systems make organizations more adaptable, why do governments so often procure platforms that increase coupling rather than reduce it?

That isn't merely a technical decision. It's a procurement decision, a governance decision, and ultimately a leadership decision.

I'll explore that in the next article of this series.

Editor's Note: This article is the second 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.