[vbtemp]

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.

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.

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."

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.

[jrott]

I love this document as well for very similar reasons. It's interesting how attached people become to the ritual of doing things instead of thinking about why they are doing it.

In my experience it seems like a ton of things that people want to do with agile is get to skip the writing and design work that has to happen to make deep technical projects happen. There is a really strong desire to just start implementing and then be able to refactor to working code. Of course there is always pressure to deliver faster so the refactor only ever gets half done and then there is an architectural mess.

[bitwize]

The advantage that Agile brings to the table is that it enables more tracking and measurement at finer-grained time intervals than other approaches. Tracking and measurement is the key feature of Agile or any other software development methodology. It enables the business to determine what needs to get done, if it's on track to completion, and if not, what the pain points are. Having a short OODA loop for these three points is paramount to the business's success and in order to do that you need to track and measure. You can't manage what you can't measure, and Agile processes give the business data and analytics about how their development efforts are going at least at a sprint level of granularity; depending on local practices it could be as fine as one day. That's huge. It could potentially add visibility to all aspects of the business -- so get ready to see Agile everywhere.

TL;DR, if you believe Agile was created to help you do your job better, you might also believe that open-plan offices were really adopted to "foster collaboration" and not make you easier to spy on at work.

[at_a_remove]

Agile really scratched that "cult" (weird names, daily rituals, special roles, people who don't do it are either ignorant or evil) part of the brain that programmers are susceptible to, the part that starts so many flamewars over emacs versus vi or top-posting versus bottom-posting. It's as if people forgot that programming existed before Agile came along.

[vbtemp]

This is actually brilliant. Fantastic way to put it. Especially the part that people who don't do it must be some kind of outcast: ignorant, evil, pathological...

[marcodave]

I think it's a case of the "nobody has been fired for choosing an agile methodology"

[closeparen]

>data center distributed systems that are air-gapped

So do the users visit the datacenter to connect them, or what?