Live data from Hacker News

We always end up with waterfall

amazingcto.com

21–30 of 144 posts

Re: We always end up with waterfall

#21
post #9

Naturally everyone does waterfall, just at different points. Even if I did the leanest form of Kanban, I have to check the requirements of each ticket, understand them, translate them to maybe a prototype/discovery phase, come up with tests and an implementation strategy and verify the result somehow. That's just waterfall at the finest possible granularity. Waterfall doesn't mean not to iterate. It also doesn't mean…

> 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 paper, but if I find it I’ll update my comment)

> Besides, waterfall is just the straw man of scrum zealots.

The irony is that scrum itself is often just a wrapper for a waterfall process with all the problems it comes with. So many corporate implementations of scrum are AINO - agile in name only. Management that doesn’t understand the complexity of software is doomed to oversimplify it.

That said, if you are working iteratively - one feature at a time, with feedback - then whatever you call it, that’s not waterfall.

Re: We always end up with waterfall

#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 pointless. As it is just waterfall. In a different colour.

Re: We always end up with waterfall

#23
post #19
post #9

Naturally everyone does waterfall, just at different points. Even if I did the leanest form of Kanban, I have to check the requirements of each ticket, understand them, translate them to maybe a prototype/discovery phase, come up with tests and an implementation strategy and verify the result somehow. That's just waterfall at the finest possible granularity. Waterfall doesn't mean not to iterate. It also doesn't mean…

> 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 methodology nearly always will be (and was) sacrificed if the need arises. So as we are discussing a thing we do in practise, we shouldn't discuss it as a theoretical framework in the vacuum of space, but as something that will be (a)bused in reality.

As a film guy I am a big fan of clear up-front planing (you probably know some of the things that go into films, treatments, scripts, story-boards, concept art, ...) A film is very waterfall-y in how it is produced. But good directors maintain their flexibility on set by maintaining a balance in how serious they take the script on set and where other solutions present themselves that are a thousand times better, e.g. because the location/the actors or whatever is more striking than any writer could have imagined etc.

Re: We always end up with waterfall

#24
post #9

Naturally everyone does waterfall, just at different points. Even if I did the leanest form of Kanban, I have to check the requirements of each ticket, understand them, translate them to maybe a prototype/discovery phase, come up with tests and an implementation strategy and verify the result somehow. That's just waterfall at the finest possible granularity. Waterfall doesn't mean not to iterate. It also doesn't mean…

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

Re: We always end up with waterfall

#25
post #9

Naturally everyone does waterfall, just at different points. Even if I did the leanest form of Kanban, I have to check the requirements of each ticket, understand them, translate them to maybe a prototype/discovery phase, come up with tests and an implementation strategy and verify the result somehow. That's just waterfall at the finest possible granularity. Waterfall doesn't mean not to iterate. It also doesn't mean…

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

> The irony is that scrum itself is often just a wrapper for a waterfall process with all the problems it comes with

I worked as an external employee in an environment that had a very functional scrum implementation. You had groomings, plannings, dailys, retrospectives. Every task was defined, estimated, time on them tracked to get better in estimating. You had scrum masters, capacity plannings. On the surface, it was all very functional and productive.

But the reality is, business analysts and product managers who had little knowledge of how the system works were in charge of talking to clients, writing specifications, getting them approved and ready for development, and very little possibility to iterate if there was a problem in the definition.

It was very efficient at building a bad product. :D

Re: We always end up with waterfall

#26

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…

And then the project manager fires everyone and hires a team that gives them the answers they want. Even though most of the time the answers were wrong, but by that time the project manager is already neck deep with dependencies around the new team.

That's why we can't have nice things. You depend on having nice project managers, which is rarely the case.

Re: We always end up with waterfall

#27
post #7
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…

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.

I have seen exactly that - no iterations. Mostly it was customer waiting for the finished product and that was the first time they've seen it.

As an improvement, sometimes the project management *forced* the customer to make some checkpoints along the way, but they were a far cry from real iterations.

Re: We always end up with waterfall

#28

For people who worship capitalism as much as folks here do, a lot of you sure don't get business processes. Yes, you wind up having to plan things, because the rest of the business world runs on deadlines and contracts and milestones and deliverables. Agile is, God forbid, almost like being an artist or low, disgusted whisper liberal arts major...when done correctly, in that you're iterating and tinkering and shippin…

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 than through share value impact.

This response is just about how big a deal the shareholder perspectove is, if you can fly under that radar then you stillneed to convince everyone else that you can be trusted to deliver eventually.

Re: We always end up with waterfall

#29
RUP really isn't waterfall anymore. It's not as linear. It's it's own thing, a sort of hybrid model. The nineties already knew the issue with expecting to get everything right the first time.

The problem with it is it's too complicated. Your management with the mental capacity of a five year old just wouldn't understand it.

Re: We always end up with waterfall

#30
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…

Huh? I’ve never seen scrum fully implemented. It’s always been pick and choose.

The most common defence from Certified Scrum Masters TM © is that you haven’t implemented it correctly/fully.

Does YMMV?

Post reply on HN