Bryon Kroger and Matt Nelson joined me on the Acquisition Talk podcast to talk about digital transformation in the Department of Defense. They are the CEO and COO of Rise8, a digital consulting company, and previously had leading roles in the Air Force’s Kessel Run software factory. In the episode, we talk about:
- Roper’s ‘There is no Spoon’ paper on the digital trinity
- Their take on the new DoDI 5000.87 Software Acquisition Pathway
- What it means for government to “own” the tech stack
- How Rise8 will support the Advanced Battle Management System
- Why entitlement funding is dangerous for organizations
Systems thinking
Here’s Bryon talking about Gall’s Law, which comes from John Gall. Bryon called him the Voltaire of systems engineering theory.
… complex systems are invariably found to have formed from small, simple working systems and the inverse propositions also true, complex systems can’t be built from scratch. You have to start over with working simple systems. The problem… is we have so much baggage and experience with things not integrating at the end that we assume that you have to design the whole system upfront. That’s the problem.
I think the requirements process plays a big role here. We often hear how “requirements stability” is necessary for program success. More and more planning goes into the front end to minimize uncertainty. Inevitably, there are integration problems and the acquisition folks blame unstable requirements. But the problem was that the development aimed to build a complex system from scratch, rather than tackling the essential requirements and iterating to a complex set of requirements.
Here’s Matt Nelson with a view on requirements:
We have to really get good and strong on how to do user centered design and develop requirements based off of that process. I’ve been an acquisition officer for 14 years and if I have a quarter for every time, the acquisition community blamed bad requirements is the reason why that the system’s not working, I’d be a rich man.
Software Acquisition Pathway
The DoD’s new Software Acquisition Pathway tailors the instructions for software programs to take advantage of agile development and devsecops. There is a fair amount of promise to it, allowing programs to use an alternative requirements process to the JCIDS, apply user centered design, support continuous releases, value assessments, and more.
As with anything new, there are some issues that have to be considered. Bryon points out that the term Minimum Viable Product has been abused in the DoD. In the instruction, an MVP cannot be released until it meets a Minimum Viable Capability Release, which has to potential to reenact waterfall requirements. Here’s Bryon:
For it to be a minimum viable capability, it has to have all these things and it’s just a new spec list. And instead I would argue that we should think of every release as a net value release.
… The user should be making decisions of is this net value to me? Not does it do these 20 things, but is it better than it was yesterday? The answer is yes, we should release it.
Matt takes a different angle:
The one negative that I have on the software acquisition pathway, it’s tailored for a single application. To get out into a production like environment, but it doesn’t have a lot of discussions or governance or guidance on how to turn that like single application into a systems of systems and do end to end integration test for a suite of applications that is solving an overall enterprise problem.
Defense acquisition invariably leads to thinking in terms of program stovepipes rather than networks of interoperable capabilities. In the 21st century, systems are less likely to be self-contained with well-defined boundaries. They not only interoperate in an enterprise architecture, they don’t have to be built from the ground up. A new software application doesn’t require a team to create its own cloud or platform solution — they can pay for that as a service.
Owning the Tech Stack
In Will Roper’s paper on digital acquisition, There is no Spoon, one of his principles was that the government should own the tech stack. I asked Bryon and Matt about what this meant to them. My takeaway was the following.
When we talk about government “owning” the tech stack, we first must talk about what the tech stack is. Here’s a nice chart from Matt:
The next thing to consider has two dimensions. First, which parts of the tech stack will be built as part of the software project, and which will be furnished to the project from an enterprise capability. Second, whether the government performs the work in-house or whether it contracts with a firm.
The way I understand their argument, particularly Bryon’s, the government has scarce software talent in-house. It should husband those resources and apply them to the application and data layers of the tech stack. Government personnel are, after all, the closest to the mission and requirements, especially for embedded systems. For business applications, commercial software as a service makes sense.
Further down the tech stack, Bryon argues that software infrastructure and platforms are below the value line, meaning government should contract for those solutions. Perhaps in the future when in-house software capabilities are stronger those areas will rise above the value line, but Bryon argues that multiple commercial offerings should be available for use. Instead of literally “owning” infrastructure and platform, government should own the technical baseline, purchase it from industry, and provide it as Government Furnished Equipment to the projects dealing in applications and data.
Listen to the podcast for an in-depth discussion on the topic.
Context is King
Bryon and Matt rightly put emphasis on building a 21st century workforce in the Department of Defense. The Air Force has gone from about 200 to 500 airmen doing developing software. At Rise8, they will come pair with government software developers, designers, product managers, and other positions, to provide them the technical knowledge to implement some of the great visions coming from leadership. Here are some wise words from Bryon:
When people lack context, we have to lead with control. The new model is freedom and responsibility in a devops world. You lead with context, not control. And we are severely lacking in context.
Entitlement funding
Bryon and Matt have a great way of taking innovative approaches and couching them in terms of existing JCIDS, acquisition, and PPBE processes. For example, see Bryon’s video Smuggling DevOps into the Worlds Largest Bureaucracy, or Matt’s article How the Clinger Cohen Act can accelerate your digital transformation. They have a compelling vision for acquisition metrics and governance, including use of the DORA metrics and growth boards. But one necessary aspect doesn’t quite fit in:
And I actually want to make it so that your funding’s [00:55:00] not guaranteed. This is the hard part. This [is] the only thing in our framework we recommend that requires a policy change, which is entitlement funding… The most dangerous things in an organization is entitlement funding. It doesn’t matter what you do. If an organization is entitled to their funding, they won’t change.
Here is Matt adding to that:
You should transition from funding specific products or specific problems to start funding teams.
Of course I’m a huge fan of budget reform along these lines. First, the DoD should do away with funding projects and outputs and instead fund teams and organizations. Second, the DoD should fund portfolios of teams/efforts within a single budget line item in order to allow for management by real options. The ability to route money to the highest value use ensures a competitive environment, rather than the present system of entitling a program to multi-year budgets that are extremely hard to affect except on the margins.
Thanks Bryon and Matt!
I’d like to thanks Bryon Kroger and Matt Nelson for joining me on the Acquisition Talk podcast. You can learn more about their new company Rise8 here, and about their previous program Kessel Run here.
Some books Bryon mentioned include Eric Ries’ The Lean Startup and Lean Analytics; John Gall’s Systemantics; Eliyahu Goldratt’s The Goal; and Nicole Forsgren et al’s Accelerate. Here’s more on the Air Force’s 2015 Own the Technical Baseline report.
Listen to Bryon on a number of podcast episodes: his exit interview on the Kessel Run podcast; Project to Product podcast; Pivotal Conversations podcast (and here’s another one).
Matt has a number of good articles on Medium, including a Manifesto for Agile Acquisitions; How to establish a new culture in agile software acquisition; and From CDRLs to Agile Services.
Watch Bryon’s YouTube videos, including Scale Leadership, not Technology; and Building a DoD Software Factory.
Leave a Reply