Live data from Hacker News

Even with Agile and Scrum waterfall will sneak in

amazingcto.com

201–210 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#201

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. If you do this feature by feature than you have descr…

I've worked on all kinds of projects, and every single time the project failed, the tooling and methodology were blamed, not the individuals. This is the #1 cause of failed software projects - the inability for individuals to take responsibility for parts of the workflow, for which they are incompetent , and not subsequently working on improving that competence at an individual level. But true, breaking larger proble…

So when waterfall doesn't work, it's the fault of the developers, who are doing it badly? Well, I've seen agile work, too, with really good developers. And plenty of people have seen both fail, if you don't have good enough developers. Hmm, maybe it's not the methodology?

Re: Even with Agile and Scrum waterfall will sneak in

#202

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.

And cost overruns and delays in the 00s and 10s! People here on HN keep telling me I'm imagining things, that Waterfall either isn't bad or isn't real. But a 9-figure project I was (fortunately briefly, though not brief enough, around 1 year) on was several years late and delivered only half the features the users needed. Why? Because they made the plan in the mid-00s, and the circumstances changed but the plan didn't. They did what Waterfall describes, they committed to their initial analysis and plan and never looked back. Fortunately they learned after that, but it was a costly exercise.

Re: Even with Agile and Scrum waterfall will sneak in

#203

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…

Here's one way to explain it: The generalization is that waterfall is a form of organization level open loop control and scrum is a form of organization-level closed loop control of your process. In one case you set a goal and then move towards it (and "damn the torpedos"). In the other case you stop and look where you're going and adjust course at regular intervals iteratively (But "are we there yet?"). In real-time…

This. So much this.

Especially this bit:

> In the case of closed loop cargo cultists: They might end up taking cruder faster steps, but then don't actually close the loop by going back to the start and iterating.

Agile isn't about having standups. It's about having fast feedback, so that you can react to what you have learned. If you don't have that, you don't have agile, no matter what process you have in place. (For that matter, any time you are trying to do agile by a rigidly defined process, that's an oxymoron.)

Re: Even with Agile and Scrum waterfall will sneak in

#205

Earlier quoted context omitted.

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

I've seen it done well, so it can be done.

Plenty of people have seen waterfall done badly.

Maybe it's so easy to get software development wrong. It's not just agile.

Re: Even with Agile and Scrum waterfall will sneak in

#206
post #185

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

"Waterfall out 90 days" is not what is derided as Waterfall. The derided form of Waterfall is for large applications and commitments, 90 days is small in context. That's the prototype phase of a project that Waterfall may be applied to.

The basic model of Waterfall is, indeed, fine if you iterate, which then isn't Waterfall. The basic model + iteration + shorter timeframes (probably under 90 days, certainly under 180) is basically just the same plan-do-check-act cycle from Deming (and others). You want it to be shorter so you can respond to new information (including the results of the partially developed system). Waterfall, the derided form, doesn't give you feedback until final delivery, or maybe the phase called "FQT" (final qualification testing). Importantly, until the customer is re-involved (which may happen in FQT or in delivery) you don't get revalidation of the system.

System engineers learned and applied this as far back as the 1950s, at least. No serious large scale system uses Waterfall and reliably succeeds.

Re: Even with Agile and Scrum waterfall will sneak in

#207

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…

Maybe it is natural, but instinct isn't always best.

All you need to see is that its obvious that if you don't have continuous design/stakeholder feedback you can spend a lot of resources building the wrong thing. A lot of work is put into preventing this.

The cargo culting and snake oil sales exist but its just a fact of life not exclusive to agile methods.

Re: Even with Agile and Scrum waterfall will sneak in

#210
post #77

Earlier quoted context omitted.

"Agile" processes still have all these steps, they just repeat them in a loop on a much smaller timescale. This allows for a lot more flexibility, and for feedback from the qualification of the first iteration to go in as input to the analysis stage of the next iteration.

I agree with that. But it's worth noting that we need to spend more time on task management with a shorter development cycle. In waterfall or scrum or whatever, one development cycle often comes with listing tasks, prioritizing, planning, developing, retrospection, or something similar. If the cycle is long, we can spend more time on each process. But if the cycle is short, we rush to complete each process and can't…

Sure, but that's kind of tangential isn't it? You can just churn through tickets thoughtlessly in both methods, no?
Post reply on HN