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

Even with Agile and Scrum waterfall will sneak in

amazingcto.com

Post reply on HN
Print view View original

181–190 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#181

Post by felipellrocha »

boffinAudio wrote: post #56
littlecranky67 wrote: post #18

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…

You don’t understand. The analysis *can’t* be completed fast enough.

Re: Even with Agile and Scrum waterfall will sneak in

#182

Post by brightball »

boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. 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 ste…

Planning beyond 90 days out and pretending the plan has any hope of accuracy, that new information won’t change the plans (or design) and that the plan you started with will still even be beneficial when you finish. Brittleness.

Dependency planning has to happen of course. That’s not unique to waterfall, it’s just planning.

Re: Even with Agile and Scrum waterfall will sneak in

#183

Post by Trasmatta »

lbriner wrote: post #116
sornaensis wrote: post #40

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…

It makes a lot of sense, which is why a lot of people follow it. Your comment is implying that somehow 1000s of people around the world don't realise they are doing something stupid. You are portraying a poorly run implementation of agile as the only way and then destroying it. We call it a straw-man. * My development team are rarely interuppted with customer meetings * The meetings we have will always have outcomes,…

> You are portraying a poorly run implementation of agile as the only way and then destroying it. We call it a straw-man.

Every time there's any criticism of agile, people inevitably show up and say "well, you're just doing it wrong". Maybe there's an issue with the methodology if it's so easy to get wrong, and happens so frequently?

> Your comment is implying that somehow 1000s of people around the world don't realise they are doing something stupid.

If you read any thread on agile, I think plenty of people know they're doing something stupid...

Re: Even with Agile and Scrum waterfall will sneak in

#184

Post by buescher »

g051051 wrote: post #169
WJW wrote: post #87

Earlier quoted context omitted.

Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients. These clients often couldn't really specify in enough detail what they needed from the software that was to be built. In that scenario, the structures of Agile make a lot more sense. These days, when a company decides to start using some form of Agile methodology (usually scrum) they need to do something with th…

> Many (most?) of the early Agile promoters were owners or partners in a consultancy doing work for clients. This is a huge point that people who weren't in the industry back then completely miss: The people behind the Agile manifesto weren't trying to figure out how to improve software development as a whole...they were looking for ways to improve their consulting business. What works for them as consultants selling…

Also, virtually all of them had primarily worked in enterprise software. What works for consultants on internally developed software, with a captive user base and key stakeholders who write all the checks, is not necessarily what's going to work on customer-facing products, embedded, etc.

Re: Even with Agile and Scrum waterfall will sneak in

#185

Post by bgroat »

brightball wrote: post #182
boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. 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 ste…

Planning beyond 90 days out and pretending the plan has any hope of accuracy, that new information won’t change the plans (or design) and that the plan you started with will still even be beneficial when you finish. Brittleness. Dependency planning has to happen of course. That’s not unique to waterfall, it’s just planning.

I agree with this.

But why not waterfall out 90 days then? Or 75 or something

Re: Even with Agile and Scrum waterfall will sneak in

#186

Post by brightball »

bgroat wrote: post #185
brightball wrote: post #182

Earlier quoted context omitted.

Planning beyond 90 days out and pretending the plan has any hope of accuracy, that new information won’t change the plans (or design) and that the plan you started with will still even be beneficial when you finish. Brittleness. Dependency planning has to happen of course. That’s not unique to waterfall, it’s just planning.

I agree with this. But why not waterfall out 90 days then? Or 75 or something

You’re basically describing Scaled Agile. They have big planning meetings every 8-12 weeks (called PI Planning) where devs make a plan based on priorities, work out dependencies and get agreement with the business side of the house about the plan itself.

In my opinion, it’s the ideal balance of concerns.

Re: Even with Agile and Scrum waterfall will sneak in

#187

Post by gilbetron »

boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. 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 ste…

Traditional waterfall model doesn't allow for iteration between the main steps, and this was followed historically, and caused absolutely massive delays and cost overruns in projects through the 70s, 80, and 90s. Popping iteration onto Waterfall model and still calling it Waterfall model is being disingenuous.

Re: Even with Agile and Scrum waterfall will sneak in

#189

Post by AnimalMuppet »

boffinAudio wrote: post #56
littlecranky67 wrote: post #18

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…

When I was a kid, I remember we topped over this hill on I-15. Way down there in the distance, there was an overpass across the road. I remember wondering how my dad could aim the car accurately enough to go under that overpass from that far away. As an adult, I know that he didn't even try to do that. Instead, he steered the car as a continual process, not just once.

That's the same kind of problem with waterfall. You want them to do the analysis perfectly, and then you want the world to not move while the implementation happens. Neither of those is possible. And then you blame the analysts for failing to do the impossible.

The analysis phase is never complete enough. The conditions are never the same by the time the implementation is complete. That's just reality. What are you going to do about it? You need to steer during implementation, not just once at the beginning.

Re: Even with Agile and Scrum waterfall will sneak in

#190

Post by karaterobot »

boffinAudio wrote: post #10

I've never quite understood, over 30 years of experience in software development, what problems Waterfall presented that warranted a complete refactor of software development processes such that things are now very much in cult-/cargo-cult territory. 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 ste…

For what it's worth, I've never been on an agile team that did not have some waterfall decision making that was not open to correction, or a waterfall-based process that was totally closed off to testing and making changing along the way. I think we argue about platonic archetypes that don't exist in reality. Most processes and teams I've worked with have resembled each other more than not, if you ignore the terminology they use. I think success or failure of a project comes down to a lot of factors that are hard to quantify, so in some sense our focus on process methodology is a bit ritualistic and cargo culty.
Post reply on HN