9 ms·

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 Agi

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.

colechristensen 4y ago
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".
- badlucklottery 4y ago
  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.
  - xeromal 4y ago
    And the worst part about it. Holding your ass to the flame over your shit estimate.
  - mrwh 4y ago
    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.
  - galangalalgol 4y ago
    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.
  - hef19898 4y ago
    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.
    - datavirtue 4y ago
      GE, is that you?
- flatline 4y ago
  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.
  - CRConrad 4y ago
    > even mediocre agile is miles better for delivering working software than bad waterfall. Well, mediocre anything is usually better than bad something.
- Jensson 4y ago
  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.
- theshrike79 4y ago
  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.
  - unnah 4y ago
    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?
    - theshrike79 4y ago
      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 =)
  - commandlinefan 4y ago
    > 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.
- TheBigSalad 4y ago
  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).
- hef19898 4y ago
  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).
watwut 4y ago
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)
- s-lambert 4y ago
  Is it a heavy process when you compare it to stuff like Scaled Agile Framework (https://www.scaledagileframework.com/ https://www.scaledagileframework.com/)?
  - watwut 4y ago
    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.
  - CRConrad 4y ago
    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".
- galangalalgol 4y ago
  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.
  - theshrike79 4y ago
    Scrum doesn't work unless the whole organisation implements it.
    - watwut 4y ago
      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.
antupis 4y ago
>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.
kodah 4y ago
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.

colechristensen 4y ago

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

badlucklottery 4y ago
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.
- xeromal 4y ago
  And the worst part about it. Holding your ass to the flame over your shit estimate.
- mrwh 4y ago
  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.
- galangalalgol 4y ago
  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.
- hef19898 4y ago
  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.
  - datavirtue 4y ago
    GE, is that you?
flatline 4y ago
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.
- CRConrad 4y ago
  > even mediocre agile is miles better for delivering working software than bad waterfall. Well, mediocre anything is usually better than bad something.
Jensson 4y ago
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.
theshrike79 4y ago
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.
- unnah 4y ago
  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?
  - theshrike79 4y ago
    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 =)
- commandlinefan 4y ago
  > 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.
TheBigSalad 4y ago
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).
hef19898 4y ago
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).

watwut 4y ago

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)

s-lambert 4y ago
Is it a heavy process when you compare it to stuff like Scaled Agile Framework (https://www.scaledagileframework.com/ https://www.scaledagileframework.com/)?
- watwut 4y ago
  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.
- CRConrad 4y ago
  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".
galangalalgol 4y ago
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.
- theshrike79 4y ago
  Scrum doesn't work unless the whole organisation implements it.
  - watwut 4y ago
    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.

antupis 4y ago

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

kodah 4y ago

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.