7 ms·

U.S. Department of Defense – Detecting Agile BS [pdf] (2018)

122 points by rareitem 2y ago

deleted 2y ago
[deleted]
bluefirebrand 2y ago
I love this document. I'm absolutely going to be sharing this around a bit at my company
- wiradikusuma 2y ago
  Share the link, not just the PDF, to give more legitimacy ;)
  - galangalalgol 2y ago
    I strongly dislike it on one count. It actively promotes using the choice of tools as a marker for "true agile". They go so far as to reword the first item to exclude any references to tools. I have seen plenty of groups using all the right tools, full of individually skilled developers, producing garbage late to schedule. The reason is that they did not interact with each other in a way that lead to success. They drew lines about whose problem things were and then used them to assert problems weren't theirs. They set up their own (or modified shared) interface documentation and let it be out of synch with what the other end specified. And on down the line. Tools can help, sometimes. But if someone is using cvs or subversion instead of git, I'm not going to label them as nonagile. If they didn't pick c++'s build system of the week, that doesn't meen the product isn't quality.
    - wiradikusuma 2y ago
      Reminds me of a slide made by armchair architect in the previous company I worked for :)
      - galangalalgol 2y ago
        I am inclined to think there was some incentive to formally support those tools with the paper. Maybe nothing as blatent as free trips and meals, but who knows.
simondanerd 2y ago
Sharing this link to a buddy... He's a "full stack web developer" for the US Army and can't make an HTML page but sure can do "npm run start".
- SirGeekALot 2y ago
  Yikes! NPM can be an attack vector if you don't understand how it works and what it does.
pylua 2y ago
This document has no teeth. It is more simple than this … does it have fixed scope and fixed timeline ? If so it’s not agile.
- havkom 2y ago
  The document vibe to me is like it is written by some junior engineers who have just read a blog post about the Netflix stack and think they know it all now.
- nyrikki 2y ago
  It is part of an effort that will have impact. Remember that the US federal government is the largest IT spender in the world. This is part of their efforts to move agencies internally I using a carrot first. Now that the GAO officially released an agile audit guide, the stick is in place. GAO Agile Assessment Guide https://www.gao.gov/products/gao-24-105506 https://www.gao.gov/products/gao-24-105506 Note that in the public sector, appropriation committees have the power, and see how they are targeting states here. https://guides.18f.gov/derisking/state-field-guide/budgeting-tech/ https://guides.18f.gov/derisking/state-field-guide/budgeting... TOGAF, ITIL and the other crusty frameworks all had to take steps to modify their long held dogma over the past few years. I would give it another 5 or 10 years or so before federal funding to even states depends on compliance. Remember that the military moved away from Taylorism to mission command a long time ago. This is moving IT the same way. If you have or aspire to have government contracts it is probably a good idea to pay attention. Note how that 18f page links to the above document and goes farther, saying that if there is a single individual who can insist on a Gannt chart , you aren't 'agile' There is two centuries of experience in the military setting, with only about 70 in the biz world, the feds are quite clear that they won't wait for IT.
  - 2OEH8eoCRo0 2y ago
    They're right though- teeth means enforcement. These DOD recommendations/guidelines aren't worth the paper they're printed on if they aren't don't make into the contracts.
localfirst 2y ago
color me paranoid but clicking a pdf from defense.gov feels wrong but I want to read this so bad lol
- deleted 2y ago
  [deleted]
- CoastalCoder 2y ago
  I think you're paranoid. Seriously, I can't imagine a plausible threat from downloading that.
  - localfirst 2y ago
    I envy you.
havkom 2y ago
First parts of the document are pure BS focusing on hype technologies rather than “Agile”. I mean, questions about ”Kubernetes or Docker Swarm?” etc. The last section with flow chart is good though.
- polemic 2y ago
  They aren't "hype" technologies - but it does seem badly framed. If it were to say "the team uses version control, CI frameworks, agile tracking tools then they might be agile" it would make more sense. That would be especially useful if , say, much of their existing softare is delivered once a month via zip files on an ftp server.
  - havkom 2y ago
    Using these technologies or frameworks may just as well indicate that they are not agile. Nowadays much more common that the wrong technologies are used in the wrong places.
