Good for you. Some of us old-timers have lived through pure waterfall, waterfall-inspired, and guilt and shame for not doing waterfall right.

The guilt and shame is so spot on. Living though such projects illustrated so well the "the beatings will continue until morale improves" project management school of thoughts.

This school has its agile proponents too, though. But compared to the common practices of the penultimate decade, XP and Agile at least acknowledged that failure was the default mode of software development projects, and made contingency plans for it.

I was part of a development organization that, driven by guilt and shame, tried to mature and improve their "ad-hoc" processes by fully embracing by-the-book waterfall.

To me it felt like they were saying, "You know all the things you did to make your last project a huge success: the short iterations, tight feedback loops, early and frequent customer involvement, designing your systems to accommodate change? Yeah, don't ever do any of that again."

So I left, and found that dogmatic by-the-book scrum shops can also be horrible places to work. Live and learn.

> The guilt and shame is so spot on

Absolutely. If the waterfall isn't working, you need to waterfall harder. Because more time spent up front writing paper architectures and guesswork requirements is what's needed!

oh, don't get me wrong i've worked in that environment, but its just a natural naive way of doing things - dignifying it with a name seems to be something that happened later