How we plan to use Product Ownership to transform digital services in local government

In years past our Franklin County Data Center (FCDC) software dev teams made valiant attempts to use Scrum/Agile approaches when building solutions. But they ran into challenges.

Our local government clients were not interested in these newfangled approaches. They came along for the ride politely, joining sprint reviews and feature demos, but what they really wanted to know was, "when are you gonna be done?" We were pushing an Agile approach with waterfall-minded clients.

As we're learning from Recoding America, this waterfall mindset permeates government service thinking at all levels—it's the default model. We're definitely not alone.

Most government teams are focused on risk-avoidance in their operations, opting to focus on legal compliance and rigid processes that are beyond questioning rather than taking calculated risks around interpreting and re-interpreting service approaches that improve through re-assessment over time. It's just safer to do things the way they've always been done and wait for new laws than to update procedures based on real-world feedback loops, which could risk elected official, public, or regulator ire.

“...waterfall methodology amounts to a pledge by all parties not to learn anything while doing the actual work.” —Clay Shirky

Just like "nobody ever got fired for buying Cisco," nobody in government got fired for doing the same things they've been doing for decades.

So what can we do? Take ownership.

Rather than attempting to evangelize the value of agile concepts and get our local government customers to change their world views, while integrating digital services with their missions (which has clearly failed us in the past), our GX Foundry team is going to take a different approach.

We plan to use a Scrum-derived (but not pure) Product Ownership model in which our software products—whether we build them or buy-and-manage them—will be "owned" by our team, not our customers. That means we'll be responsible for:

• stakeholder identification and product definition
• UX research, design, and analytics
• product roadmaps and backlogs
• engineering (coding, configuration, vendor management)
• user training and ongoing support

Sure, our local government teams should "own" their digital services, and we will be delighted to partner with them as much as possible. But asking tigers to change their stripes isn't realistic and would fail to show proper respect for the services our often-overworked government teams already provide every day. They can own their overall public services, and we can own the digital services that snap into their operations.

Will it work?

We don't know. But we do know the old waterfall-style approach has created a lot of pain for our team and our customers. Just one example: technical debt. Turns out when you build software and "walk away" because the customer is happy to keep going with the same solution indefinitely, the inexorable march of technology combines with your bias toward shiny new projects and leaves you with systems aged out beyond your ability to maintain them or even get handsomely-paid support from vendors.

Developing product ownership maturity

From here, we envision progressing through a unique digital services maturity model while on our Product Ownership journey, moving from lower-value to higher-value digital delivery. Right now we're thinking we will:

1. Build a complete catalog of the Products we must manage, assign Product Owners, and develop rudimentary roadmaps. (We're having to invent this, since our notions of ownership are new and appear to be unique.)
2. Prioritize technical debt retirement. We'll have to work with our customers to get this done, but it's a vital early step because our tech debt is growing to dangerous levels, both in total size and as digital security risks escalate.
3. Bring in a low-code / no-code solution to allow for rapid application development and rapid tech debt retirement. This is already in progress, as we acquired Quickbase just this summer, a proven player in local and State governments.
4. Find a handful of small but visible digital service projects we can tackle with our existing team, to learn more about managing the full lifecycle of Product Ownership, starting with design work using UX methods like user journey mapping and other research.
5. With successes in tech debt retirement (item 2) and some new (small-ish) digital service developments (item 4), we'll take our success stories directly to our local government customers and partner with anyone willing to tackle their own opportunities for digital transformation, whether for internal processes or public-facing services.

Ready or not, here we go

Again, we don't know if all this will work. And we know some portions of our current team may even be turned off by this vision and approach.

But we know the alternative—the status quo—leads to professional development malaise, customers unwittingly heading into an inevitable tech debt collapse, and countless lost opportunities to serve our community better using contemporary digital platforms.

So we're moving ahead. Ready or not.

Have you taken a similar journey? Have any tips you can share? Please let me know—it's always great to hear from fellow professionals that have tackled similar challenges and how they've succeeded, or even where they may have failed.