doctor_eval 2y ago
While this document starts strong and has some good points, it strongly conflates “scrum” with “agile” and goes downhill pretty quickly. > wrong answer: what’s a sprint cycle? You don’t have to have sprints to be agile. What’s important are the four values. The manifesto says, “Individuals and interactions over process and tools” but this document then goes on to talk a lot about specific processes and tools. It’s a trap!
- sirwhinesalot 2y ago
  A trap every freaking "Agile" company falls into. Don't get me started on fixed scope + fixed timeline that they all still do anyway, only now broken into "sprints".
bane 2y ago
The fact that this had to be produced, reviewed (probably by lawyers) and cleared for open publication is a sign that the DoD has recognized that it's wasting a lot of time and money paying teams to make things that help the DoD...and not getting it -- despite agile's promise of delivering working software to users ever iteration. The document contains and is a symptom, the root cause analysis of why this document exists should be next. Reading between the lines, there's lots of complaining here about teams working with people who aren't users and having no mechanism to reach users. I suspect that there is a very large "cottage" industry of companies that basically sit between teams and end-users and act as "intermediaries" and basically just siphon tax dollars into their quarterly revenue reporting while breaking the connection between teams and users, guaranteeing successful software is never delivered, and making sure that software efforts essentially go on forever or are restarts of previously failed efforts.
alexfromapex 2y ago
It feels like we’re getting closer and closer to Idiocracy with these published government articles where the title lacks decorum
- mckn1ght 2y ago
  Actually I think that overcorrecting for decorum is taking us to Idiocracy faster. It’s right there in the name: we need to stop coddling idiots, grifters and otherwise unqualified people that work their way into positions of power. Agile gives these types of people nearly limitless recourse to maintain their grip (although it is not solely Agile’s fault, it’s the broader culture).
nvr219 2y ago
Can they make one for AI please?
jiveturkey 2y ago
Maybe there's some assumed context, but this doc doesn't clarify whether agile is actually desirable or not, for any given project. If it doesn't matter, say if there is a fixed budget for example, then ... who cares what the team calls their process. Lovely: > Are teams empowered to change their process based on what they learn? No -> Agile BS
dzonga 2y ago
ahh agile, what every tech company likes to say they adhere to. the church of agile. yet it feels to deliver good quality software on predictable timelines. agile is simply a way to cover management's ass and shift blame to programmers or other stakeholders. worse more with microservices or more appropriately "distributed monoliths" you can easily shift the blame to - the other team has been blocking our progress since we need an api they provide. seen this playout so many times at $lastjob.
- rqmedes 2y ago
  Image delivering a race car to a customer via Agile, starting with first delivering a bicycle
- jopsen 2y ago
  Is that such a bad idea: > 37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame.
pjmorris 2y ago
Warning in the article: > "Meeting requirements is treated as more important than getting something useful into the field as quickly as possible." I've got a bad feeling about this. It seems like the kind of attitude that leads to last Friday's Crowdstrike update.
- deleted 2y ago
  [deleted]
- galangalalgol 2y ago
  I see where you are headed, and certainly unscrupulous entities will it as an excuse to cut corners, but I think they are talking about the case where someone produces something that will clearly not work, while still meeting the letter of requirements. Having good requirements is important, but making them is iterative as well, and having to treat software developers like an evil DM when you are casting the wish spell is not ok.
  - pjmorris 2y ago
    Yes, I agree with 'Working software over comprehensive documentation.' It's that 'working' part that sometimes depends on getting the requirements right.
- kevinmchugh 2y ago
  I think there's domains where rigorously establishing requirements ahead of time is necessary and creates better outcomes than shipping quickly and iterating. Especially safety-critical domains. If your product can kill someone (either on failure or success), defining expectations, behaviors, and specifications ahead of time is responsible. I really like this article, about the space shuttle dev teams: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
- deleted 2y ago
  [deleted]
