Army wants more agile approach to software, including how it buys it

The Army is in the midst of a big push to modernize its software development processes, and not just talking about the code-writing part. Its agreements with industry might be about to change in significant ways as the service tries to make its contracting for software as agile as the development process itself.

The Army planted a major flag in the ground to define its future software practices back in March, when the service published a new directive ordering the embrace of modern methodologies. Some of the big focus areas: agile development with a more nimble requirements process, continuous teaming between users and developers, an emphasis on agile development and a new center of excellence to update the Army’s acquisition processes for software.

Army officials say they’re already working to inculcate agile principles within their own organizations, but that they also need a new contract vehicle to buy software from industry – or pay vendors to build from the ground up. That contract is expected to be worth more than $1 billion over the next 10 years. The Army is still building the request for proposals with input from industry, but it’s expected to be an unusual approach: An indefinite-delivery/indefinite quantity contract, with contract types determined at the task order level, ranging from firm fixed price to time and materials.

“Every contract needs to be tailored to the task, and it’s not a simple world of cost-plus versus fixed-price,” Doug Bush, the assistant secretary of the Army for acquisition, logistics and technology told reporters during a recent media roundtable. “Those are ends of a spectrum. In between those things lies a vast array of hybrid approaches that are tailored to different things. So this is a very complicated thing that cannot be simplified into a binary cost or fixed price narrative.”

That “tailoring” is unusual on IDIQ contracts, however. Often, when the government wants the flexibility to determine things like contract type on individual projects, officials will solicit the work through full and open competition. IDIQs, meanwhile, usually determine most of those details in advance when contract holders earn spots on the contract, so task orders can be awarded quickly.

Speeding the award process

The Army’s objective, with its admittedly novel approach, is to combine the best of both worlds.

“The first goal is speed. Having a vehicle established will allow us to go faster on task orders than doing a de-novo contract in every case, which I think is better for industry,” Bush said. “What we’ve seen without this approach is that all of our program executive offices have to do their own separate competitions for different software development, each a little bit different way, and it’s just — we hope — more efficient to have a vehicle they can use to go faster.”

So far, industry’s views on whether that “hybrid approach” to an IDIQ can work appear to be mixed. The Army has issued two requests for information so far and gotten feedback from 188 companies. 93% agreed with how the Army is thinking about the overall scope of the contract, which will range from commercial-off-the-shelf software to highly-customized development work. But only 53% of companies agreed with the idea of determining contract type at the task order level.

Nonetheless, the Army is considering taking the notion a step further: letting vendors who win spots on the IDIQ propose their own contract types as part of their bids for each task order.

“We would evaluate your solution and your proposed contract type, and they should match,” said Jennifer Swanson, the deputy assistant secretary of the Army for data engineering and software. “The reason to do that is so that we are able to consider all solutions that are out there. There may be a commercial solution we’re not aware of, and this would allow a company to bring that forward with say, a firm fixed price contract type that would make sense for a commercial solution, as opposed to what we traditionally do, which is we say this is either commercial or it’s not commercial. This would allow us to get more competition and more insight on what’s out there.”

But Swanson emphasized that the possible choose-your-own-contract-type approach isn’t set in stone. In fact, nothing is. The Army says it’s continuing to revise the draft RFP in response to industry feedback.

Still gathering industry feedback

The latest change happened just a few weeks ago, after vendors raised concerns about the Army’s planned approach to labor rates.

“Somebody wrote a comment on LinkedIn that pointed out that we had inadvertently included labor categories that have all of the education requirements and things that we’ve always used, but that don’t really make any sense anymore. It’s limiting, and it’s not what we want,” Swanson said at AFCEA’s TechNet conference in Augusta, Georgia last month. “So we revised the draft RFP, but also, we need help from industry [on that issue]. I don’t think that saying we’re going to pay ‘X’ for a bachelor’s in this and ‘Y’ for a master’s in this makes any sense in this space. But what does make sense? That’s something that we are looking for feedback on from industry.”

One more promised area of flexibility, officials say, would add frequent on-and-off ramps to add and remove vendors over the up-to-10-year period of performance. And whatever the $1 billion contract vehicle ends up looking like, officials emphasize it won’t be the only way the Army buys software: it won’t be mandatory use and other contract vehicles will still be allowed to exist.

Internal moves to Agile

Meanwhile, Army acquisition organizations say they have already been managing to move their practices to agile methodologies internally too, without the new IDIQ.

Bill Hepworth, the program executive officer for enterprise information systems, said his organization has been on a journey to transition all of its programs to agile processes since a year and a half ago, when it settled on the Scaled Agile Framework (SAFe).

“What it started doing was giving us a common language to talk from the program level all the way down into the tech teams,” he said. “It also allowed us to integrate the tech teams and the program levels to start communicating, especially with our functionals, and aligning the priorities inside of each program so that we can go after the highest-value targets up front.”

Hepworth said it was a heavy lift at first, when PEO-EIS first set up its own hub to lead its agile transition: the Lean Agile Center of Excellence.

“Aric Sherwood, who was running that for us, referred to it accurately as the Lean Agile Center of Mediocrity in its first couple of go-rounds, because we struggled to transform from waterfall to agile,” he said. “But what we’ve been able to do now is really systemically go across our entire portfolio and, at the very least, enforce SAFe principles. And most of the programs now are operating under full agile, where we’re doing two-week sprints, we’re doing product increment planning, we’re actually working and collaborating with our functionals now, and they’re joining the journey. That is one of the big keys, because if your functionals aren’t on board, you’re going to have a really tough process ahead of you. This year, we’re trying to transition and go even further down the path of DevSecOps. We want to start doing automated builds, automated deployments, automated testing. That’s key. It’s a big push this year, and I’m happy to say that we’ll have that up in operation in the next couple months and that will become standard across the organization.”

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.