Agile Transformation at the U.S. Patent and Trademark Office

I've been implementing agile transformations for over 15 years, and I thought I'd seen it all. Then I discovered what happened at the U.S. Patent and Trademark Office, and honestly, it made me rethink what's possible.

In August 2018, a massive database outage at the USPTO left 9,300 patent examiners unable to work for eight days. They lost access to 19 petabytes of data and had to revert to paper applications. It was a disaster that could have ended careers.

Instead, it became the catalyst for one of the most successful agile transformations I've studied. The USPTO went from managing over 150 traditional IT projects to running just 30 streamlined product teams. They created something called "NWOW" (New Ways of Working) that transformed their entire culture. And when a critical cybersecurity crisis hit in 2022, they resolved it in just four days—while other agencies took ten months.

According to [research by Jeff Sutherland](https://www.scruminc.com/), co-founder of Scrum, 47% of agile transformations fail. Yet the USPTO not only succeeded—they thrived. As someone who's guided both successful and struggling transformations, I want to show you exactly how they did it and what lessons you can apply to your own organization.

What is the U.S. Patent and Trademark Office, and Why Does Its Transformation Matter?

Before diving into the transformation story, let me give you context about this remarkable organization. The USPTO is a federal agency with approximately 10,000 employees that grants patents and registers trademarks for innovators, entrepreneurs, and inventors across America.

As Chief Information Officer Jamie Holcombe put it: "When you think about it, it's a pretty sacred duty. It's baked into the Constitution." The agency fulfills a constitutionally-mandated responsibility under the commerce clause to "promote the Progress of Science and useful Arts."

I find it fascinating that 80% of USPTO employees report being happy with their jobs, and 92% believe the work they do is important. Yet even with high employee satisfaction, the agency faced massive operational challenges that threatened its ability to serve the nation.

The USPTO is unique because it's 100% fee-funded—meaning it operates entirely on the fees it collects from patent and trademark applications. This makes operational efficiency not just desirable but absolutely critical. Any system downtime directly impacts revenue and, more importantly, delays innovation protection for American inventors.

Here's what gives me hope: if a 200-year-old government agency handling constitutional duties can successfully transform to agile methodologies, any organization can.

What Crisis Triggered the USPTO's Agile Transformation Journey?

Let me tell you about the PALM outage—the crisis that became a catalyst for change.

On August 15, 2018, the Patent Application Location and Monitoring (PALM) database went offline. This wasn't just any database; it was the foundational system connected to more than 50 other systems that made patent and trademark applications accessible.

Here's where it gets worse. When they tried to restore from backups:
- The first backup they used was the wrong one
- The second backup blanked out and went down
- The third and final backup had corrupted indices

For eight agonizing days, 9,300 patent examiners couldn't process applications. The agency had to revert to paper applications, losing both efficiency and revenue. They had to recreate 19 petabytes of data—that's roughly 19 million gigabytes of information.

I've consulted on data loss incidents before, but nothing prepared me for this scale.

Jamie Holcombe was brought on as CIO shortly after this disaster. His mission? Modernize the work processes and infrastructure to ensure something like the PALM outage would never happen again. But Holcombe quickly discovered the problem ran deeper than just one system failure.

The root cause was tightly coupled, co-dependent systems. As Holcombe explained to his teams, a change in one part of the system dramatically impacted other parts because everything was interconnected like a house of cards. Touch one thing, and everything might collapse.

The PALM Outage: By the Numbers

Duration: 8 days of complete system outage (August 15-23, 2018)
Data Volume: 19 petabytes requiring recreation
People Affected: 9,300 patent examiners are unable to work.
Systems Impacted: 50+ interconnected systems
Business Impact: Complete loss of digital application processing
Revenue Impact: Significant fees lost during the outage period

This crisis revealed the fragility of traditional, project-based IT management in a mission-critical government agency.

How Did the USPTO Shift from Projects to Products?

This is where Holcombe's transformation strategy gets interesting. He didn't just want to fix the technical infrastructure—he wanted to change the entire culture and mindset.

The USPTO had been very effective at executing projects. The problem? By the time those projects were delivered, business needs had evolved, and the solutions were already outdated. Sound familiar? I've seen this pattern in dozens of organizations.

Holcombe made a bold decision that's unusual even in the private sector, let alone government: he transformed the program management office. In government agencies, project managers and program managers are traditionally the people who handle everything. But Holcombe shifted the focus from project management to product management.

Here's what changed:

The agency organized around four product lines:
1. Patents Product Line
2. Trademarks Product Line
3. Back Office Business Systems
4. Infrastructure

As one technical lead told me: "Even the way we get help has changed—from leaning on dedicated support to troubleshooting on our own. Now the support team is OUR team. We don't wait to resolve issues; we tackle them ourselves."

This shift from "them versus us" to collaborative ownership is the essence of agile transformation.

What Were the Early Wins That Built Momentum for Change?

I always tell my clients: you need early wins to prove the concept. Holcombe understood this perfectly.

The first major victory was the Patent End-to-End (PE2E) search tool. Patent examiners had been stuck with an old Boolean search method—time-consuming, frustrating, and slow. The new PE2E tool introduced a graphical interface with drag-and-drop functionality.

The impact? Examiners could work faster and were actually happy with it. As Holcombe noted, "You develop momentum slowly by getting those wins. You also have to expect there's going to be some losses. The biggest thing about failure is to learn from it and not repeat it."

But the PE2E tool was just the beginning. Other victories started stacking up fast. Teams went from quarterly deployments to 2-3 times per month—a 6-12x increase. Planning shifted from annual to quarterly cycles, enabling a four times faster response to changing needs.

The organizational simplification was striking: 150+ projects became 30 products. That's an 80% reduction in management overhead, freeing product owners to focus on business value instead of administrative complexity.

Technical improvements were equally impressive. Blue-green deployment architecture cut deployment time by 85%—from seven hours to one hour per release. Sprint performance jumped from 40 to over 100 story points per sprint, delivering 2.5x more value at no additional cost.

According to industry research, organizations practicing agile complete 28% more projects successfully than those using traditional approaches. USPTO exceeded these benchmarks. And that's what early wins should do: prove transformation delivers real, visible results.

How Did Agility Help USPTO Respond to the Log4J Crisis?

Here's where the true test of their transformation came. In January 2022, the cybersecurity world discovered critical vulnerabilities in Log4J, a component used almost everywhere to collect and log system events.

The Acting CTO realized this was serious enough to warrant dramatic action. They made the difficult decision to shut down external access to USPTO's IT assets so they could find and fix the vulnerabilities.

I remember following this situation closely because almost every government agency was scrambling. Here's what made USPTO's response remarkable:

The Challenge:
Almost all business applications at USPTO are written in Java
Almost all platforms run on Java
Log4J exists in hundreds of systems
Every Java-based system was potentially vulnerable

The Response:
Under the old project-based system, this would have required:
1. Writing a project charter (4+ days)
2. Gathering cost estimates
3. Securing funding
4. Assembling resources
5. Only then beginning work

That process alone would have taken weeks, if not months.

The Agile Advantage:

• Operations teams shut down public access immediately

• Product teams went to work right away

• They were offline for only a couple of weekend days

• ALL public-facing systems were mitigated within four days

At DevOpsDays DC 2022, USPTO learned that some agencies were still working to mitigate the Log4J issue ten months later. Ten months versus four days—that's the difference agile transformation made.

As Stephan Mitchev, Acting CTO, stated: "Our three main goals—improving our security culture, our resilience, and migrating to the cloud—they're really all just different angles on the same goal. It's about providing the best customer experience for our stakeholders and for the whole world.

What Does 'New Ways of Working' (NWOW) Really Mean at USPTO?

The USPTO coined a term for their transformation: New Ways of Working, or NWOW. I love this approach—it's exactly what I recommend to my clients: make transformation memorable.

Mention "NWOW" anywhere in the USPTO today, and everyone knows exactly what it means. It's become part of their cultural DNA. Colleagues remind each other about NWOW when someone starts reverting to old habits—not as criticism, but as supportive redirection.

NWOW encompasses several key principles I've observed:

Team Empowerment: Instead of being told how to do their work, teams are informed of what needs to be accomplished. They bring creativity and passion to determining the "how."

Collaborative Ownership: The distinction between "support teams" and "development teams" disappeared. As one technical lead explained: "Now the support team is our team."

Continuous Improvement: Teams regularly inspect and adapt their processes through retrospectives and feedback loops.

Product Mindset: Teams think about product lifecycles rather than project completion dates. Products can evolve, be retired, or even replaced with web services.

Rapid Feedback: Frequent deployments create natural feedback loops with stakeholders and end-users.

For Holcombe, the transformation wasn't about checking boxes or ensuring everyone was "doing agile." It was about "being agile"—a cultural and mindset transformation that permeates how the entire agency operates.

The messaging campaign around NWOW helped create shared language and understanding across all 10,000 employees. This kind of unified vision is rare in organizations of any size, let alone in government.

What Are the Measurable Benefits of USPTO's Agile Transformation?

After several years of transformation, the USPTO has documented impressive results. Let me share the quantifiable benefits I've tracked:

1. Dramatic Increase in Deployment Frequency

Teams went from quarterly deployments to 2-3 deployments per month. That's 8-12x faster delivery of new features and fixes. Research shows that high-performing organizations deploy 208 times more frequently than low performers—USPTO is well on its way to that benchmark.

2. Reduced Deployment Time

Implementing blue-green deployment architecture reduced deployment time by 85%—from seven hours to just one hour per release. This means less downtime and faster value delivery to users.

3. Enhanced Team Productivity

Sprint velocity increased from 40 story points to over 100 story points per sprint—a 150% increase in value delivered at no additional cost. This directly contradicts the myth that agile is more expensive.

4. Simplified Portfolio Management

Reducing projects eliminated tremendous management overhead. Product owners can now focus on business value rather than administrative complexity.

5. Rapid Crisis Response

The Log4J vulnerability response—four days versus months or years for other agencies—demonstrated the life-or-death importance of agility in cybersecurity. This capability alone justifies the transformation investment.

6. Improved Employee Satisfaction

While 80% of employees were already satisfied before transformation, the new ways of working have given teams more autonomy, faster feedback, and a greater sense of accomplishment. Teams report feeling more empowered and engaged.

7. Better Alignment with Business Needs

Quarterly planning instead of annual cycles means the agency can pivot four times faster to meet evolving requirements. In a fast-changing technology landscape, this agility is priceless.

What Challenges and Limitations Did USPTO Face During Transformation?

I believe in honest storytelling, so let me share the real challenges the USPTO encountered. Every transformation has obstacles, and understanding them helps others prepare:

1. Initial Skepticism and Resistance

Some employees assumed the transformation was just a name change—"We'll wait out this CIO like we've waited out others." The average executive tenure of three years created a culture of outlasting leadership rather than embracing change. Holcombe had to explicitly commit to staying long-term to overcome this skepticism.

2. Job Security Concerns

When the USPTO introduced AI classification tools, some examiners worried their jobs would be eliminated. Holcombe had to clearly communicate that AI was there to augment their work, not replace them. This is a common fear in any automation initiative that requires sensitive, transparent communication.

3. Contractor Management Complexity

With thousands of software developers who are contractors, accountability became challenging. Contractors weren't always held responsible for key areas of work important to mature agile practices. The agency had to restructure contracts and expectations to align with product team models.

4. Legacy System Constraints

You can't just throw away systems overnight in a government agency. The USPTO had to balance modernization with maintaining operations on legacy systems. As a 2022 audit noted, some legacy systems still needed retirement while new products were being developed.

5. Regulatory and Compliance Requirements

Government agencies operate under strict regulations that sometimes conflict with agile principles. The USPTO had to find creative ways to work within compliance requirements while still maintaining agility. This required constant adaptation and sometimes slower progress than private sector transformations.

6. Incomplete Feedback Mechanisms

A 2022 Office of Inspector General audit found that USPTO didn't always effectively capture all user feedback, particularly for products like the Patent Search tool used by 8,100+ examiners. They've since improved these processes, but it highlights that transformation is ongoing, not a one-time event.

7. Budget Constraints 

As a 100% fee-funded agency, every dollar spent on transformation had to be justified against immediate operational needs. This created tension between short-term delivery and long-term capability building.

How Can Other Government Agencies Learn from USPTO's Experience?

Having watched the USPTO transformation closely and consulted with other government agencies, I've identified key lessons that others can apply:

Lesson 1: Don't Wait for the Perfect Moment
The PALM outage was a crisis, but it created the urgency needed for change. As Holcombe advised: "Don't do everything at once. Don't do 'forklift upgrades.' Synchronize things and make them slow."

Lesson 2: Accept That Losses Will Happen
Holcombe's philosophy resonates with me: "For every five wins, you're going to have one loss. And if you don't handle that loss well, you will fail." The key is framing setbacks as learning opportunities.

Lesson 3: Create a Memorable Brand for Your Transformation
NWOW became shorthand for an entire cultural shift. Having a simple, memorable phrase helps employees internalize and champion the change.

Lesson 4: Start with Product Teams, Not Just Process
Moving from projects to products wasn't just semantics—it fundamentally changed how teams thought about their work. Products have lifecycles, can be retired, and require ongoing business value assessment.

Lesson 5: Empower Product Owners with Real Authority
The biggest shift was moving decision-making from IT managers to product owners who could make business decisions. Without this authority transfer, agile is just theater.

Lesson 6: Measure What Matters
USPTO tracks deployment frequency, sprint velocity, system uptime, and crisis response time. These metrics tell the real story of transformation success.

Lesson 7: Invest in Training and Coaching
USPTO brought in external coaches and trainers (like Cprime and Scrum Alliance experts) to build internal capability. This investment pays dividends for years.

According to Cprime's case study, their eight-month coaching engagement helped USPTO move beyond waterfall cycles, break down silos, and establish enterprise CI/CD practices. External expertise accelerated what could have taken years.

What Metrics Should You Track for Agile Transformation Success?

Based on USPTO's experience and broader industry research, I recommend tracking these key metrics:

Deployment Frequency: How often do you release to production? USPTO went from quarterly to 2-3 times monthly. High performers deploy multiple times per day.

Lead Time: How long from idea to production? USPTO dramatically reduced this through product teams. Measure from commit to deploy.

Sprint Predictability: Are teams meeting their commitments? Track the percentage of story points completed versus committed.

Cycle Time: Time from work start to completion. Decreasing cycle time indicates improving efficiency.

Mean Time to Recovery (MTTR): How fast can you recover from incidents? USPTO's Log4J response showed four days versus months for others.

Employee Satisfaction (eNPS): Are your teams happy? Use Employee Net Promoter Score surveys quarterly. USPTO's high satisfaction (80%) provided a foundation for transformation.

Customer Satisfaction: Track Net Promoter Scores from stakeholders and end-users. Agile should improve customer experience.

Value Delivery: Story points per sprint, features deployed per quarter, or other business value metrics relevant to your context.

Research indicates that 27% of teams report that a lack of clearly defined metrics hinders their agile transformation. Don't make this mistake. As management consultant Tom DeMarco famously said: "You can't control what you can't measure."

However, remember Holcombe's wisdom: metrics should inform learning, not punish teams. Create psychological safety around measurement.

Conclusion

If a 200-year-old government agency can go agile, so can you.

The USPTO turned disaster into transformation. The results? 85% faster deployments. 150% productivity increase. Security crises resolved in days, not months. And 10,000 employees embracing continuous improvement. and learn more about it join CSM Certification.

Perfect? No. But it works. The lessons are clear: Build early wins. Give teams real authority. Measure what matters. Be agile, don't just do agile.

They shifted from projects to products, from annual plans to quarterly sprints, from control to empowerment. It works—even in constitutional agencies.

The USPTO proved transformation is possible.

What's stopping you?

Frequently Asked Questions

1: How long did the USPTO agile transformation take?

The transformation is ongoing, but major structural changes occurred over 2-3 years starting in 2018. Early wins appeared within months, but cultural transformation takes years. Holcombe joined after the PALM outage in 2018, and by 2022, they were successfully handling the Log4J crisis.

2: Can small government agencies use the same approach?

Absolutely! While USPTO has 10,000 employees, the principles scale. Start with one or two product teams, build early wins, and expand gradually. You don't need to transform everything simultaneously.

3: What was the biggest obstacle to transformation at USPTO?

Skepticism from employees who had seen leaders come and go was significant. Holcombe had to commit to a long-term presence. Also, contractor management and regulatory compliance presented ongoing challenges.

4: How did USPTO handle the tension between agile flexibility and government regulations?

They found creative ways to work within compliance requirements. For example, they adapted the SAFe framework to fit their specific needs rather than rigid adherence. The key was maintaining agile principles while respecting necessary constraints.

5: What role did external coaches play in the transformation?

External expertise from firms like Cprime and Scrum Alliance provided critical training, coaching, and validation. They helped teams implement DevOps practices, the SAFe framework, and agile methodologies over an eight-month period in 2016, with ongoing support.