I was on an industry panel at the ACT-IAC DevOps Forum a few weeks ago. The first question the moderator asked was, “From your industry perspective, what could the Federal Government do to increase the adoption of DevOps?” The moderator and panelists had a prep call a couple of days prior to the event so I had a chance to think about my answer in advance. I chose to let loose on something I would like to see in federal contracting (the first one in my wish list below). After the event, I thought about more contracting approach changes I would like to see adopted by more agencies.
1. Specify elite-level expectations for key software delivery metrics.
This was the one I shouted out from the stage at the event. The Accelerate State of DevOps Report established four software delivery metrics that distinguish high-performing organizations from their non-high-performing peers: deployment frequency, lead time for changes, mean time to recover (MTTR), and change fail rate. The 2018 report introduced a new top performance level: elite. Elite performers deploy on demand multiple times a day with lead times less than a day, restore service in less than an hour on average, and have failed changes to production less than 15% of the time. We know the private sector is getting these results. Just check out the experience reports from the DevOps Enterprise Summits. There are even some examples in the Federal Government.
Why aren’t we demanding this level of performance from service providers to our nation?
2. Specify expectations for continuous improvement.
We know from the State of DevOps Report that high-performing organizations keep getting better. That’s one way they stay ahead of the competition. We also know that if we write something into a contract today as “best practice” (my view on “best practices” will be the subject of another post), that “best practice” is at risk of becoming outdated tomorrow because of the discovery of a “better practice”. Even specifying the software delivery metrics at the elite level is insufficient (see first point), because the elite level will change over time. We want to encourage continuous improvement in how we work.
The Federal Government should expect the service it receives to keep getting better.
3. Use modular contracts and multiple awards.
A federal contracting officer recently asked me, “How do I hold a contractor accountable for delivery?” The question was from the perspective of trying to write a better, clearer contract that would help do this. My response to him was, “Fire the contractor if they don’t deliver.” The problem with firing a contractor is most agencies have spent a lot of time and effort to get the contract done — months, quarters, even years in some cases. They’re hesitant to go back to square one. I get it. Under the circumstances, they’d rather deal with the devil they know rather than the devil they don’t. So let’s reduce the time and effort and risk associated with contracting so we make it easier to fire contractors that aren’t delivering and double down on the ones that are. If the Federal Government used smaller, shorter, modular contracts and awarded them to multiple companies, they would have more frequent evaluation points both on what they needed and which contractors were delivering it. I also know that the work involved to issue smaller contracts is (you guessed it) a lot less time-consuming and burdensome. So the lean principle that works in manufacturing and software development (namely, smaller batch sizes) also works for contracting.
Why are agencies still using large, slow, risky contracting approaches that ultimately don’t deliver what they need or want?
4. Specify the desired business outcome — not detailed system requirements.
If we’ve learned anything from waterfall software development, we’ve learned that doing “big requirements up front” doesn’t work. Why are we still doing this with contracts? Instead of specifying detailed requirements in a long contract, lay out the desired business outcome (e.g., smaller case backlog, higher citizen satisfaction, shorter cycle times on grant decisions) and preferably a couple of business-oriented metrics to monitor to know we’re moving in the right direction. Getting the outcome is the real goal, anyway. Then fund the contract as long as you’re getting the outcomes you want for the investment you’re making. If you aren’t, stop funding the contract (see previous point). Another benefit of this approach is opening up possibilities for creative solutions that could produce the outcome more efficiently and effectively.
Why is the Federal Government putting adherence to detailed requirements over getting the business outcome those requirements are intended to produce?
5. Use “show me, don’t tell me” evaluations.
I’m actually seeing this technique used a lot more over the last several years (thankfully). Instead of merely writing words and drawing polished pictures in a document, companies need to “walk the talk” by demonstrating their experience and approach in practice. This demonstration could take the form of building a prototype to submit as part of a proposal, a one-day technical challenge, or even just a whiteboard discussion about how the company would solve a particular problem. Regardless of the form, this evaluation approach separates companies that merely talk a good game from the ones who can actually back it up with real experience.
Why is the Federal Government taking the risk that a company’s practitioners can’t deliver what the proposal shop promised?
There are examples of all of these approaches across the Federal Government, to one degree or another. It’s not a question of whether they’re possible or even allowed by the FAR. We know they are. Now it’s a question of how fast agencies will adopt these approaches to get better outcomes for themselves and for our nation. We need better. We can get better. Our nation deserves it.