That's the solution, full stop. The right support and the right people. A "sprint" is just a mechanism, it's useless without the right people.
So maybe that's the problem the government has? It's not the process, it's the people!
What characteristics would you ascribe as 'typical' among the nearly 2,800,000 federal government employees? What do think of the engineers at NASA? The biologists and mathematicians working on the human genome project? What character traits do you think are shared by Park Rangers fighting fires and educating people about the value of wilderness in Yosemite, and FBI Agents working undercover to investigate organized crime?
I'm genuinely curious.
And I speak with some experience here. In the early 90's I taught a class about Microsoft Solutions Framework to a group of government IT people, and they were less than thrilled to have to learn a new way of doing things. MSF is a slightly agile process, more so than many others at the time, nothing like XP or even Scrum though. They had been using a waterfall process for a long time and were just fine with it.
While one class doesn't automatically mean that everyone in government IT is that way, from my experience in consulting with several government agencies and other large companies, there are a lot of people who don't want to change. I think that many people who have never had to work in that environment don't realize how it is, certainly nothing like a startup - and I've also worked at a startup in the past as well.
Got it.
Process is the biggest issue not people.
The kinds of folks that stay at jobs for 20+ years and retire are very, very different from the HN style job hopping motivated go-getters and it impacts work output drastically in large numbers. DC has a lot of the really motivated types, but they are oftentimes not doing the tech work.
I've been a federal employee, contractor, employee of F500 companies, small regional company, two-person start-up, and start-up employee for some frame of reference.