jiveturkey 2y ago
(2018)
rqmedes 2y ago
Disappointed, I was hoping they came out with Agile is BS. Which it mostly is.
travisgriggs 2y ago
Just identify your "gatekeeper" points. If you have lots, there's no way you're really doing any form of agile.
aetherspawn 2y ago
Agile can be waterfall-like when the minimum viable product is otherwise too large to avoid waterfall analysis paralysis. For example, zonal controller for an electric .. tank. Under relaxed Agile you would deliver a high-level plan (module architecture) as a deliverable, and then do JIT design of each module as a deliverable followed by implementation as a deliverable. If you follow guru agile for this and deliver 1 feature at a time, it will take 10 years to get your desired feature set. Because you’ll rework and refactor each module 100 times, followed by tear up and tear down of physical testing, 100 rounds of regression testing…
the__alchemist 2y ago
Meanwhile, in order to deploy web-based software in the USAF, you need to use something called Platform One, due to something called a "Continuous Authority to Operate (ATO)". Platform One has a baby Yoda, and it is Agile to its core. The whole thing is based on the Agile core concepts like TDD, pair programming etc, and it uses "DevSecOps". This means is it is a huge time commitment just ticking the various boxes. There's something called a "pipeline", which is a set of many third party tools that all have to pass various arbitrary metrics. The pipeline breaks at arbitrary point at arbitrary times, and only Platform One team members are allowed to fix it.
strken 2y ago
It annoys me a bit that "it depends how you define a programmer" is a wrong answer. "12 full-time software engineers, 4 data scientists who touch the SQL reports sometimes, and we contract out some front-end UI work plus we have a full-time email marketing guy who does HTML templates" would be better, but that's still just a more complicated way of saying "it depends".
deleted 2y ago
[deleted]
johnbellone 2y ago
The additional documents that are linked in the footnotes are great, too. https://media.defense.gov/2018/Apr/22/2001906836/-1/-1/0/DEFENSEINNOVATIONBOARD_TEN_COMMANDMENTS_OF_SOFTWARE_2018.04.20.PDF https://media.defense.gov/2018/Apr/22/2001906836/-1/-1/0/DEF... https://media.defense.gov/2018/Jul/10/2001940937/-1/-1/0/DIB_METRICS_FOR_SOFTWARE_DEVELOPMENT_V0.9_2018.07.10.PDF https://media.defense.gov/2018/Jul/10/2001940937/-1/-1/0/DIB...
neilv 2y ago
The title made me suspect it was about Here's some signs that Agile buzzwords and rituals are being used as a smokescreen for project crisis, organizational dysfunction, and team capability deficit. And I was all ready to high-five them. But it seems to start with the implicit assumption that Agile is good, and non-Agile is bad, and the information is some almost off-the-cuff notes on their own particular definition of Agile.
deleted 2y ago
[deleted]
ChrisArchitect 2y ago
Previous discussion: 1 year ago https://news.ycombinator.com/item?id=34957523 https://news.ycombinator.com/item?id=34957523 4 years ago https://news.ycombinator.com/item?id=23962722 https://news.ycombinator.com/item?id=23962722

122 points by rareitem 2y ago

deleted 2y ago

[deleted]

bluefirebrand 2y ago

I love this document. I'm absolutely going to be sharing this around a bit at my company

wiradikusuma 2y ago
Share the link, not just the PDF, to give more legitimacy ;)
- galangalalgol 2y ago
  I strongly dislike it on one count. It actively promotes using the choice of tools as a marker for "true agile". They go so far as to reword the first item to exclude any references to tools. I have seen plenty of groups using all the right tools, full of individually skilled developers, producing garbage late to schedule. The reason is that they did not interact with each other in a way that lead to success. They drew lines about whose problem things were and then used them to assert problems weren't theirs. They set up their own (or modified shared) interface documentation and let it be out of synch with what the other end specified. And on down the line. Tools can help, sometimes. But if someone is using cvs or subversion instead of git, I'm not going to label them as nonagile. If they didn't pick c++'s build system of the week, that doesn't meen the product isn't quality.
  - wiradikusuma 2y ago
    Reminds me of a slide made by armchair architect in the previous company I worked for :)
    - galangalalgol 2y ago
      I am inclined to think there was some incentive to formally support those tools with the paper. Maybe nothing as blatent as free trips and meals, but who knows.

simondanerd 2y ago

Sharing this link to a buddy... He's a "full stack web developer" for the US Army and can't make an HTML page but sure can do "npm run start".

SirGeekALot 2y ago
Yikes! NPM can be an attack vector if you don't understand how it works and what it does.

pylua 2y ago

This document has no teeth. It is more simple than this … does it have fixed scope and fixed timeline ? If so it’s not agile.

