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

We always end up with waterfall

amazingcto.com

Post reply on HN
Print view View original

61–70 of 144 posts

Re: We always end up with waterfall

#61

Post by paulsutter »

jongjong wrote: post #4

People tend to go too far in one direction and then later over-correct in the opposite direction. Waterfall model is too much, scrum is too much. The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. Software development requires some planing and also some flexibility. One decade, companies think software architecture is the most important technical role in…

Discovery vs design is the real dichotomy. When discovery is needed, move in small steps with lots of discussion. When design is possible, move in big steps with detailed specs

We’re biased to overestimate our understanding of problems, so we should lean towards discovery mode and small steps

Dysfunctional agile has detailed specs and little discussion (no discovery, myopic design)

Re: We always end up with waterfall

#62

Post by ChrisSD »

andyjohnson0 wrote: post #40
jongjong wrote: post #4

People tend to go too far in one direction and then later over-correct in the opposite direction. Waterfall model is too much, scrum is too much. The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. Software development requires some planing and also some flexibility. One decade, companies think software architecture is the most important technical role in…

> The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. I'm feeling grumpy and decaffinated this morning, so I'll just note that you can't sell books and courses and conferences on "balance and nuance".

But saying things like "everything is somewhere in the middle" and "use common sense" is just as much marketing speak. It's meaningless to the point it's very successfully used in both marketing and politics (but I repeat myself).

The key thing is you can set the parameters so that whatever you're selling happens to fall squarely in the middle. And of course anything can be common sense so long as you can successfully ridicule the alternatives and describe your solution in a way that sounds plausible(ish).

Re: We always end up with waterfall

#63

Post by solatic »

At its core, the true underlying problem is that you can't actually fully control another person's output while still holding onto any genuine agility. The design is going to leave out some Product features, the code is going to diverge slightly from the design, QA will find some things the code didn't account for, DevOps, Security, and Legal will each chime in with other things that weren't considered.

If the organization requires that everyone is happy, then everyone gets to review the work at every stage (in order to express unhappiness and get it fixed before proceeding). The inevitable result is a Waterfall process to gatekeep how work moves to each stage. The inevitable result is a lack of agility.

But if the organization can lean into the Truth that Nothing Is Perfect, that your product is not perfect, your design is not perfect, your code is not perfect, your scaling, observability, security, and compliance are not perfect, then suddenly, nobody needs anybody's approval. You ship, and you ship quickly. Then you focus on learning and iterative improvement. Make things better over time, but not necessarily right now.

Getting rid of Waterfall is learning to let go and to live with imperfection.

Re: We always end up with waterfall

#64

Post by bipson »

pjmlp wrote: post #2

Easy, as somehow discussed on the article. Beyond the IT department everyone else has very to low incentives to adopt "those crazy ideas from computer guys", they care about deadlines, roadmaps, when marketing campaigns can be organised, with what content, what should be on the contracts with business partners,... Ever since we got those ideas around 2000, the best outcome if agile is adopted at all, is scrumfall as…

I think here is the common misunderstanding:

No one says Agile can't have full blown requirements or the respective documents.

To the contrary, you can't expect your dev to understand what he has to write without giving him a goal he is working on - Agile won't fix that.

Agile just means you build in small steps from what you have and review your steps ASAP, instead of working multiple months based on some detailed documents, derived from other documents, written by some other department months ago, building stuff no one wanted in the first place.

Re: We always end up with waterfall

#65

Post by hnfong »

atoav wrote: post #23
hnben wrote: post #19

Earlier quoted context omitted.

> Waterfall doesn't mean not to iterate I don't want to be pedantic, but waterfall does mean exactly that by definition (or at least it used to). There are plenty of variations, that include prototypes or MVPs or iterations (e.g. V-Model, Spiral model). > waterfall is just the straw man of scrum zealots You can't just change the definition of a word, and then call people using the original definition "zealots", see h…

The question is whether any of the "classical" examples for waterfall project managements out there didn't iterate at all. Having iterations is not incompatible with waterfall per se. E.g. you can plan to have 3 prototypes and then one final product beforehand. You can also decide to skip project phases if they are not needed. When people hear waterfall they think of a pure methodology, when in practise the methodolo…

