Start Smart: Structuring Azure DevOps for Government IT without Breaking the Silos Too Fast

So your CIO heard about Agile and DevOps—maybe even Azure DevOps—and wants the IT department to “implement it.” What does that even mean? If you’re in local government IT, the idea probably came down from someone who read a blog or heard a buzzword in a mayor’s cabinet meeting. Now it's on your plate.

Here’s the truth: DevOps isn’t just about tools or automation. It's about people, ownership, and collaboration. And if you work in local government, you know those three things are deeply siloed.

Silos Aren’t the Enemy—At First

Government departments are built to be autonomous. Permitting doesn’t run the same way as Solid Waste. The GIS team has different needs than the Council Clerk’s office. And each area is very protective of its stuff—its boards, its code, its process. If you walk in saying, “Let’s open everything to everyone,” you’ll hit a wall of resistance. “That board is private,” “Our process is different,” “No one outside should see this repo”—you’ve heard it all.

As my friend and experienced agile coach JoAnna Kelly puts it:
“In local government IT, we’re not building nuclear weapons.”

Transparency is good. Collaboration is better. But forcing too much openness too early will make everyone dig their heels in. That’s why buy-in matters more than purity at the beginning.

The Portfolio Approach: A Team Project per Area of Business

Here’s the recommendation: Treat each “area of business” as a portfolio, and give each one its own Azure DevOps Team Project. That Team Project isn’t for a product or a sprint—it’s a full ecosystem. A portfolio. The word "project" on the Azure DevOps UI is misleading. It's not small. It's not short-lived. It's the kingdom. And inside it, the "owners" are the lords of the land.

They decide:

• Who gets in
• What practices they follow
• How they use boards and repos
• Which pipelines they build

Of course, you still establish organizational guardrails:
security policies, governance standards, compliance checks. But you delegate autonomy inside each portfolio to the people who live and breathe that area of business every day.

What Counts as an “Area of Business”?

In local government IT, we typically see two kinds:

1. External-facing government functions
   These usually map to departments:
   • Permitting
   • Water and Sewer
   • Solid Waste
   • Council/Commission
   • Elections
   • Parks and Recreation
     … you get the idea.
2. Internal IT platform services
   These cut across departments and provide infrastructure:
   • Hosting/Servers
   • Databases/Storage
   • GIS and Maps
   • Networking
   • Identity and Security

Each of these deserves its own portfolio when the time is right.

Don’t Create All the Portfolios at Once

This is crucial: Do not try to define and pre-create every portfolio.
Instead, foster the idea of portfolios and let teams grow into it. Make it known that any team serving a real area of business can request one. Encourage it. Support it. But let it happen organically.

Create a simple, structured process for requesting new portfolios. And put that responsibility in the hands of someone who deeply understands the org chart, the culture, and the cross-department relationships. Do not delegate this to just anyone. Naming and scoping portfolios is political—it requires both insight and diplomacy.

Final Thought: Let the Structure Grow

If you try to restructure everything upfront, you'll spend months arguing and still get it wrong. But if you build the structure in service of ownership, and let it evolve at the pace of adoption, your Azure DevOps environment will become something powerful.

One portfolio at a time.