[colechristensen]

At least "waterfall" never existed, it was invented by people to describe something somebody else was doing.

The design-build-test cycle necessary for physical products where the build and test phases can take days, weeks, or years was being used for software where build/test can take seconds or at most hours -- faster design cycles are beneficial and lots of folks used to engineering things got stuck with really long cycles. You don't need a management framework to accomplish those faster cycles.

[paulmd]

In most cases what you need is management permission to move quicker. Everyone says they want to be agile, but doesn't want to invest in the tooling (unit and integration tests, build servers, etc) that would let you be agile, so you end up with agile overlaid over the waterfall methodology, which does absolutely nothing.

[bmj]

I would argue that management often doesn't truly understand "Agile" beyond "software engineers should operate this way." In my organization, the engineers are willing to be disciplined with Agile practices, but product management has no interest in real planning that would achieve a manageable backlog across releases. Instead, they change release scope numerous times, and nearly every release cycle runs long because we never finish what we start--by the final iteration we are working on entirely different stories than what we groomed in iteration #1. To them, "agile" means "do what we want whenever we want it."

[shandor]

> "do what we want whenever we want it."

Isn't that quite well in accordance of Agile Manifesto's "Responding to change over following a plan"?

Sprints and backlogs and grooming, all those sound they're straight from the Scrum Book. And while I understand that for many Scrum == Agile, actually it's not.

Note that I'm not saying anything about what's the best way to do software. Only that "responding to change" sounds very much agile.

[projektfu]

This sort of thing happens all the time. The Japanese-style quality movement had many different fads (for example 5S) but most of the top denizens said that there are some basic universal facts about quality but every organization has to develop their own system that works. Consultants can help you do that but you can't follow a textbook and make a company. By contrast, the American quality movement has always been filled with charlatans and fads like "Zero Defects". Do Americans want religion and not mastery? Who knows.

I see Scrum a lot like I see Six Sigma. They take some of the processes you see from a successful team and they turn them into gospel for managing all teams. Sometimes they try to apply these processes to the rest of the company in places where they don't make sense. They create a bunch of certification levels so that they can claim you can't just learn it from a book. They make a bunch of money but leave their clients in a strange place.

[ahi]

That's my organization. Most of the actual work doesn't go through either process because the engineers know if they start discussing things in the sprint planning a manager will pick it up for a multi-year "investigation".

[derekp7]

Fortunately with cloud and open source tooling, there isn't anything to buy. And management is already excited about cloud because they read it in CIO magazine and their buddies mention it on the golf course.

The only thing needed is training on proper usage of the tooling. But that can come about organically when companies accidently hire a few competent engineers.

[chrisseaton]

> At least "waterfall" never existed

The waterfall paper criticised a process that did exist and still does exist in some companies - it didn’t make it up.

[coldcode]

But people dragged the diagram out of the paper to create the idea that waterfall was a good thing. Boyce actually made fun of the idea.

[chrisseaton]

Yes I know - but the point is it did exist. What were they naming and making fun of if it didn't even exist?