havkom 2y ago
The document vibe to me is like it is written by some junior engineers who have just read a blog post about the Netflix stack and think they know it all now.
nyrikki 2y ago
It is part of an effort that will have impact. Remember that the US federal government is the largest IT spender in the world. This is part of their efforts to move agencies internally I using a carrot first. Now that the GAO officially released an agile audit guide, the stick is in place. GAO Agile Assessment Guide https://www.gao.gov/products/gao-24-105506 https://www.gao.gov/products/gao-24-105506 Note that in the public sector, appropriation committees have the power, and see how they are targeting states here. https://guides.18f.gov/derisking/state-field-guide/budgeting-tech/ https://guides.18f.gov/derisking/state-field-guide/budgeting... TOGAF, ITIL and the other crusty frameworks all had to take steps to modify their long held dogma over the past few years. I would give it another 5 or 10 years or so before federal funding to even states depends on compliance. Remember that the military moved away from Taylorism to mission command a long time ago. This is moving IT the same way. If you have or aspire to have government contracts it is probably a good idea to pay attention. Note how that 18f page links to the above document and goes farther, saying that if there is a single individual who can insist on a Gannt chart , you aren't 'agile' There is two centuries of experience in the military setting, with only about 70 in the biz world, the feds are quite clear that they won't wait for IT.
- 2OEH8eoCRo0 2y ago
  They're right though- teeth means enforcement. These DOD recommendations/guidelines aren't worth the paper they're printed on if they aren't don't make into the contracts.

localfirst 2y ago

color me paranoid but clicking a pdf from defense.gov feels wrong but I want to read this so bad lol

deleted 2y ago
[deleted]
CoastalCoder 2y ago
I think you're paranoid. Seriously, I can't imagine a plausible threat from downloading that.
- localfirst 2y ago
  I envy you.

havkom 2y ago

First parts of the document are pure BS focusing on hype technologies rather than “Agile”. I mean, questions about ”Kubernetes or Docker Swarm?” etc. The last section with flow chart is good though.

polemic 2y ago
They aren't "hype" technologies - but it does seem badly framed. If it were to say "the team uses version control, CI frameworks, agile tracking tools then they might be agile" it would make more sense. That would be especially useful if , say, much of their existing softare is delivered once a month via zip files on an ftp server.
- havkom 2y ago
  Using these technologies or frameworks may just as well indicate that they are not agile. Nowadays much more common that the wrong technologies are used in the wrong places.

doctor_eval 2y ago

While this document starts strong and has some good points, it strongly conflates “scrum” with “agile” and goes downhill pretty quickly. > wrong answer: what’s a sprint cycle? You don’t have to have sprints to be agile. What’s important are the four values. The manifesto says, “Individuals and interactions over process and tools” but this document then goes on to talk a lot about specific processes and tools. It’s a trap!

sirwhinesalot 2y ago
A trap every freaking "Agile" company falls into. Don't get me started on fixed scope + fixed timeline that they all still do anyway, only now broken into "sprints".

bane 2y ago

The fact that this had to be produced, reviewed (probably by lawyers) and cleared for open publication is a sign that the DoD has recognized that it's wasting a lot of time and money paying teams to make things that help the DoD...and not getting it -- despite agile's promise of delivering working software to users ever iteration. The document contains and is a symptom, the root cause analysis of why this document exists should be next. Reading between the lines, there's lots of complaining here about teams working with people who aren't users and having no mechanism to reach users. I suspect that there is a very large "cottage" industry of companies that basically sit between teams and end-users and act as "intermediaries" and basically just siphon tax dollars into their quarterly revenue reporting while breaking the connection between teams and users, guaranteeing successful software is never delivered, and making sure that software efforts essentially go on forever or are restarts of previously failed efforts.

alexfromapex 2y ago

It feels like we’re getting closer and closer to Idiocracy with these published government articles where the title lacks decorum

mckn1ght 2y ago
Actually I think that overcorrecting for decorum is taking us to Idiocracy faster. It’s right there in the name: we need to stop coddling idiots, grifters and otherwise unqualified people that work their way into positions of power. Agile gives these types of people nearly limitless recourse to maintain their grip (although it is not solely Agile’s fault, it’s the broader culture).

nvr219 2y ago

Can they make one for AI please?

jiveturkey 2y ago

Maybe there's some assumed context, but this doc doesn't clarify whether agile is actually desirable or not, for any given project. If it doesn't matter, say if there is a fixed budget for example, then ... who cares what the team calls their process. Lovely: > Are teams empowered to change their process based on what they learn? No -> Agile BS

dzonga 2y ago

ahh agile, what every tech company likes to say they adhere to. the church of agile. yet it feels to deliver good quality software on predictable timelines. agile is simply a way to cover management's ass and shift blame to programmers or other stakeholders. worse more with microservices or more appropriately "distributed monoliths" you can easily shift the blame to - the other team has been blocking our progress since we need an api they provide. seen this playout so many times at $lastjob.

