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

51–58 of 58 posts

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

#51

Post by closeparen »

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

>data center distributed systems that are air-gapped

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

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

#52

Post by carlsborg »

valuearb wrote: post #50
jnurmine wrote: post #22

Earlier quoted context omitted.

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…

I once ran a 45 person dev organization that used waterfall to ship a half dozen commercial applications a year, including dozens of localized and enhancement versions, and never missed a ship date over five years. And won numerous industry awards. It can be done with waterfall.

Thats impressive, was it your shop?

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

#53

Post by lmilcin »

For me the biggest clue is always a fixed "agile" process. By definition any notion of fixing a process is anti-agile.

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.

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

#54

Post by Jtsummers »

valuearb wrote: post #50
jnurmine wrote: post #22

Earlier quoted context omitted.

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…

I once ran a 45 person dev organization that used waterfall to ship a half dozen commercial applications a year, including dozens of localized and enhancement versions, and never missed a ship date over five years. And won numerous industry awards. It can be done with waterfall.

This raises several questions:

1. How experienced were these people in the particular problem domain?

2. How long was a single development effort and how many people?

3. What do you consider Waterfall? Are we talking "pure" Waterfall where everything is truly done in set phases? Or do you have feedback loops in place, like testing integrated properly into the development phase?

4. What was the relationships like with customers? Was it one (or a small number) of consistent customers or a diverse set of customers (closer to contract/bespoke software work)?

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

#55

Post by valuearb »

Jtsummers wrote: post #54
valuearb wrote: post #50

Earlier quoted context omitted.

I once ran a 45 person dev organization that used waterfall to ship a half dozen commercial applications a year, including dozens of localized and enhancement versions, and never missed a ship date over five years. And won numerous industry awards. It can be done with waterfall.

This raises several questions: 1. How experienced were these people in the particular problem domain? 2. How long was a single development effort and how many people? 3. What do you consider Waterfall? Are we talking "pure" Waterfall where everything is truly done in set phases? Or do you have feedback loops in place, like testing integrated properly into the development phase? 4. What was the relationships like with…

1) Pretty young work force, we essentially trained everyone who came in.

2) typical team was 2-3 devs, 1-2 QA, project manager, product manager. Typical dev time was 6-9 months.

3) Waterfall has a pretty amorphous definition, our implementation not very pure, which is probably why it succeeded. Each component of a new release would start testing as soon as engineers had something testable. When all components passed QA we’d go into alpha, then beta.

4) It was consumer software, specifically targeted to graphics professionals on Mac/Windows. We had hundreds of thousands of customers, and delivered physically in floppies and CD Rom.

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

#56

Post by valuearb »

carlsborg wrote: post #52
valuearb wrote: post #50

Earlier quoted context omitted.

I once ran a 45 person dev organization that used waterfall to ship a half dozen commercial applications a year, including dozens of localized and enhancement versions, and never missed a ship date over five years. And won numerous industry awards. It can be done with waterfall.

Thats impressive, was it your shop?

I built the process. Or should I say, we built the process to best meet the specific requirements for our products and customers, as communicated by our product marketing team.

Our main strength was actually our Product Management director. He was excellent at collecting and communicating highest priority customer requirements. He was always questioning and pushing, and helping my engineers come up with better approaches and implementations.

He was also excellent at building external relationships do we had really good partnerships, and training/leading team PMs so they were good team leaders. He was so damn good at it they eventually he moved in from our little company to run all mobile for a $100B+ company.

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

#57

Post by rstuart4133 »

jnurmine wrote: post #22
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…

The Zen of waterfall:

At some level everything is waterfall. If anything is to get done at all, at some point the programmer has to make a plan, then put his head down, arse up and implement it.

At another level nothing is waterfall. If the plan is successful it was shipped to the consumer (which may be the programmer himself), and it's very presence changes things for the consumer in ways that they didn't foresee. They then realise they need a new set of changes.

What we call waterfall model is really referring to the scale. If the plan is grand, the specifications for such a grand plan need to be detailed, the implementation long, and the time between putting the head down and evaluating results is large, and we call it waterfall.

But if the stragegy is to explore the solution organically, the re-evaluations are frequent, the waterfall periods are short and we call the strategy something else.

So in the end everything uses waterfall. The programmer would not get the long periods of intense focus he need to be productive without it. But also nothing is waterfall, because no plan can foresee everything, it must be continually re-evaluated in the light of unexpected changes it brings as it is implemented.

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

#58

Post by jrumbut »

qznc wrote: post #14
jrumbut wrote: post #8

Earlier quoted context omitted.

I think the parent post has, but for the reader who is a software engineer take 15 minutes out of your life to read WW Royce's "Managing the Development of Large Software Systems." In this brief and engaging paper you will find the diagram used by many agile enthusiasts to describe the "waterfall method" and will be shocked to discover that it is held up as an example of a process that never actually works in reality…

http://beza1e1.tuxen.de/waterfall.html Incremental and iterative development is not an invention of Agile either. It was used before "Waterfall" existed.

Indeed, that's some great added context to the linked paper and how the whole waterfall strawman was created.
Post reply on HN