Live data from Hacker News

Even with Agile and Scrum waterfall will sneak in

amazingcto.com

51–60 of 319 posts

Re: Even with Agile and Scrum waterfall will sneak in

#51

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…

???

It's predictability.

You can plan the construction of a building, because the elements are known. If someone fails to deliver a bag of nails on time, it won't matter.

If you add labour to a project, it will very ballpark accelerate linearly.

1 team, 10 houses = 10 weeks, 2 teams 10 houses, = 5 weeks. Ballpark.

More developers do not mean the software will be finished more quickly.

There are economies of focus in software, generally not scale.

Which is why you want good developers.

The other factor is that 'Requirements Change' in Software more than they do in building, and that's the other #1 issue that causes problems.

The entire ethos of 'small releases, often' is built around that.

Software is evolved a big organically for this reason.

Waterfall is obviously counterproductive.

If there is a 'default' methodology in software it's 'Iterative Waterfall' whereby you break the project down into the smallest reasonable phases. There can be an overarching plan but it has to be nimble.

Re: Even with Agile and Scrum waterfall will sneak in

#52

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…

Ahhhh, I couldn’t have put this better myself. Agile is forcing devs to change how they work to solve a problem caused by poor product and business management and all the problems it creates are swept under the rug as “technical debt”

Re: Even with Agile and Scrum waterfall will sneak in

#53
post #9

To this day I still don’t understand how one can read the agile manifesto and somehow get to scrum. The whole thing is about processes, and tools (jira)… the complete opposite. The reason everyone ends up doing waterfall is that it’s not the devs who you need to convince when selling agility, is the chain of command. Being agile means having no long term plan. If the C-suite can’t handle that, you’ll never be agile.

In Scrum, the team should be self-managing. The Product Owner and Scrum Master are not managers or bosses, they're a customer representative and a secretary. I can see that working with "people over process".

But then came certification, existing managers et cetera and that was lost.

Re: Even with Agile and Scrum waterfall will sneak in

#54

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…

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

It's refreshing to see someone else make this point.

Re: Even with Agile and Scrum waterfall will sneak in

#55

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…

This problem is not a problem of project management methodologies, but rather a problem of business strategy and scope management. If you want to fly to the moon with one shot, that is exactly it. Breaking down scope into smaller and better understood objectives is what will make things work and that should happen before a project starts. Afterwards it can be executed both as one big waterfall sprint for each objecti…

Perfect example of unclear formulated goal of the project. You say "fly to the moon with one shot" and think it is completely defined. But the whole, year-long project would change in scope whether you mean "Land on the moon unmanned", "Land a man on the moon", "Land a man on the moon AND return him safely to earth" or "Flyby the moon, get close to surface and take some pictures".

And if you now accept that any of those above goals may be changed into another during project runtime, you understood why waterfall is not often the best idea.

Re: Even with Agile and Scrum waterfall will sneak in

#56

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…

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/Specification/Requirements phase, with relevant qualifications steps. It doesn't matter if you're a Manager or a lowly Developer - if you can't adequately qualify the requirements and specifications, the analysis is simply not complete.

Pushing the problem to or away- from Managers is just one way of saying "I'm too lazy/incompetent to adequately complete the Analysis phase, resulting in poor requirements, lacking or contradictory specifications, and no planning". Its the Analysis that needs attention, i.e. maybe nobody actually knows how to wear the Analysts hat any more ..

Re: Even with Agile and Scrum waterfall will sneak in

#57

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…

The problem is that the more unknowable the future is, the quicker your plans about the future will be invalidated.

Thus a quick iterative feedback loop where there is a tight lead time between user feedback and users using the software tends to work better because it lets you adapt much more quickly to changing circumstances.

This is why I always aim to minimize that feedback loop as much as is feasible.

Unfortunately you are right that it got bound up in a pseudo cult. Worse, the cultish practitioners tend to do as all cults do and put their emphasis on ritual (e.g. standup) and completely miss everything else.

I kind of hate the term agile now precisely because the movement almost set out to create a cult out of this.

Re: Even with Agile and Scrum waterfall will sneak in

#58
post #24
post #2

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to stri…

> As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity. This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....". JIRA bur…

> "Yesterday I committed to... and did/did not achieve this because..." "By this time tomorrow I commit to delivering....".

99% of the time this is an underhanded way to implement micromanagement.

Re: Even with Agile and Scrum waterfall will sneak in

#59
post #45

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…

Additionally, as a start-up, we rarely know what the product should be. We have a first vague idea of the product but don't know what it exactly is. Commonly, the ideal product is different from the initial design, and we only know that after the actual design, investigation and development. If it's the nature of software development, the development framework should be capable of design change in short terms. Agile…

"Agile" just means "analyse the situation until you have properly fleshed out specifications, great requirements that will solve the problem as described, and a proper plan for development".

Still, "Analyze until Completion" doesn't need to be couched in fancy new-age terms that someone will get paid to teach everyone ..

Re: Even with Agile and Scrum waterfall will sneak in

#60

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…

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…

> Almost always, your customer doesn't know what they want - they think they do, but they don't

I honestly don't understand this statement. Could you provide an example to elaborate on this point? I have read it at so many places but it sound more like the fashionable thing to say.

The "need" have a starting point, may be a very high level problem statement, and then through analysis, back and forth question answering, you discover the need in more concrete terms instead of abstract terms where you started with.

Post reply on HN