Great document overall!<p>> The purpose of this document is to provide guidance to DoD program executives and acquisition professionals on how to detect software projects that are really using agile development versus those that are simply waterfall or spiral development in agile clothing (“agile-scrum-fall”).<p>Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be.<p>The real danger is that the project would just be managed badly, independent of professed approach. Just muddling through badly.<p>(I am not even sure if waterfall was ever actually a thing, I mostly ever only hear about it as a thing to avoid?)
Interesting that all these issues are completely different from my own experiences with Agile BS. We would have 10 hours of exhausting meetings every 2 weeks in order to plan our sprints. Unconsciously, we just ended up hyper inflating estimates so our team would joke about how the only thing we did each sprint was "slap a box on it" (in CSS, or some similarly simple task).<p>I left that job when all the developers completed their tasks a few hours before the end of the sprint, giving me (QA) just a few hours to test, merge, and deploy their code, which because of our terribly clunky and manual deploy system, just wasn't possible. I was placed under an internal investigation for not being productive because I held up the sprint of the "most productive team in the company" and made us look bad to out of state executives.
I love the document and will distribute to my co-workers. The short story, however, is not really that there's a checklist to determine BS Agile, but rather that all/most Agile is BS.<p>In my career I've seen "Agile" throw a wrench in the works for so many projects. Embedded systems; data center distributed systems that are air-gapped; aerospace safety systems; R&D work. Agile in these cases just isn't the thing to do, but unfortunately the culture these days is that everyone MUST be Agile, and so it creates another bureaucratic nightmare of dysfunction.<p>The funny thing is, people will always go to bat for Agile (MUCH more so on Reddit than HN).. and I don't understand why. I think furthermore the discourse around this has become so weird. For example, I asked someone kindly what is "Not-Agile"? There's no answer, other than "bad ways of making software". The discourse has become caveman-like "Agile good. Not-Agile bad."<p>At the end of the day, Agile is probably great if you're making a mobile app or a web app with a small team for a client with a small-to-medium budget, which accounts for most work software developers do, which is why its so popular. But is inherently too short-sighted and unable to address technical challenges that go more than superficially deep.
What's DIB? Just trying to understand who is the target audience of this guide.<p>It's a practical set of traits to spot. But inevitably a question comes up "what to do next?" Re-educate, enforce, hire/fire, disband?<p>One needs to remember how the Agile processes were being "installed" back in the day in organisations/teams of various degree of dysfunction. Lots of those teams went through trials of "templates", including waterfall, just with the same outcomes.<p>Too often, the failure is not at the team but on org-level. The base tenet of Agile success is buy-in on all levels. Yet it's easier for the management to "buy-into" a structure and attributes, not into actually empowering and trusting the teams.<p>So, this detection approach may find all right attributes, tools, lingo, roles... but not the actual practices. A beaten down example is a morning stand-up, which disguises the dreaded subordinate reports - best indicator of such theater is a presence of a "clip-board" or note-taker person.<p>I'd think for such guide to be of better practical value, there should be a section which would outline ways to detect the constraints and obstacles for adoption of a proccess which would be effective in a given team's case. It does not have to be Agile-or-wrong.
My current problem : customers who don't want to participate in the agile process and do want to have a "simple" pre-agreed specification to use to determine project success/failure. Of course they can't write such a spec and want me to do it - and of course I can't without doing large parts of the work to implement it (because if I'm wrong I'm on the hook for a large sum of money wasted).
Discussed at the time: <a href="https://news.ycombinator.com/item?id=18910608" rel="nofollow">https://news.ycombinator.com/item?id=18910608</a>
It started well, then it completely fell on the corporate bullshit side.<p>For example: "Some current, common tools in use by teams using agile development".<p>This is the kind of reason why a lot of people are required by management to use useless overkill stacks for their needs like docker or kubernetes.<p>Also the "questions to ask" are typical ridiculous agile corporate bullshit like "have you a product charter", or common forced process oriented questions.
I interviewed recently at a defense contractor and experienced something like this. I know you’re supposed to ask questions during an interview but I usually only really come up with two: what is your git/hg workflow and what does your automated test coverage look like.<p>Usually the second one has an answer along the lines of “not good but we’re working on it” which is fine. This place though tried pretty hard to convince me they were using git to manage their code right up until I asked the second question. The senior engineer sort of mumbled a few things ending with something along the lines of “we’re still figuring out exactly what the transition from svn will look like.”<p>I’m not sure why they didn’t decide to hire me but I feel like that interaction really upset someone and may have been a big part of it.
For me the biggest clue is always a fixed "agile" process. By definition any notion of fixing a process is anti-agile.<p>In my current team the only thing that I have asked to do when "going agile" was biweekly retro to discuss what to improve. Seems to be going pretty well even if most problems have solutions from various described "agile" process templates.