Live data from Hacker News

Even with Agile and Scrum waterfall will sneak in

amazingcto.com

211–220 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#211

I started working prior to Agile becoming a thing but wasn't around for the entirety of the 1990s. I have seen both waterfall and agile products fail or succeed. I don't think the process is ever to blame when they failed or deserves much credit when they succeeded. My take on it is both processes have their strengths and weaknesses and perhaps a product needs to start Agile and slowly morph towards Waterfall as it m…

Fully agree with this despite a much shorter career. Waterfalling a young project still in its exploratory phase leads to wasted work. Forcing agile onto a very mature project leads to tech debt and shoddy work.

A big part of the problem is when people have been indoctrinated into one of the various denominations of the Agile cult and try to force it upon every organization, product, project, or team they encounter. And of course it goes without being said that almost nobody follows “real agile” since in most companies it’s just a way for management to micromanage and randomize the tasks of individual engineers so middle management can look at pretty burn down charts.

Re: Even with Agile and Scrum waterfall will sneak in

#212

Earlier quoted context omitted.

There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it. Doing that per issue is still basically agile. The prob…

That might be its stated goal, i still haven’t seen a single shop that actually implements that. First thing that happens when implementing agile are estimations, and the justification for that is for “predictability”.

> First thing that happens when implementing agile are estimations

I'm usually the first to chime in that all estimates are lies, but small estimates (i.e., per-issue, not per-project) easier than big ones.

Re: Even with Agile and Scrum waterfall will sneak in

#213
In 2015 Dave Thomas, whose name is on the Agile Manifesto, gave a talk named “Agile is dead - long live agile”, addressing the intent behind the manifesto and the Agile Industrial Complex / cult-like movements which spawned from that.

https://youtu.be/vqz8ND-N1hc

Re: Even with Agile and Scrum waterfall will sneak in

#214

Earlier quoted context omitted.

There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it. Doing that per issue is still basically agile. The prob…

That might be its stated goal, i still haven’t seen a single shop that actually implements that. First thing that happens when implementing agile are estimations, and the justification for that is for “predictability”.

I do it properly, but I also usually work alone, or in very small teams. I have the luxury of setting the goals, and moving the goalposts, when needed (often).

Waterfall is almost required, when you are crossing the streams. Merging separate workflows is a fraught process. You need to know what will be delivered, when. I spent most of my career, working for hardware companies, and saw this every day.

Truly agile processes don't really lend themselves to that; which is actually kind of the point.

But the real deal, is that high-level managers and non-tecchies can't deal with Agile.

Managers have a lot of power. If we don't help them to understand the process, they will make decisions, based on what they know.

Re: Even with Agile and Scrum waterfall will sneak in

#216

Earlier quoted context omitted.

The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. Additionally it is really hard for project management to get metr…

>The problem with waterfall to my experience is not immediately visible to developers or directly concerns developers, but rather the stakeholders and managers. Almost always, your customer doesn't know what they want - they think they do, but they don't and will only realize this after you finished development and have a visible system demo/field test. This just indicates a failure to perform a proper Analysis/Speci…

This just indicates a failure to perform a proper Analysis/Specification/Requirements phase

No, we're suggesting the analysis/specification phase should be comprised of what are, effectively, many really small waterfalls. And that any effort to obtain specs for an entire system without first building some minimal version of the system is doomed to failure.

For a small enough feature, yes, you end up doing waterfall. The problem is breaking up a massive system into those small enough pieces.

Re: Even with Agile and Scrum waterfall will sneak in

#218

In my few years working as a dev, I am absolutely convinced that scrum and agile are the worst possible development practices you can have from the perspective of a developer, even though they are sold as 'developer centric' or that seems to be the impression a lot of people have at least. It makes no sense at all to me to constantly have work interrupted with customer meetings that produce NO concrete specifications…

Scrum and Agile (note: capitalised) can be very painful. Badly moderated "scrum days" are a time sink. Two rounds of planning in order to start a sprint are common. Hours spent grooming infinite backlogs. An entire class of bullshit jobs is created. And all of your work is modelled on a five-year Gantt chart, effectively rendering it waterfall with more meetings.

But it is not inherently so. It can be quite simple. It can be bloated. It's usually somewhere in the middle. At the very least, since Scrum being a thing, continuous integration, integrated teams, and simplified version control flows became a thing, since every sprint is "a releasable increment".

While every waterfall project I ever worked on (granted, at the beginning of my career) felt like it was inherently shite. A cascade of dependencies. This means that every delay has a cascading effect on the duration entire project. This means that early actions are next to immutable later on. You're pulling requirements out of your arse because you have nothing concrete to validate them against. You only know if it works towards the very end. And until then, the product is unreleasable. And I guarantee you, requirements will change. Corona happens. A CTO quits and the new one wants something else. Dotnet core is released and now you're looking at that upgrade. You learn something new but you can't adapt.

Ultimately, bad orgs fester bad methods build bad products. But please don't pretend to know everything upfront because you don't.

Re: Even with Agile and Scrum waterfall will sneak in

#219

The sooner people realize that agile and scrum are sales pitches with little substance the better off everyone will be.

I don't know if I agree with that. Rather than have every team on earth invent their own process from first principles, they provide adequate starting points on which to grow. Agile, Scrum and Kanban aren't perfect but they can get a team started. Good teams will take them as templates and tweak as needed.

Re: Even with Agile and Scrum waterfall will sneak in

#220

Earlier quoted context omitted.

There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it. Doing that per issue is still basically agile. The prob…

That might be its stated goal, i still haven’t seen a single shop that actually implements that. First thing that happens when implementing agile are estimations, and the justification for that is for “predictability”.

To me it the estimates themselves don't really matter. Everybody already knows if something is gonna be worked on or not (at least kind of). The value I find from estimates is they encourage the team to discuss how something is gonna be built.

The best moments are when everybody estimates that something is "easy" except for exactly one person who says "this is super hard". Then there is a discussion about what the "easy" camp might have missed or perhaps the shortcut the "hard" person didn't know about.

At the end, everybody walks away understanding a little more about what the rest of the team is working on.

Post reply on HN