A term has a meaning, and the fact that people don't actually practice it doesn't mean you can just change what it means.

> A film is very waterfall-y in how it is produced. But good directors maintain their flexibility on set by

Right. So they don't stick strictly with waterfall, even though the industry tends to be "waterfall-y".

My understanding is that in some (non-software) industries, waterfall is practiced because you really can't go back and change things. Or maybe you could, but it would mean increased cost and delays to the extent that you might as well have started all over.

There was a time when people thought "software engineering" was really engineering, so you had to follow traditional engineering best practices. eg. Do it right the first time, make plans and stick with them. It just turns out that this doesn't work for software, and as you said, nobody is really stupid enough to do strictly that now.

Re: We always end up with waterfall

#66

Post by CuriousSkeptic »

chadcmulligan wrote: post #49

I'm doing scrum and waterfall at the moment, customers are saying why is it costing so much? Managers are saying we're agile :-D what fun. We have design docs and requirements docs and epics and scrum masters and devops etc etc

This is the kind if project where agile can truly shine.

“Hey, customer, looks like we burnt through half your budget and it doesn’t look like we’ll be able to complete the full spec on what remains…

I could ask you to increase the budget, but I think I have a better suggestion. You tell me which feature is most important to get in and well focus on that exclusively, and iterate on that until you're either happy with what you’ve got, or the budget runs out. Then lets take a decision on how to proceed from there if still needed”

Re: We always end up with waterfall

#67

Post by nicbou »

solatic wrote: post #63

At its core, the true underlying problem is that you can't actually fully control another person's output while still holding onto any genuine agility. The design is going to leave out some Product features, the code is going to diverge slightly from the design, QA will find some things the code didn't account for, DevOps, Security, and Legal will each chime in with other things that weren't considered. If the organi…

The problem is that some things must be perfect, because they expose the company to significant risk. You can iterate on a feature but not on compliance.

Re: We always end up with waterfall

#68

Post by clcaev »

kibibu wrote: post #50
SideburnsOfDoom wrote: post #12

Earlier quoted context omitted.

> Honestly I've never seen a waterfall model implemented without iterations. I have. It didn't reach the end.

People should read Royce's paper that popularised Waterfall. It has iterations, sadly it appears most people stopped reading after Figure 2. https://www.praxisframework.org/files/royce1970.pdf

Thanks. 1970. It also talks about building a prototype, eg one to throw away.

Re: We always end up with waterfall

#69

Post by quickthrower2 »

andyjohnson0 wrote: post #40
jongjong wrote: post #4

People tend to go too far in one direction and then later over-correct in the opposite direction. Waterfall model is too much, scrum is too much. The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. Software development requires some planing and also some flexibility. One decade, companies think software architecture is the most important technical role in…

> The optimal approach is almost always in-between and yet, frustratingly, nobody advocates for balance and nuance. I'm feeling grumpy and decaffinated this morning, so I'll just note that you can't sell books and courses and conferences on "balance and nuance".

Oh I am sure you could come up with myriad processes, rituals and ethos and give it a snazzy name like “zero-sigma” (alluding to being the average way)

Re: We always end up with waterfall

#70

Post by smugglerFlynn »

nicbou wrote: post #67
solatic wrote: post #63

At its core, the true underlying problem is that you can't actually fully control another person's output while still holding onto any genuine agility. The design is going to leave out some Product features, the code is going to diverge slightly from the design, QA will find some things the code didn't account for, DevOps, Security, and Legal will each chime in with other things that weren't considered. If the organi…

The problem is that some things must be perfect, because they expose the company to significant risk. You can iterate on a feature but not on compliance.

You can iterate on compliance _implementation_ if you keep some tollgate that guarantees all compliance business requirements are eventually met. In my opinion this is not the same as waterfall, and leaves room for experiments and iterative learning.

The (very) tricky part, in my experience, is to have these requirements captured in implementation-agnostic way. Even strict accounting reqs require huge amount of work for someone to deconstruct them down to actual compliance requirement, instead of something solution-specific like "we need to store X in component Y".

Not everyone wants to invest into this just for agility sake.

Post reply on HN