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

31–40 of 144 posts

Re: We always end up with waterfall

#31

Post by atoav »

mrmlz wrote: post #5
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…

Yeah, because waterfall with iterations is better than SCRUM/AGILE/WHATEVER. God intended water to run from the TOP to the BOTTOM. Don't fight gravity.

The best results I have ever seen have been projects that people on the bottom did themselves, because they needed it without the people on the top ever knowing about it.

The worst results I have ever seen have been projects where the people on the bottom stopped caring because the people on the top tried to make them ignore the laws of nature.

Also: God is dead

Re: We always end up with waterfall

#32

Post by switch007 »

28304283409234 wrote: post #22

Agile always was the answer to that nagging project manager asking “When will it be done?” By engaging with an answer the engineers kept being part of the discussion. Instead, they should have said: you don’t get to ask that question. That question has no place here. Engage with us in building the product and let us create and enjoy! Of course, the real world needs deadlines, timelines, roadmaps. And thus, agile is p…

Yup. Every single organisation I’ve worked at just paid lip service to the whole “you need to be involved in the process” observation.

Unfortunately in my career I’ve only ever seen execs recede further and further away, hiring more and more PMs to replace them in that task. The self aggrandisement is getting worse and worse. They go away for retreat camps, and strategy meet-ups etc and pat themselves on the back about doing Very Important Work for weeks after each event

Here it’s a class thing. They see themselves aligned with the capitalist owners more than the “factory workers” (the devs)

Re: We always end up with waterfall

#33

Post by The_Colonel »

marcus_holmes wrote: post #15

I disagree. Everyone does iterative development, always, but it comes disguised as waterfall/scrumfall/kanban/whatever. The product is developed using waterfall and then it gets put in front of a stakeholder, who has changed their mind in the time between the initial spec and the delivery. So another, smaller, waterfall is created. This is iterative development. And it always happens, because no-one gets product deve…

I think this ignores two major constraints - the "waterfall mindset" was about stakeholders (customers) believing they can get a finished product in a fixed timeline for a fixed price.

What happened then was that after the delivery, the stakeholder was wildly unhappy with the result and demanded re-work, but that would be unplanned and un-budgeted. Many ugly arguments and finger pointing would ensue, which could repeat in several "iterations".

The other thing which doesn't align with agile was that the stakeholder usually didn't participate in the development. They weren't reviewing the progress, they were typically waiting for the finished product to be delivered.

Re: We always end up with waterfall

#34

Post by atoav »

marcus_holmes wrote: post #15

I disagree. Everyone does iterative development, always, but it comes disguised as waterfall/scrumfall/kanban/whatever. The product is developed using waterfall and then it gets put in front of a stakeholder, who has changed their mind in the time between the initial spec and the delivery. So another, smaller, waterfall is created. This is iterative development. And it always happens, because no-one gets product deve…

Two things:

1) You can end at the first iteration and call it a day. The only reason nobody does that is because they don't benefit from an unhappy customer

2) If you have experience, nothing stops you from putting some iterations into the waterfall. As you said the need for feedback rounds should be no surprise.

Traditionally the downside to waterfall was that the distance between those iterations was too big. But smaller iterations and partly prototypes is nothing that wouldn't be allowed in waterfall if you'd like to do it. And if you find a PM that doesn't do the reasonable thing "because the methodology won't allow it" they are probably a bad PM.

Re: We always end up with waterfall

#35

Post by Illotus »

The_Colonel wrote: post #24
doctor_eval wrote: post #21

Earlier quoted context omitted.

> Waterfall doesn't mean not to iterate Technically, that’s exactly what it means. The entire design is signed off and completed before the implementation starts, and there is no feedback loop. But waterfall itself was a straw man in a paper intended to recommend a much more complex process. It’s more than ironic that it became seen to be a valid process in and of itself. (Sadly I’ve lost the link to the original pap…

> But waterfall itself was a straw man I disagree. I've been in many projects which looked exactly like the stereotypical waterfall, with the expected results (delays, death marches).

Originally in the W. Royce article from the 70s it was a strawman put up by Royce. He then went on to define much more reasonable iterative model.

Unfortunately the strawman was what started getting traction.

Re: We always end up with waterfall

#36

Post by mrmlz »

SideburnsOfDoom wrote: post #12
mrmlz wrote: post #7

Earlier quoted context omitted.

Honestly I've never seen a waterfall model implemented without iterations. And you can always update the top-spec at later date if needed its just more difficult.. Which it should be.

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

Yeah - I mean, when I wrote the comment I ignored all the absolute disaster-projects I've seen. But those where doomed on so many levels I don't even wanna blame waterfall or agile or the in-betweens.

Re: We always end up with waterfall

#37

Post by SideburnsOfDoom »

goodlinks wrote: post #28
SideburnsOfDoom wrote: post #8

Earlier quoted context omitted.

The question that you're missing is: Which works better? Which delivers more better software, more reliably? Granted, the business world does run on quarterly results and shareholder value and being able to say ..., but you can say any damn thing that you like, only promising it doesn't guarantee that it will happen. Software development is always uncertain, the question is how best to tame that - ignore it or lean i…

There needs to be a stable narrative to shareholders, anything within your control should be managed. Moving all software development into some kind of skunkworks part of the business with 0 expected returns and only ever discussing roll outs may be one way to do it. (Shrug) Its why i think innovation is maybe a bit easier at a privately held or government owned org. They can look at the value more directly rather th…

> There needs to be a stable narrative to shareholders

I don't disagree with that. In fact, knowing the end goal is even more important when actions are "skunkworks".

> Moving all software development into part of the business with 0 expected returns

Agile's focus on "Working software is the primary measure of progress. ... early and continuous delivery of valuable software." is IMHO the opposite of that characterisation; as it demonstrates value and solicits feedback as soon as feasible. Note that this has very little to do with "is it following a pre-agreed plan or not?".

The issue is more that too many businesses believe that software development is best done as top-down detailed micromanagement, and the tools at hand (i.e. Jira) lean into this delusion.

Re: We always end up with waterfall

#38

Post by SideburnsOfDoom »

mrmlz wrote: post #36
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.

Yeah - I mean, when I wrote the comment I ignored all the absolute disaster-projects I've seen. But those where doomed on so many levels I don't even wanna blame waterfall or agile or the in-betweens.

So, "if you ignore the ones without iterations, I've never seen a waterfall model implemented without iterations."

Re: We always end up with waterfall

#39

Post by mrmlz »

atoav wrote: post #31
mrmlz wrote: post #5

Earlier quoted context omitted.

Yeah, because waterfall with iterations is better than SCRUM/AGILE/WHATEVER. God intended water to run from the TOP to the BOTTOM. Don't fight gravity.

The best results I have ever seen have been projects that people on the bottom did themselves, because they needed it without the people on the top ever knowing about it. The worst results I have ever seen have been projects where the people on the bottom stopped caring because the people on the top tried to make them ignore the laws of nature. Also: God is dead

I'm not really sure what you are arguing. Of course if its a one man job (or a couple) and the .. product or whatever isn't system/safety critical even having a PM is probably overkill and the overhead of "any" process likely just wrecks the output.

But if you need to organize 50+ engineers and actually produce a ... product? That people/agencies/customers expect things of you sure as shit is going to need a definable goal, verifiable output and a somewhat chronological way of achieveing that. Waterfall it is (with reasonable iterations).

Re: We always end up with waterfall

#40

Post by andyjohnson0 »

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

Post reply on HN