Hacker News Reader

Comment by BFLpL0QNek | Hacker News Reader

Even 10-15 years ago I was at a small Thoughtworks event where Martin Fowler was speaking and back then he was using the term “Water-Scrum-Fall” saying most Agile projects he’s seen are waterfall projects wrapped in to two week sprints. At the time Agile/Scrum didn’t have the popularity and only just gaining traction at larger companies.

Today everywhere I work is now “Agile”, doing scrum or similar. It’s all lip service, it’s just another process and ceremonies over the actual spirit and ethos of the original manifesto.

The teams I’ve worked on who didn’t practice agile where actually the most “agile” in the spirit of the manifesto. The teams that did agile, by the book, with the ceremonies and all, dogmatically, doubling down on it, where the least agile in the spirit of the manifesto and not that productive or creative, often micromanaging every tiny detail in a Jira ticket.

View on HN

Having worked in actual "waterfall" (which is just a perjorative term) environment in the defense industry long ago, scrum is quite a bit worse in overhead, amount of nonsense, waste, inflexibility, etc.

Agile/scrum is a codeword for "we don't want to / know how to / haven't ever experienced long term planning, but we're going to do it anyway".

Yup. If you're at a shop that is openly waterfall, they do the requirements gathering and design/prototype work up front so the planning is based on something approaching reality.

"Scrum" has become waterfall without the pre-work so it often descends into iteratively pulling estimates out of your asses.

And the worst part about it. Holding your ass to the flame over your shit estimate.

Definitely my experience of Scrum! In my part of a FAANG we do a sort of sloppy waterfall and honestly it's the most effective method I've found.

Waterfall was a problem too for those who focused on it to the exclusion of "individuals and interactions". Planning is good, being attached to a plan is not.

I feel you, and I'm not in software, nominally I'm a Product Owner from the business side. As a business we didn't understand the problem we are facing yet, we have no strategy how to tackle the problem in limited time and with the limited resources we have. And since two weeks Dev Ops is pushing me to come up with a headcount estimate to develop the software solutions we need. Because, of course, upper management needs resource estimates to come up with a reduced budget. It's a mess. And our BPO is fully on-board with this, because career opportunities. And the other POs have close to no experience. The DevOps head never had any IT experience before he became DevOps. We have a whole bunch scrum masters, agile coaches and the like. We have zero functional consultants, and we are looking at an ERP implementation project here. Oh, and the last developer we had on the project didn't see the difference between a technical and a business go-live or the need to conduct proper use-case based user acceptance tests. Or proper requirements definitions, because, you know, agile. It's a mess.

GE, is that you?

I have done CMMC3 waterfall development, though the maturity model certainly did not dictate that. I have also seen agile done in the way you describe. I have also been on teams and run teams that used agile ceremonies to foster communication and teamwork and set a cadence, while long term planning was going on elsewhere. The two are not mutually exclusive, and even mediocre agile is miles better for delivering working software than bad waterfall.

> even mediocre agile is miles better for delivering working software than bad waterfall.

Well, mediocre anything is usually better than bad something.

Scrum was designed for low trust environments where you have to constantly demonstrate that you are worth your salary, ie consultants. Scrum gives a constant stream of status updates to show you make progress and blocker reports to cover you ass and shift blame to the client, that is very important for consultants but shouldn't be needed in high trust environments.

Agile is also for projects where the customer doesn't know what they want exactly, but they do have an idea what problem they want solved. With an agile project they can pull the plug if stuff doesn't work and they can pivot (within reason) to new features that are discovered during the process.

I have friend in a defence sector waterfall project. It was meticulously planned years ago, the design was locked. Production was started. Everyone knows it'll get scrapped for being out of date when it's finished on schedule in 2024. But they need to finish it anyway, because the deal is hard-locked and there is a big penalty for not delivering or delivering late.

Since the system your friend is implementing is already outdated... does that mean that someone else on the defense sector created a better system with a faster development process? Or did the competing developers simply make a better guess at what they should develop in their own own waterfall process?

Military secrets gotten from a drunken friend and all.

But let's say that the problem they're solving doesn't exist anymore, tech advanced and you can get 90% of the same functionality with off the shelf stuff =)

> where the customer doesn't know what they want exactly, but they do have an idea what problem they want solved

But they also know they need it by Tuesday.

To be clear you and the comment above are describing two different problems. "Water-Scrum-Fall" implies that too much planning was already done up front and the work is just divided into arbitrary 2 week milestones. You are describing a problem where product thinks they don't need to plan long term because they are using "agile". A good product team is somewhere in the middle. A long term user/product vision without getting too specific in implementation or feature priority so that the team can pivot as needed without eating too much cost (there is still a cost to a pivot).

Yeah, at my current place agile is also used for the hardware development side of things. And in all cases, hardware and software, it is, IMHO, just a pure excuse for non-existent requirements management (hardware) or no clue what the business actually needs (software).

Scrum is ritual heavy process by definition. There is no way to do scrum without being heavy on process or dogmatic. The moment you start doing that, your process cease to he Scrum (and any advocate will point at your difference against process as reason why it issues are not cause by Scrum and why it is not scrum)

Is it a heavy process when you compare it to stuff like Scaled Agile Framework (https://www.scaledagileframework.com/)?

Genuinely, I have no idea. Never seen that in practice and I am reading about it first time. That is based on first quick glance at the link you sent.

Honestly, from all I've heard and read about "SAFe", it feels like "Take the already-not-very-agile Scrum, and squeeze the last vestiges of agility out of it to make it Enterprise Certified".

Scrum is waterfall in disguise and it always has been. I have never seen scrum be anything but a catastrophe, or a token gesture to appease those who would replace accountability with process.

Scrum doesn't work unless the whole organisation implements it.

I have seen scrum turn into hell more then once and it had zero to do with rest of organization doing anything. Literally each time, there was no evil customer pressuring us too much or making bad demands, nothing like that.

Thing is, Scrum doesn't work for most of the organization.

Sales use a sales funnel as their guiding organizational tool. IT operations and support do reactionary work on incoming tickets, and some rather routine and planned projects. HR is almost all routine paperpushing. Legal has to take the time it takes to answer the questions they get, because they have to answer correctly. Market analysis is timeboxed analysis - a spike in agile lingo. Hardware design is innately waterfall. Hardware production is just mindless repetitiveness as fast as you can go... and so on...

They're all different!

I found Kanban a lot better for this. You have a sorted list of tasks, and you can only work on a small amount of them at once. A lot less time is spent estimating tasks to fit them in a pointless two week bucket.

Backlog grooming can be done asynchronously, constantly. The PM can push a task to the top without making the developers work harder this sprint. They can go faster or get delayed, because they don't have to meet the arbitrary requirements of a sprint.

>The teams I’ve worked on who didn’t practice agile where actually the most “agile” in the spirit of the manifesto. The teams that did agile, by the book, with the ceremonies and all, dogmatically, doubling down on it, where the least agile in the spirit of the manifesto and not that productive or creative, often micromanaging every tiny detail in a Jira ticket.

Personally I have noticed opposite scrum works if you run it by the book first and then start tinkering process based on retros and this "agile" does not work where you implement something that kinda looks scrum or kanban and kinda mess major part like estimates are hours etc. It is not ideal but low trust or multiple stakeholders it works.

I'll add that empowering the development team via retrospectives and actual authority while having a single interface to the business via product owner are huge contributors to the agility of a team in my opinion.

Reply on news.ycombinator.com