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.
https://media.defense.gov/2018/Apr/22/2001906836/-1/-1/0/DEF...
https://media.defense.gov/2018/Jul/10/2001940937/-1/-1/0/DIB...
> 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 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.
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.
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.
> "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 really like this article, about the space shuttle dev teams: https://www.fastcompany.com/28121/they-write-right-stuff
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…
Lovely:
> Are teams empowered to change their process based on what they learn? No -> Agile BS
The last section with flow chart is good though.
Seriously, I can't imagine a plausible threat from downloading that.
