Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DIB Guide: Detecting Agile BS (2018) [pdf]

media.defense.gov

Post reply on HN
Print view View original

21–30 of 58 posts

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#21

Post by 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.

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#22

Post by jnurmine »

eru wrote: post #2

Great document overall! > 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”). Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be.…

Software development perspective here, from the receiving end of project management.

In my experience, waterfall needs unlimited time and money. Waterfall fails hard when money or time are limited, in which case the likely outcome is that the head of waterfall will be massive and the tail will be rushed, so that one gets a design-heavy and rushed implementation with little or no testing and scant documentation etc.

A timeboxed waterfall with inflexible sculpted-in-stone time schedules are a recipe for burning in the ensuing deathmarch. The planning either cannot or will not anticipate all unknowns and/or the buffers dampening the impact of the unknowns shrink because of outside pressure. (What do you mean 8 months to make this thing, can't you do it in 2 weeks, haggle haggle, sold for 2 months; available time reduced by a factor of 4)

In contrast, (a theoretically ideal) agile or some other iterative method works fine if time or money are limited. The iterative nature allows for a cut-off after a sprint. Pull the plug and have a result of state-of-the-art at that point; of course the result then might not quite reach the viable dimension of MVP nor even resemble a product.

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#23

Post by marcodave »

vbtemp wrote: post #21

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,…

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

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#25

Post by sgt101 »

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

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#26

Post by at_a_remove »

vbtemp wrote: post #21

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,…

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.

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#27

Post by vbtemp »

at_a_remove wrote: post #26
vbtemp wrote: post #21

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,…

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.

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

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#28

Post by jrott »

vbtemp wrote: post #21

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,…

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.

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#29

Post by Jtsummers »

eru wrote: post #2

Great document overall! > 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”). Actually doing 'waterfall' properly would probably be fine? Or at least not the bogeyman it's made out to be.…

Waterfall was a thing, it actually is a thing. It is a terrible thing. It is an idealized version of running a project that assumes you can actually plan everything out for the next 6-60 months with teams from 5-5000. I have only ever seen it work when the projects were small or the teams were experienced and working on a mature system.

"Work": I don't mean that the projects fail but that they fail in some aspect. Like they deliver late, or don't deliver the full requirements, or they don't deliver the real requirements (because the requirements were written 5 years ago by a consultant, this might be a total failure in many cases).

"agile" (not Big-A Agile the faddish cult) resolves a lot of this by one simple thing: frequent feedback between developers and customers while developing smaller increments. Which, ironically, was actually Royce's point in the paper: Feedback loops, not necessarily with the customer, need to be incorporated in order to develop large scale systems.

One of the issues in discussing this is that it turns out that when most people say "Waterfall" they mean a modified version. When you dig into what they're doing it's either a small modification (we bring the customer in during testing, which is good but that's still 4 years into the project) or a major modification (V-Model which incorporates all of Royce's feedback loops and then some). Others have gone to doing incremental & iterative development or evolutionary but still call it Waterfall because they don't know any other term.

But yes, Waterfall exists, it is a nightmare, and I hope to never be involved in it again.

Re: DIB Guide: Detecting Agile BS (2018) [pdf]

#30

Post by [deleted] »

jrott wrote: post #28
vbtemp wrote: post #21

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,…

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…

[deleted]
Post reply on HN