Rapid software delivery is possible inside DoW — Software Factory 2.0 shows how

I co-founded Kessel Run, the Department of War’s (DoW) first software factory, with a simple mission: To continuously deliver valuable software that warfighters love. At our peak, we deployed five applications from concept to operations in an average of 124 days, reducing target development timelines by 85%. Section 31, the U.S. Space Force’s first software factory, deployed eight applications to operations in an average of 64 days and reduced conjunction analysis from three hours to 15 minutes.

These outcomes weren’t luck. They were proof that rapid software delivery is achievable inside DoW.

But those successes didn’t scale. Both organizations eventually succumbed to institutional gravity. The same patterns repeated: mission dilution, leadership turnover, millions spent building custom platforms instead of using superior commercial solutions, and acquisitions reverting back to staff augmentation. This wasn’t a failure of vision. It was a failure of system design.

At a time when software connects every domain—air, land, sea, space, and cyberspace—that’s a problem we can’t afford to repeat. Software Factory 2.0 (SWF 2.0) is designed to close those gaps. Not Agile reform, but a system reset built on one principle: optimize for learning fastest, not predicting perfectly.

The SWF 2.0 blueprint: Three imperatives

Senior leaders have three levers to pull to build on that principle:

1. Requirements. Replace multi-year forecasts with real-time discovery of operational friction. Instead of a five-year requirement for a “targeting system,” identify the bottleneck—like a three-hour targeting approval process. Set a goal—like reducing the approval process to 30 minutes. And empower a team to solve it. In this Kessel Run example, the requirement was an outcome, not a feature list.
2. Resourcing. Software doesn’t fail because of funding. It fails because of how funding is allocated. Replace large, multi-year obligations with small, high-performing teams funded through capacity-based models. Use quarterly “Growth Boards” to scale what works and shut down what doesn’t.
3. Acquisitions. Most programs still operate in a “water-scrum-fall” mode: Agile in the middle, bureaucracy at the ends. Shift to outcome-based contracts where vendors are accountable for mission impact, not hours billed, and replace staff augmentation with teams that own their products end-to-end.

The path forward

The standard for Software Factory 2.0 is simple: real software in production for real users.

Software has zero value until it is in the hands of those it’s meant to serve. Delivering early often reduces risk, shortens feedback loops, and drives better outcomes. But that only works if the system supports it.

That means founding leaders remain in place for eight to 10 years to preserve mission context, rather than rotating out every two to three years. It means enabling continuous delivery with a path to production and continuous Authorization to Operate, so delivery doesn’t stall with every update. It means using commercial platforms for undifferentiated heavy lifting so teams can focus on mission value. And it means empowering small, cross-functional teams to own outcomes from user research to production without competing mandates pulling them off mission.

Success is measured in delivery performance, user satisfaction, and mission impact. Not activity.

We know this works. The blueprint is clear. The time to act is now. Think big. Start small. Scale fast.

___________________________________________________________________________
Equip yourself with the tools for digital transformation with Rise8’s Free Mission O/S Course and this SWF 2.0 White Paper.