He's talking about how you contract for additional staff to help with developing digital products.
Typically the way government does this is by not contracting for staff at all, but instead contracting for a company to develop a software product that meets a long laundry list of requirements. Since 'agile' is in the DoD zeitgeist these contracts often throw in some agile buzzwords like "Story points" instead of "work breakdown structure", or split up the product into some kind of phased delivery scheme. Sometimes they'll throw in to do user-centered design.
But invariably these contracts lay out the same thing: develop a product that meets X requirements. This means you have to know the requirements. You can't instead hire smart people to help explore a problem space, do interviews and experiments to determine whether you've achieved product-market fit (or what we'd call mission-market fit), and only then to start fielding a digital product in increments.
This is considered a 'services contract' and these are frowned upon because they seem ripe for fraud ("you paid BigCo $40 million a year to do 'market research and product discovery'????? What did they discover? Why couldn't it have been $20M instead??").
TL;DR: The type of services you'd contract for are different for a modern digital product compared to a waterfall-style project. Even though DoD says we're doing agile, the reality is that the contracting system still pushes you hard to waterfall because no one seems to have the expertise to do 'agile acquisition'.