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

Less is more agile

beny23.github.io

Post reply on HN
Print view View original

11–20 of 174 posts

Re: Less is more agile

#11

Post by burnished »

peteradio wrote: post #6
Ecstatify wrote: post #4

Earlier quoted context omitted.

Could you elaborate?

Waterfall is not practiced, its an ill-defined strawman meant to be the "other wrong way of doing things". At best its a self-deprecating measure meaning the more agile you are, the less you know where you are going, and the more waterfall your project management appears the more you know what you are doing. Is that supposed to sell me on agile? I want the strawman.

Nope. Waterfall is still used and used correctly in situations where there are large and important contractual or compliance obligations. You wouldn't use an agile methodology in construction, you waterfall the hell out of that. Same for hardware projects where fab times can be very lengthy.

I don't blame you for coming to the conclusion you have, but you'd do well to signpost when you suspect something is true vs have reason and evidence that something is true.

Re: Less is more agile

#12

Post by peteradio »

sodapopcan wrote: post #9
peteradio wrote: post #6

Earlier quoted context omitted.

Waterfall is not practiced, its an ill-defined strawman meant to be the "other wrong way of doing things". At best its a self-deprecating measure meaning the more agile you are, the less you know where you are going, and the more waterfall your project management appears the more you know what you are doing. Is that supposed to sell me on agile? I want the strawman.

> Waterfall is not practiced Is this anecdotal or what? "I want the citations."

Waterfall was first coined as a smear for as far as I can tell "planning too much": https://en.wikipedia.org/wiki/Winston_W._Royce

Re: Less is more agile

#13

Post by peteradio »

burnished wrote: post #11
peteradio wrote: post #6

Earlier quoted context omitted.

Waterfall is not practiced, its an ill-defined strawman meant to be the "other wrong way of doing things". At best its a self-deprecating measure meaning the more agile you are, the less you know where you are going, and the more waterfall your project management appears the more you know what you are doing. Is that supposed to sell me on agile? I want the strawman.

Nope. Waterfall is still used and used correctly in situations where there are large and important contractual or compliance obligations. You wouldn't use an agile methodology in construction, you waterfall the hell out of that. Same for hardware projects where fab times can be very lengthy. I don't blame you for coming to the conclusion you have, but you'd do well to signpost when you suspect something is true vs ha…

Does Waterfall as used today test software during subassembly development, if so its not https://en.wikipedia.org/wiki/Winston_W._Royce 's waterfall.

Re: Less is more agile

#14

Post by sodapopcan »

peteradio wrote: post #12
sodapopcan wrote: post #9

Earlier quoted context omitted.

> Waterfall is not practiced Is this anecdotal or what? "I want the citations."

Waterfall was first coined as a smear for as far as I can tell "planning too much": https://en.wikipedia.org/wiki/Winston_W._Royce

That's super interesting and I didn't know this history. However, misinterpreting someone's ideas doesn't make it not real if people are actively practicing them.

Re: Less is more agile

#15

Post by mpyne »

burnished wrote: post #11
peteradio wrote: post #6

Earlier quoted context omitted.

Waterfall is not practiced, its an ill-defined strawman meant to be the "other wrong way of doing things". At best its a self-deprecating measure meaning the more agile you are, the less you know where you are going, and the more waterfall your project management appears the more you know what you are doing. Is that supposed to sell me on agile? I want the strawman.

Nope. Waterfall is still used and used correctly in situations where there are large and important contractual or compliance obligations. You wouldn't use an agile methodology in construction, you waterfall the hell out of that. Same for hardware projects where fab times can be very lengthy. I don't blame you for coming to the conclusion you have, but you'd do well to signpost when you suspect something is true vs ha…

> You wouldn't use an agile methodology in construction, you waterfall the hell out of that.

On the contrary, Mary Poppendieck has a wonderful presentation she gave on how the Empire State Building was built in record time by literally doing it as a more agile-style construction. https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...

