Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

media.defense.gov

Post reply on HN
Print view View original

11–20 of 47 posts

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

#11

Post by havkom »

polemic wrote: post #8
havkom wrote: post #7

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.

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.

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.

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

#12

Post by bane »

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.

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

#15

Post by jiveturkey »

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

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

#16

Post by dzonga »

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.

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

#17

Post by pjmorris »

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.

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

#18

Post by SirGeekALot »

simondanerd wrote: post #4

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".

Yikes! NPM can be an attack vector if you don't understand how it works and what it does.
Post reply on HN