Why Government DevOps Is So Hard

Discussions of DevOps in government attract attention precisely because success is rare. The combination of strict compliance requirements, deeply entrenched SDLC processes, multi-stakeholder approval chains, and risk-averse culture makes the transition uniquely difficult. The U.S. Patent and Trademark Office (USPTO) is one of the few agencies that has made measurable progress — and the story of how they did it offers practical lessons for any organization facing similar bureaucratic headwinds.

About the USPTO’s Fee Processing Next Generation (FPNG)

The USPTO is the federal agency responsible for granting patents and registering trademarks in the United States. Unlike most government agencies, it is entirely self-funded: every service it provides is paid for by fees charged to applicants and registrants. That funding flows through the Fee Processing Next Generation system — effectively a high-stakes government-run e-commerce platform.

• FPNG processes approximately $3.5 billion in payments annually.
• It is used by applicants worldwide.
• It is subject to the full spectrum of government security, compliance, and audit requirements.

This context matters: when a payment system of this scale and criticality attempts a DevOps transformation, the stakes and the obstacles are both very high.

Defining DevOps in a Government Context

Simmons Lough, tech lead at the FPNG, offered a deliberately concise definition of DevOps during his All Day DevOps presentation:

“Frequent, quick software installs to production without shortcuts.”

Simmons Lough, Tech Lead, USPTO FPNG

The phrase “without shortcuts” is important. In government, speed cannot come at the expense of security or compliance. The goal is to engineer the compliance burden out of the critical path — not to bypass it.

Lough observed that at the time of his talk, most federal agencies were deploying to production approximately once per quarter. While cultural transformation and collaboration are frequently cited as the starting points for DevOps adoption, he argued that government teams need to prioritize Continuous Delivery mechanics first. Too many initiatives stall because executives spend cycles talking about culture change without ever improving the pipeline itself.

The Problem: A Sprint Process Built for Delay

A standard two-week Agile sprint ends with a scrum master declaring “done.” In a typical government environment, that declaration triggers a cascade of sequential, manual, form-driven steps:

1. The development team fills out a form requesting security testing.
2. The form enters a queue. One to two weeks later, a security team picks it up, scans the system, and returns results.
3. Developers fix identified issues.
4. Another form is submitted — this time for code review. Another queue, another wait.
5. After all reviews, a Production Readiness Review is convened — potentially involving 30 or more separate groups, each of whom must give explicit approval before deployment.

The cumulative lead time from “code complete” to “deployed” can easily exceed six to eight weeks, which is why quarterly releases are the norm rather than an anomaly. This process is structurally incompatible with DevOps principles.

Lough also highlighted a second problem: government teams frequently attempt to accomplish too much in a single sprint. Smaller batch sizes reduce risk and make it easier to define a meaningful “definition of done” — but reducing sprint scope to a level where customers are actually using the output by the time the sprint closes is a discipline that takes active effort to build.

The USPTO’s Solution: Three Pillars of Change

The FPNG team spent approximately three years — starting with a pilot — designing, approving, and implementing a new approach. The core shift was giving the application team the authority to approve their own releases, backed by automated quality and security gates. A new document was created to formally override the legacy SDLC process. Here is how they structured the transformation:

1. Agile Discipline and the Definition of Done

Many government development teams lack a clear, agreed-upon definition of “done.” Without it, sprint scope expands, work bleeds across iterations, and it becomes impossible to release incrementally. The FPNG team established explicit done criteria and enforced small enough batch sizes that each sprint’s output was immediately usable by customers. This is a prerequisite for any meaningful Continuous Delivery practice.

2. Microservices Architecture

The FPNG decomposed its application into discrete business domains — payments, carts, receipts, and others. Each microservice is:

• Independently releasable — no coordinated release trains required.
• Independently testable — test suites run in isolation without cross-service dependencies.
• Independently deployable — teams can ship a payments fix without touching the receipts service.
• Backed by its own database schema — avoiding shared-data coupling.
• Served by its own CI/CD pipeline — one pipeline per microservice.

The organizing principle is independence. When teams can work, test, and deploy without coordinating with every other team, build times drop and release cadence increases significantly.

3. Automated Build Gates

This is the technical keystone of the whole transformation. Rather than routing every release through a human approval queue, the FPNG automated the quality and compliance checks that previously required weeks of manual effort. Their automated gates include:

• Live code coverage measurement
• Unit test execution
• Blocker violation detection (critical code quality issues that halt the pipeline)
• Automated policy enforcement (replacing many of the manual form-based reviews)
• Automated security scanning (replacing the manual queue-based security test requests)

The result: what previously took weeks of queue time now takes approximately 8 minutes to execute. The compliance checks still happen — they are simply automated and embedded directly in the pipeline rather than managed through a paper-based ticketing process.

Key Takeaways for Government DevOps Teams

• Start with a pilot. The USPTO took three years to get full approval for its new process — beginning with a contained pilot gave them evidence to present to stakeholders.
• Automate the compliance gates, don’t bypass them. The approval requirements didn’t go away; they were re-engineered into the pipeline so they happen automatically and continuously.
• Shift authority to the delivery team. Replacing 30-group Production Readiness Reviews with automated gates and team-owned quality standards is what unlocked faster deployments.
• Enforce a meaningful definition of done. Without it, small batches and Continuous Delivery are impossible to sustain.
• Architecture matters. Microservices with independent pipelines are not just a technical preference — they are an organizational strategy that reduces cross-team coordination overhead.

Conclusion

The USPTO’s FPNG story is a useful data point for anyone convinced that government and DevOps are fundamentally incompatible. They are not — but the transformation requires engineering compliance into the pipeline, not waiting for culture to change on its own. When automation replaces manual gates and delivery teams are trusted with release authority, even a $3.5B government payment platform can move faster than once per quarter.

Original source: blog.sonatype.com — based on Simmons Lough’s presentation at All Day DevOps.