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.
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.
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".
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.
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.
They're right though- teeth means enforcement. These DOD recommendations/guidelines aren't worth the paper they're printed on if they aren't don't make into the contracts.
The document vibe to me is like it is written by some junior engineers who have just read a blog post about the Netflix stack and think they know it all now.
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.
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.
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).
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 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.
Yes, I agree with 'Working software over comprehensive documentation.' It's that 'working' part that sometimes depends on getting the requirements right.
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.
I am inclined to think there was some incentive to formally support those tools with the paper. Maybe nothing as blatent as free trips and meals, but who knows.
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…
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
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.
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.