frenofafren
25431
561
18
Apr 10, 2025 7:25 PM
frenofafren
25431
561
18
somnif
It failed because you didn't keep your Jira swimlanes clean, obviously. (shudder)
eronth
Boy that really oversells the value of waterfall.
sadurdaynight
Agile development ... we have a rocket that flies. But, you don't want to modify and use THAT old rocket. You want an ALL NEW rocket! Built from the ground up! Using new technology we don't know how to use, so a learning curve is involved. And 3rd party vendors that can hold our project hostage. And the PM's don't adjust the timeline to account for any of this. So you end up with a new half-assed rocket that does what the old one does, and folks are upset.
OrThatsWhatTheySayAnyway
But in a tangibly different way that disrupts all processes and tools developed over years with the old rocket for an array of activities that occur before, after and even in intervals during the rocket flying phase. The whole enterprise is less productive, ppl are told to suck it. Folks are very upset. Some of them leave.
NoLoveJustBots
its all true, except the first one, this is more like: you write 700 pages on how to go to mars, you make 4 extra hours/day for 2 years, you forgot the cockpit
ElbowDeepInAGoblin
Scrum: https://dwarffortresswiki.org/index.php/Strange_mood
hsalonen3000
I have MSc Minor in Software Engineering Methods. I have used Kanban, been a Scrum Master and am currently using version of Agile. Lean is something I have studied and read about, but never had in practice. I find that most people , specially in America, lie in their resumes about this shit, and in reality are using only a cherry picked subset of these methods (Kent Beck was against this), and this guy sorta knows, what it was like .. in 2019..
IconicM
The entire point of agile is teams are supposed to self-organize and figure out what works best for themselves.
meccit
'Lean': "this means we don't have to write documentation, right?"
PaulManley101
I worked in software dev for 20 years as a manager. You do the things that work well for your team. Change the things that don't. The ideology/process/method part is a distraction. Things get done by people who want to do them , IE, invest in the people.
possumEnjoyer
This comment should be enshrined in bronze and polished daily
hsalonen3000
What currently works for us (big corp) is that we have agile coaches roaming between teams and helping with the adoptation. I have also been to startups and things work differently there, because our processes need to scale. When you have 1000+ employees, it is utter chaos without processes, but if you have like 10, you can do whatever you want and adding a process might actually slow you down.
PaulManley101
Oh that's interesting, my BigCorp ( 1000+ engineers ) days they had "The Process", and it was bad.... or really it just worked for the "main" team in Israel, but I managed teams where we had M&A'd them, so each team was super different. ( Like we bought a company, technology, software, people )
Getting people to move to "The Process" was the easiest way to get a lot of devs to quit.
TheFishFace
This fails to say anything accurate, and hence anything funny, about protect organisation methods.
ElbowDeepInAGoblin
In fact, it failed to say anything accurate or inaccurate about protect organization methods because it isn't a comic about security arrangement.
TheFishFace
Huh?
ElbowDeepInAGoblin
"protect organisation methods" = security arrangement
TheFishFace
Oh
SkinlessWizard
Found the pencil pushing middle manager!
TheFishFace
Guess again, Internet person.
Tell me, in what way does kanban favour making small tasks more than any other method? Where is the big distinction of scrum - sprints and the associated rituals - highlighted? Etc
wadatahmydamie
SpaceX development: Lie about wanting to go to Mars, fly to Epstein Island instead
BeaverOnFire
ElbowDeepInAGoblin
SpaceX would be stupid even if dude did wanna go to Mars. A defeatist mindset and myopic to boot. 'This planet's fucked. Screw it. Mars!' - Why not just fix the problems HERE (possibly automate pollution-churning factory ops, relocate them to space stations). The planet will heal then. Otherwise we'll just hit the same issues on Mars anyway.
Cindex1337
People like to pretend that the goal was to make Mars into a second Earth, but it was never the plan. Just like a moon base isn't like settling an island.
Shaodyn
Lie about wanting to go to Mars, never actually go anywhere at all, tell everyone your enemies sabotaged you.
MoonRiverFrost
hetriedtokillmewithaforklift
bUt YoU dIdN't UsE sCrUm CoRrEcTlY!
stblackbird
OMFG being evangelical about a management method... Let the Devs do their damn work
Zaranthan
These fad dev cycles always fall back on the classic cult technique of "if following the plan doesn't solve the problem, you didn't follow the plan right."
apLundell
And it's even true. Because all of these fed dev cycles are only possible if the dev team is independently wealthy. If you have to report to a boss, you can't apply them in their pure form, because that's not how business works. So you make compromises, and then when the fad dev cycle fails, the adherents will blame the compromises. Never mind that the plan wasn't even possible without the compromises.
GoodChange
A comic made by someone who knows nothing of project methodology, planning or execution.
ThingsThatDontJustifyGenocide
They used the Lean method
ArcaneConjecture
The point is that NOBODY knows anything about project methodology, planning or execution. Nobody.
TravelingTableTop
A comment by someone who insists on daily standups and is everyone's least favorite person to see typing on Teams.
hobbitdude13
A comment made by someone who knows nothing about the condensing of a topic for purposes of humor.
SpaceballsTheComment
It's funny tho
Marsupialmessiah
I work with kanbans as part of the toolkits we are provided for projects and it is on point
WoeToHice
Having been a professional software developer for 25 years, I agree with the sentiment of the comic. All this time that I've worked in this industry, people have been fucking up projects regardless of what process was supposed to solve that. The Agile Manifesto was well-meant, but what it ended up achieving is shifting the responsibility of many different roles onto the engineers, along with the burden of blame for failure, without even raising our wages in proportion to that.
jridley
Agreed. I'm retired now, but: when I first went to my last job, we just went to work, everyone got assigned a task list for the year, we went in every day and worked on it. Everything got done. We spent maybe 3 hours a YEAR in formal meetings. If we needed anything we just talked to the right people. We didn't report we just did stuff.
Later management got methodology religion, we spent sometimes 3 hours a DAY in meetings. Spent countless hours reporting progress instead of MAKING progress.
Mohareb
That's a very optimistic waterfall
OlemGolem
You want to go Mars.
You build a rocket but it took longer than planned.
Because it took longer than planned, the testing department now has half as much time to test it than planned.
The test results are in and there are more developments to be done but there is no time left.
The rocket fails to launch to Mars.
Togame21
I mean, NASA objectively didn't do it waterfall-like. They did an enormous amount of experiments, both in labs and with unmanned test flights, and even a lot of the manned flight were full of uncertainty. Then they used all that data to build a rocket to go to the moon, but it would never have worked without those tests. Sounds like a modified form of agile to me, where instead of a shippable product you go for a worthwhile experiment.
hsalonen3000
Waterfall would be probably more like: You spend a year planning and collecting requirements. You start development, but it falls behind schedule. In the end, tests fail. The decision is made to add more people to the project. Specs become outdated, first coders have left the company. The project continues for 10 years, and is shutdown after funding ends. Last person turns off the lights.
hsalonen3000
The problem with waterfall is a long development cycle without guaranteed results. You have to redo that, you are doing a shitload work again. And in long cycle. That can fail again and again..
ghostofGracchusBabeuf
Not pictured: literally half the mars-bound rockets explode and kill their crews
7thSonOfANinja
This was written by engineer and not a software engineer
WoeToHice
Ironically, the comic wasn't made by an engineer at all. The guy who made it, Mart Virkus, works in marketing.
TinyBadger101
Aye, my thought as well. Waterfall never works like that, there's a reason everyone stopped using it. Agile methodologies (Scrum and Kanban are both Agile methodologies, there is no one "Agile") have their own issues, but there's a reason everyone stopped using Waterfall as much as possible. It just didn't work.
WoeToHice
That's the problem, though. Agile also "never works like that", because the process is a lesser problem than the people. Waterfall is like having a union, capital-A Agile is like capitalism. Both can work, but both can be taken to unhealthy extremes.
tater1337
Oldest and most successful method
LebistusReticulatis
Waterfall is more like: you build with wrong and outdated specs, outdated tools and not enough money. Build something that’s within the specs. Release it and end up halfway the atmosphere
HypersonicHero
Counterpoint. BFR is closer to Agile and has blown up or failed almost half it's flights whereas SLS is waterfall and has actually gotten around the moon and back.
Meltemi
Aim for the stars and hit London instead.
Zahnradfee
Goddammit, not again!
agonarch
Waterfall requires you to have a pretty good idea up front of requirements, and no surprises. Only thing is, there's always surprises. A rocket/plane/car variant might be a good place for it but for a prototype it's gonna be a crapshoot.
If you look into the development of Crysis you can see some really good comparisons, they started Waterfall but 'switched' (restarted) to an agile methodology part way through. I would say waterfall is never appropriate for software today.
Remmon1
Crucially, waterfall is "You hire scientists to develop a rocket engine, then fire them or put them on another project while designers design a rocket to go to Mars with that engine. Then engineers have to build the designer's designs (the designers are fired or on another project by now of course). Once the rocket is built, the ops team has to train the astronauts and fly the rocket to Mars."
NoNameFred
(Also, neither Mars nor the Earth are in the same location as when the project started, but no one thought to update the flight path. Theoretically, your rocket is capable of reaching Mars — but it's currently pointing in the wrong direction)
LebistusReticulatis
I would like to give you two upvotes at ones. Great comment!
Remmon1
The problem being that if the designers or enginers run into a problem that requires a redesign/science solution, the people responsible have moved on and are no longer readily available to help fix the problem.
The whole point of Agile development methods is to put those scientists, designers, engineers, ops and astronauts all on the team together so they can work on the whole project together.
And of course, very few large corporations do agile of any kind properly.
HisRoyalMajestyKingV
I dunno. Back in the day, Waterfall worked pretty well. I figured people abandoned it because there felt they'd be seen as not following the latest trends.
HelpfulCorn
It works well for deterministic things. Software cannot be easily estimated or completely designed up front, so waterfall never works
spookyactionatadistance
They abandoned it for the fact that the standard EN method of engineering projects did not work for software engineering. I can build an almost complete login/authentication solution without needing the profile management feature to be complete.
tangent
People forget that waterfall is meant to be agile. You analyse, design, implement then test. Then go back to analyse, not ship.
WoeToHice
Nah, it was the greed. Waterfall was too bureaucratic for the businessmen who wanted to make money. Notice how Agile Manifesto says "customer collaboration over contract negotiation"? You can't make money by slapping contractual penalties on an unreasonable customer, especially if your competition is willing to work their engineers to exhaustion. Not that the engineers were blameless, either. Give people the hope that they can get filthy rich and they'll work themselves sick trying.
iDrinkDrano
As a former SCRUM manager who used to swear by agile, I've been in the industry long enough to realize that Agile is mostly hogwash and that most decent waterfall has the QA and revisions along the way anyway
WoeToHice
GWJYonder
I feel like Agile is just a good way to operate when things change a lot or you have dev and qa resources available before product owners actually have a full plan (or even full requirements). It seems like in an environment where the POs and BAs actually have all of those things sorted the agile process basically gets closer and closer to a waterfall.
iDrinkDrano
Maybe the fuckers should make a plan first. Tech has been shooting from the hip for a while now -- do you feel like it has given us the highest quality products as a result of "move fast and break things"? Because I feel like the enshittification speaks for itself.
GWJYonder
I don't think that that's largely the issue, at least not directly. While agile development can definitely be a bit more haphazard, even when there is a clearer goal there are still other failures that more directly lead to enshittification.
1. The "move fast and break things" should be relegated to pre-release or closed beta. Even with agile a robust set of unit tests, integration tests, actual human QA, and the Product Owners "Acceptance Testing" should be enough to provide a stable product 1/
spookyactionatadistance
So how do you evaluate a development time of a feature that has no mockups and is still being changed. Our boss asked us to evaluate our whole app refresh. It's about 14 months. I evaluated 75% of components I have no idea about what they look, animations, what graphs will be shown, how the graphs will be designed. So we added 25-30% to everything even though by month 3 ill probably have finished the 120 reusable components will need in the whole app.
iDrinkDrano
If I understand your situation right, you're describing what is the Analysis stage of Waterfall. The owners have given you their Requirements (Evaluate the app refresh -- why you're doing it, what the desired user experience is, what the desired business outcome is, etc) and now you need to calculate the resources you'll need and how you will measure success. This should involve all developers or at least the leads, depending on the scale of the project. Once the analysis is done, it should be -
spookyactionatadistance
That is already all done for the first 'module'. Backend development started before the designer had wireframes because there was a stack change and a DB change. I usually would refuse to start until I get at least a complete mockup but our designer does very detailed wireframes and I was able to do almost all API calls, display logic models, DTO, etc and the when the mockuos where ready I could just focus on creating the theme, typo, and component library. We are a small team,
iDrinkDrano
- presented to the owners so that they have a good idea on what the cost will be. Expect to have to defend your budget and ideas.
The step after that is Design, which is where the frontend can be made.
Waterfall does not necessitate being siloed. The programmers should be in the analysis step as much as the designers, so that everyone is working in anticipation of each other's needs. The two should remain in communication during the Design or Coding phases, to react to each other and tweak.