The 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...
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!
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.
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.
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.
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.
It feels like we’re getting closer and closer to Idiocracy with these published government articles where the title lacks decorum
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.
I love this document. I'm absolutely going to be sharing this around a bit at my company
Can they make one for AI please?
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".
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…
Just identify your "gatekeeper" points. If you have lots, there's no way you're really doing any form of agile.
(2018)
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".
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
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.
Disappointed, I was hoping they came out with Agile is BS. Which it mostly is.
color me paranoid but clicking a pdf from defense.gov feels wrong but I want to read this so bad lol
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.