Likewise, American manufacturers by WWII had already gotten very good at building complicated machinery based on relatively light levels of blueprints and documentation, with the detail-level designs being added to the drawings used on the factory floor.

In many ways we have to blame the introduction of computerized project management for waterfall... it simply wouldn't have been workable before that to even attempt a real waterfall method for projects.

Re: Less is more agile

#16

Post by chii »

Surfactant7 wrote: post #2

> Allen described his work as a consultant when he goes into a new organisation: > - First he observes > - Then he would try to identify the biggest problem > - Then he would try change it (i.e. run an experiment) > - Then if that works, run another experiment > - If it doesn’t work, go back It's probably no accident, but this is pretty close to the scientific method.

> - Then if that works, run another experiment > - If it doesn’t work, go back

The problem is that if it doesn't work for a couple times, you get fired, or at least seen as incompetent.

Management want magic rituals that fixes everything, not the scientific method.

Re: Less is more agile

#17

Post by mpyne »

peteradio wrote: post #6
Ecstatify wrote: post #4

Earlier quoted context omitted.

Could you elaborate?

Waterfall is not practiced, its an ill-defined strawman meant to be the "other wrong way of doing things". At best its a self-deprecating measure meaning the more agile you are, the less you know where you are going, and the more waterfall your project management appears the more you know what you are doing. Is that supposed to sell me on agile? I want the strawman.

Unfortunately it is still practiced in many environments, including most Navy software acquisition efforts, which are frequently run under a "systems engineering" process intended for hardware like ships and airplanes.

This process includes multiple reviews in a "SETR" (System Engineering Technical Review) process (https://www.acqnotes.com/Attachments/SETR%20Navy%E2%80%99s%2...), including steps like:

* SRR (System Requirements Review)

* CDR (Critical Design Review)

* TRR (Test Readiness Review)

Example of slide 15:

Example of Items from SRR Template

* SW Development Team

* Integrated Mater Schedule Highlighted with Software Milestones

* Software Entrance Criteria

* Requirements Analysis and Allocation Methodology (sounds agile to me!)

* System Specifications Tree

* Contract Data Requirements List (CDRL)

* Software Development Strategy

* Software Development Process

* SW Safety, Information Assurance and Security requirements

* Software Supplier Management

* Software Measurement

* Software Risk Assessment with Mitigation Strategies

* Issues and Concerns

Re: Less is more agile

#18

Post by denimnerd42 »

azemetre wrote: post #10
dbxkcichhdfufu wrote: post #7

Earlier quoted context omitted.

Waterfall absolutely was practiced. Budgets always overrun and developers had to work overtime to meet deadlines completing all the tasks that weren't mentioned in the plan.

This still happens under agile too. It’s not like a process magically fixes things. Most of the issues I read from SWE in regards to agile is that they are often neglected in both decision making and the ability to hold leadership accountable. No amount of agileness is going to save you from a miss managed team.

Well I wouldn't count mismanagement against agile then. At my work we practice SWE by managerial dictatorship and also "agile." I'm certainly not holding the failures against agile.

Re: Less is more agile

#19

Post by stephc_int13 »

Agile was a relatively good idea, I welcomed the Agile manifesto with open arms because freaking UML was all the rage at the time.

Unfortunately, Agile quickly turned to be even worse than what preceded.

Corporate bureaucracy should be fought against at all times and by all means.

If you work in software, you are valuable enough to have a say, and a choice about who you work for.

Not everything has to turn into a bullshit job.

Re: Less is more agile

#20

Post by peteradio »

sodapopcan wrote: post #14
peteradio wrote: post #12

Earlier quoted context omitted.

Waterfall was first coined as a smear for as far as I can tell "planning too much": https://en.wikipedia.org/wiki/Winston_W._Royce

That's super interesting and I didn't know this history. However, misinterpreting someone's ideas doesn't make it not real if people are actively practicing them.

The link is the man who coined the term. Would you say waterfall today is strictly adherent to NOT testing code before delivery of subassembly? That's the coiners definition.
Post reply on HN