From Command-and-Control to Collaborative Delivery: A Real Story from Government IT

Introduction

Command-and-control management is still the default operating system in many public sector IT organizations. Decisions come from the top, processes are rigid, and hierarchy often takes precedence over outcomes. While this approach offers perceived control and predictability, it often clashes with the very nature of modern software development—especially Agile and DevOps practices.

But change doesn’t always come from policy. Sometimes it comes from the bottom-up, in the quiet rebellion of delivery teams who just want to get things done better.

The Skeptical Executive

In the Miami-Dade County IT ecosystem, which serves a massive and complex public organization, a high-ranking official from the financial department once pushed back hard against Agile adoption. When an Agile coach was assigned to a key digital transformation project, the executive was clear: “This project is too important and too complex to try this Agile thing.”

He even attempted to have the coach removed, arguing, "This is my project, and it won't work here."

From his perspective, Agile was a Silicon Valley fad. A luxury. Government didn’t have time to iterate or experiment—especially on projects tied to regulatory deadlines, large contracts, and political oversight.

The breaking point came during a status meeting when he asked the coach, “When will the project be done?” The coach responded honestly, “Not sure—we need to give it at least a couple of sprints to measure velocity.”

That was the last time Agile and DevOps advocates were invited to his status meetings. And, ironically, the last time the development team actually paid close attention to those meetings.

What Happened Next

Despite the resistance at the top, the development team decided to quietly adopt Agile principles anyway. They began holding daily stand-ups, breaking down work into sprints, and focusing on delivering value in small increments.

The results were impossible to ignore:

• More frequent demos to internal stakeholders
• Reduced rework due to earlier feedback
• Fewer surprises at project milestones

The executive, initially skeptical and defensive, began to take notice. He saw that the team was hitting milestones more consistently, and that risk was reduced rather than increased. He started sitting in on reviews and even asked questions about burn-down charts and velocity.

From Resistance to Support

Over time, the executive's stance softened. He began to see that Agile wasn’t chaos—it was structure applied to learning. It was discipline, not disorder. More importantly, he saw that the team was more engaged and that the project’s success wasn’t due to command-and-control, but in spite of it.

While he doesn’t openly acknowledge his early resistance, his support for Agile and DevOps has become clear in how he engages with teams today. He now champions incremental delivery, transparency, and early stakeholder involvement.

Takeaway

The public sector doesn’t change easily. But it can change. And sometimes, the best way to lead that change is not to wait for permission—but to prove that better ways do work, even in government.

This story isn’t just about Agile. It’s about mindset. Because the real shift isn’t from waterfall to sprints, or from sign-offs to pipelines—it’s from control to collaboration.

And once that shift happens, everything else can follow.