color me paranoid but clicking a pdf from defense.gov feels wrong but I want to read this so bad lol
[deleted]
U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
31–40 of 47 posts
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#32Warning 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.
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.
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#33It feels like we’re getting closer and closer to Idiocracy with these published government articles where the title lacks decorum
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).
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#34Warning 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]
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#35Meanwhile, 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.
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#36It 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".
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#37[deleted]
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#38The additional documents that are linked in the footnotes are great, too.
https://media.defense.gov/2018/Apr/22/2001906836/-1/-1/0/DEF...
https://media.defense.gov/2018/Jul/10/2001940937/-1/-1/0/DIB...
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#39I love this document. I'm absolutely going to be sharing this around a bit at my company
Share the link, not just the PDF, to give more legitimacy ;)
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.