Most government software programs that fail never had a software problem. They had an acquisition problem.
Bryon Kroger, founder and CEO of Rise8, traces his career path to a single incident. As a U.S. Air Force intelligence officer running targeting operations, he investigated a software failure and traced it back to requirements written eight years earlier. Development finished a year before the incident. The software was complete but sat awaiting Authorization to Operate (ATO).
“I felt like the acquisition process in this case actually got people killed,” Kroger said at a recent AFA panel on acquisition reform.
That experience led him from operations into acquisitions, where he co-founded Kessel Run—the DoW’s first software factory—and later, to founding Rise8.
His argument, laid out in the Software Factory 2.0 whitepaper is direct: the way the Department of War acquires software is structurally mismatched to how software is built and delivered. The tools to fix it exist, but most acquisition offices do not use them.
You can’t change a system you don’t understand.
Kroger’s first principle is that meaningful reform requires understanding the existing system well enough to work within it.
At the AFA panel, he described how Kessel Run deliberately framed early programs to resemble traditional DoW 5000 acquisition pathways, complete with familiar milestones. The difference was in execution. Venture capital-style growth boards focused on outcomes replaced milestone reviews.
“We made it look exactly like the old thing,” he said. “Communicating in the language of the existing system can help you move through it.”
He cited acquisition reform author Dan Ward, whose writing on Federal Acquisition Regulation (FAR) interpretation is a reference in the acquisition innovation community: “Ignorance of the FAR is a greater barrier to innovation than the FAR itself.” The implication is that the FAR already provides more flexibility than most organizations realize.
The deeper issue is structural. Kroger describes it as “water-scrum-fall”—agile development constrained by rigid, bureaucratic processes on both ends. Teams may run sprints internally, but contracts are still negotiated over 12 to 18 months using processes designed for hardware. Requirements are locked before interacting with users. Progress is measured in documents rather than working software. By the time systems receive authorization, mission needs have already evolved.
Early software factories demonstrated what is possible with reduced acquisition constraints. Kessel Run deployed five applications to operational use in an average of 124 days, reducing target development timelines by 85 percent. Section 31, the Space Force’s first software factory, delivered eight applications in an average of 64 days, reducing conjunction analysis timelines from three hours to 15 minutes.
Both proved the DoW can deliver at mission speed with innovative acquisition. But early wins were not sustainable. Leadership rotations disrupted continuity. Teams were redirected to unrelated missions. Contracts reverted from outcomes-based delivery to staff augmentation.
“The same repeatable, avoidable patterns undermined both software factories,” the SWF 2.0 whitepaper concludes.
Cancel failing contracts
Kroger’s first recommendation is straightforward: cancel failing contracts.
“Programs of record is a very loose term,” he said. “Program dollars are tied to requirements, not contracts. If you have a failing contract, that is not a program of record. That is a contract, and you should cancel it.”
He also advocates for aligning multiple budget activity codes under a single program element to enable flexible funding across a portfolio. This allows resources to shift toward successful efforts and away from underperforming ones, guided by quarterly growth boards.
The SWF 2.0 framework formalizes this approach through a three-horizon investment model: 75 percent to capabilities already in production, 15 percent to prototypes ready to scale, and 10 percent to high-upside exploratory efforts.
Contracts should measure outcomes, not activity
The whitepaper calls for a shift from activity-based contracting to outcome-oriented delivery.
Structure contracts around mission value streams using domain-driven design rather than organizational charts. Favor delivery teams over staff augmentation. Measure success by software in production that delivers mission impact.
“Efficiency without efficacy is waste,” Kroger said at the panel. “You’re doing a thing really well that shouldn’t be done at all.”
He argues the DoW remains in an exploratory phase, attempting to identify what works, yet continuing to apply exploit-phase metrics such as cost, schedule, and earned value to programs that have not yet proven they can deliver anything to production.
His standard: get to production in 180 days or less, then achieve continuous software delivery on a weekly cadence. Measure performance using DORA metrics—deployment frequency, lead time, mean time to restore, and change failure rate—alongside mission-specific indicators. If the software is not in production with real users and real data, learning does not occur.
The statutory tools already exist
The mechanisms for faster, more effective software acquisition are not hypothetical. Other Transaction Authorities, FAR Parts 12 and 13, and SBIR Phase III have been available for years.
Rise8 holds an AFWERX Software Delivery Organization (SDO) IDIQ awarded under SBIR Phase III authority. Under 15 U.S.C. Section 638, the original Phase I and Phase II awards satisfied the competition requirement. Task Orders issued under this authority do not require new competition, Justification and Approval (J&A), market research, or public notice. The vehicle has a $499 million ceiling, is open to any federal agency, and enables contract award in approximately 30 days.
The Department of Veterans Affairs used this vehicle to become the first non-DoW agency to achieve continuous ATO, reducing authorization time from 568 days to 90 days. The Space Force increased scheduling throughput by 20 percent and saved more than 34,000 hours. The Air Force brought 12 applications into full CYBERCOM compliance and recovered more than 1,000 developer hours.
Accelerating acquisition is not about speed alone, but delivering capability at the speed missions demand.
Rise8 published a free IDIQ Acquisition Handbook outlining the statutory basis, procurement process, and key considerations for acquisition teams. Read the full IDIQ overview or request a call here.