Disappointed, I was hoping they came out with Agile is BS. Which it mostly is.
U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
21–30 of 47 posts
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#22color me paranoid but clicking a pdf from defense.gov feels wrong but I want to read this so bad lol
I think you're paranoid.
Seriously, I can't imagine a plausible threat from downloading that.
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#23While 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…
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".
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#24Just identify your "gatekeeper" points. If you have lots, there's no way you're really doing any form of agile.
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#25ahh 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 sin…
Is that such a bad idea:
> 37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame.
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#26Warning 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)
#27ahh 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 sin…
Image delivering a race car to a customer via Agile, starting with first delivering a bicycle
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#28Agile 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…
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#29This document has no teeth. It is more simple than this … does it have fixed scope and fixed timeline ? If so it’s not agile.
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
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...
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.
Re: U.S. Department of Defense – Detecting Agile BS [pdf] (2018)
#30Warning 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 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