rqmedes 2y ago
Image delivering a race car to a customer via Agile, starting with first delivering a bicycle
jopsen 2y ago
Is that such a bad idea: > 37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame.

pjmorris 2y ago

Warning in the article: > "Meeting requirements is treated as more important than getting something useful into the field as quickly as possible." I've got a bad feeling about this. It seems like the kind of attitude that leads to last Friday's Crowdstrike update.

deleted 2y ago
[deleted]
galangalalgol 2y ago
I see where you are headed, and certainly unscrupulous entities will it as an excuse to cut corners, but I think they are talking about the case where someone produces something that will clearly not work, while still meeting the letter of requirements. Having good requirements is important, but making them is iterative as well, and having to treat software developers like an evil DM when you are casting the wish spell is not ok.
- pjmorris 2y ago
  Yes, I agree with 'Working software over comprehensive documentation.' It's that 'working' part that sometimes depends on getting the requirements right.
kevinmchugh 2y ago
I think there's domains where rigorously establishing requirements ahead of time is necessary and creates better outcomes than shipping quickly and iterating. Especially safety-critical domains. If your product can kill someone (either on failure or success), defining expectations, behaviors, and specifications ahead of time is responsible. I really like this article, about the space shuttle dev teams: https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff
deleted 2y ago
[deleted]

jiveturkey 2y ago

(2018)

rqmedes 2y ago

Disappointed, I was hoping they came out with Agile is BS. Which it mostly is.

travisgriggs 2y ago

Just identify your "gatekeeper" points. If you have lots, there's no way you're really doing any form of agile.

aetherspawn 2y ago

Agile can be waterfall-like when the minimum viable product is otherwise too large to avoid waterfall analysis paralysis. For example, zonal controller for an electric .. tank. Under relaxed Agile you would deliver a high-level plan (module architecture) as a deliverable, and then do JIT design of each module as a deliverable followed by implementation as a deliverable. If you follow guru agile for this and deliver 1 feature at a time, it will take 10 years to get your desired feature set. Because you’ll rework and refactor each module 100 times, followed by tear up and tear down of physical testing, 100 rounds of regression testing…

the__alchemist 2y ago

Meanwhile, in order to deploy web-based software in the USAF, you need to use something called Platform One, due to something called a "Continuous Authority to Operate (ATO)". Platform One has a baby Yoda, and it is Agile to its core. The whole thing is based on the Agile core concepts like TDD, pair programming etc, and it uses "DevSecOps". This means is it is a huge time commitment just ticking the various boxes. There's something called a "pipeline", which is a set of many third party tools that all have to pass various arbitrary metrics. The pipeline breaks at arbitrary point at arbitrary times, and only Platform One team members are allowed to fix it.

strken 2y ago

It annoys me a bit that "it depends how you define a programmer" is a wrong answer. "12 full-time software engineers, 4 data scientists who touch the SQL reports sometimes, and we contract out some front-end UI work plus we have a full-time email marketing guy who does HTML templates" would be better, but that's still just a more complicated way of saying "it depends".

deleted 2y ago

[deleted]

johnbellone 2y ago

The additional documents that are linked in the footnotes are great, too. https://media.defense.gov/2018/Apr/22/2001906836/-1/-1/0/DEFENSEINNOVATIONBOARD_TEN_COMMANDMENTS_OF_SOFTWARE_2018.04.20.PDF https://media.defense.gov/2018/Apr/22/2001906836/-1/-1/0/DEF... https://media.defense.gov/2018/Jul/10/2001940937/-1/-1/0/DIB_METRICS_FOR_SOFTWARE_DEVELOPMENT_V0.9_2018.07.10.PDF https://media.defense.gov/2018/Jul/10/2001940937/-1/-1/0/DIB...

neilv 2y ago

The title made me suspect it was about Here's some signs that Agile buzzwords and rituals are being used as a smokescreen for project crisis, organizational dysfunction, and team capability deficit. And I was all ready to high-five them. But it seems to start with the implicit assumption that Agile is good, and non-Agile is bad, and the information is some almost off-the-cuff notes on their own particular definition of Agile.

deleted 2y ago

[deleted]

ChrisArchitect 2y ago

Previous discussion: 1 year ago https://news.ycombinator.com/item?id=34957523 https://news.ycombinator.com/item?id=34957523 4 years ago https://news.ycombinator.com/item?id=23962722 https://news.ycombinator.com/item?id=23962722