4 ms·
> Among the USAF's sins-according-to-Chaillan? The service is still using "outdated water-agile-fall acquisition principles to procure services and talent", Wa
by jrochkind1 5y ago
> Among the USAF's sins-according-to-Chaillan? The service is still using "outdated water-agile-fall acquisition principles to procure services and talent",
Wait, what?
- _bnmd 5y agoIt's not explained, but I know exactly what he means. We mandate that development teams and integrated product teams have to use agile methods, but the procurement process itself is inherently not agile. Contracts come with fixed dollar amounts, milestone delivery dates, and requirements that need at least signoff from senior agency officials to change and possibly acts of Congress. Further, the way your "customer" is always an acquisition office rather than actual users of your system, developers can't receive, solicit, or respond to direct feedback from users, which is a pretty basic core tenet of agile development, without which it's hard to see how it can ever work.
- ethbr0 5y agoThis. If you want to read more into the precise ordering of the neologism, it's agile sandwiched in the middle of waterfall. Which is to say, the upstream and downstream didn't change how they do things at all, and somehow developers acting differently is supposed to convert everything to agile. Or to put it another way, this is what you get when you tell everyone they need to "do agile" without actually retraining people on what that means and update processes to enable it. Source: experience with healthcare "agile" and "sprints"
- AnimalMuppet 5y agoStronger: Somehow developers acting differently without the inputs that agile processes require is supposed to convert everything to agile. And somehow it never does...
- panzagl 5y agoIn practice most contractors end up hiring a bunch of former users to act as stand-ins for the real operators. These former users then get to engage in continual pissing matches with the acquisition office over how things really get done. Hilarity ensues.
- tablespoon 5y ago> Which is to say, the upstream and downstream didn't change how they do things at all, and somehow developers acting differently is supposed to convert everything to agile. Sounds like my corner of the private sector.
- Pokepokalypse 5y agoI know the solution! Hire a scrum-master! that will fix it.
- dragontamer 5y agoThe full paragraph reads: > The DoD is still using outdated water-agile-fall acquisition principles to procure services and talent instead of leveraging “Capacity of work” agile contracts to staff teams. Improving acquisition ensures teams have the ability to groom their backlog and move at the pace of relevance. Only Platform One, and teams like Kessel Run, are truly end-to-end agile, from what I have seen to-date. I don't know what "water-agile-fall" is exactly, but he's probably talking about some terms in the Air Force. Maybe he means that the waterfall model still exists, and a bunch of people are trying (unsuccessfully) to convert to agile. But he's only seen Agile properly happen in a minority of projects.
- jrochkind1 5y agothat is somewhat clarifying! Still trying to wrap my head around "to procure service and talent" with regard to agile/waterfall.
- mpyne 5y agoHe'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'.
- markdjacobsen 5y agoHN has two threads on this now. I just replied on the other but will copy here: I can't speak for Chaillan, but as a military member who led an agile software development team similar to his during the same timeframe, I think he's referring to DoD's fondness for buzzwords. Because "agile" is the new hotness, every DoD office and vendor tries to slap the language of agile onto a waterfall model. See this wonderful report from the Defense Innovation Board on "Detecting Agile BS": https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB_DETECTING_AGILE_BS_2018.10.05.PDF https://media.defense.gov/2018/Oct/09/2002049591/-1/-1/0/DIB...
- Ziggy_Zaggy 5y agoDo you might linking the other HN thread?
- markdjacobsen 5y agoOther thread: https://news.ycombinator.com/item?id=28407219 https://news.ycombinator.com/item?id=28407219
- Ziggy_Zaggy 5y agoMuch appreciated.
- bink 5y agoI presume he means they're claiming to be agile while really continuing to use a waterfall process for deploying software. They create specs, hire a vendor, do regular reviews before testing, approvals, deployment, provide specs for changes, pay for those changes, test, approvals, deploy, and then repeat.