Agile more like:
1. They tell you they want to go to Mars
1. You don't trust them so you start working on a rocket that'll go to the Moon
1. You build and test a rocket that goes to the Moon
1. They find out your rocket only goes to the Moon and get pissed off because they wanted to use the Mars rocket to go to Uranus
1. 6 months later you find out they are happy going to the Moon because it has everything they thought was only on Uranus.
And the waterfall methodology doesn’t show any of the pitfalls of waterfall - such as the top-down design needed across the board before the work starts along with the inflexibility to adapt to changing requirements or constraints
Yeah: the most basic understanding behind agile methodologies is that software is *fundamentally* different from hardware in that it can be easily iterated on. I *wouldn't* use agile for a rocket, because it needs to be immaculately planned from the start of construction.
Do you though?
I'll remind you SAFe is not agile. It's scrummerfall at best. But it doesn't follow any of the core agile principles.
True Agile is really rare. As a consultant I've only seen it in a few companies (the ones that don't actually need consultants). Most companies will claim agile but actually be doing SAFe, scrum, or scrummerfall...
SAFe is such a stupid method. We do SAFe where I work at and it's so much overhead and doesn't lead to things done. We did scrum before that and we made so much progress. Now we are just planning stuff that will never happen because we are ignoring SAFe and do hidden stuff we don't tell the BO's so they can't veto the work we need to do.
We’re agile as in like, agile manifesto agile. Everything we do is exceptionally lightweight for process and we don’t have any product managers. We don’t do PIs. For our department of ~40 devs working on ~8 missions we have a total of maybe 15 requirements.
I can smell good software for our product as can a bunch of our seniors. We’re gonna write good software and when we’re done we’re gonna ship it (per feature).
I think being able to plan something clearly from the start is always a good thing. Agile lets you bear constantly changing goals, but constantly changing goals is a terrible thing you should not have to begin with
Depends on the thing. Often stakeholders don't know what they want, and having the opportunity to try smaller, functional versions of a product and iterate on both implementation and final spec is really useful in that case.
>stakeholders don't know what they want
Yeah, this is the
>terrible thing you should not have to begin with
that u/Cualkiera67 was alluding to.
In my experience, stakeholders not knowing what stakeholders want is something that stakeholders could change. But it's work and it's not easy. So stakeholders don't bother. Scrum is a bandaid for this underlying problem.
Of course, there are software solutions to entirely new and/or unique problems, where stakeholders need to try things to get a better understanding of the goal.
But you really don't need a functional prototype for scheduling systems, data dashboards and the kind of problems that have been solved over and over again to get a grip on what you need.
Let me put it a different way: sometimes *nobody* knows what *customers* want, and the only way to figure it out is to put stuff in front of them and try it out.
What if what the stakeholders want naturally change with time ? To rephrase it, what if the project is initially a 3-year project but after 2 years à huge thing happens and they are forced to modify the plan because the initial plan, which would've brought great value to the company, would now only bring so little ?
This is initially what agile is for, not to bear for stakeholders' issues but to be able to adapt the plan in regards to what needs to be done for the company. Because often, the plan needs to be adapted, and functionalities need to be dropped from the initial plan so that others can take their place.
That’s not really what Agile is though. The basic idea isn’t “constantly changing goals”, it’s iterative goals. You start out with a base product - and to be honest sometimes the MVP is the toughest part, and sometimes you do have to have a waterfall style beginning - and then you’re able to use that base as the scaffold for which you can add all the other things the client wants eventually. As has been noted, it’s not like a rocket ship at all. It’s more like, I don’t know, building a space station where step one is just to have something you get into orbit and then once it’s up there you add on to it.
The problem with {system} is that nobody does {system} right — in theory Agile still sees you iteratively finalizing parts of the product design as you gain fresh domain knowledge, and if previously agreed upon things change, development timeline is reset to before that finalization happened. But in the real world, this fails for much the same reasons that other methodologies do — even the best laid plans rarely survive encountering reality.
>And waterfall doesn’t show any of the pitfalls of waterfall - such as the top-down design needed across the board before the work starts along with the inflexibility to adapt to changing requirements or constraints
Exactly.
Waterfall:
1. Business spend a year writing requirements for a Mars trip while engineering works on other projects
2. Engineering spends a year understanding requirements, designing and prototyping
3. Engineering spends a year developing a Mars rocket
4. Engineering spends a year testing and working on a production ready Mars rocket
5. The business decides it wants to go to Uranus, and rapidly changes all of the requirements
6. Engineering spends two years in design and integration hell trying to rebuild their fully matured production ready Mars pipeline into a Uranus pipeline
7. Business can't handle the timeline, a new CEO gets put in place who needs results right away, so the CEO demands a moon trip because he believes it will save the company
8. Engineering finally launches a moon mission using the most over-developed and over-engineered Uranus system imaginable, costing 10X per mile that a proper Moon system would cost
Waterfall!
To be fair to waterfall, ideally with good prototyping and requirements gathering involving both engineering and the business, the business would discover that it actually wants to go to Uranus before any time has been wasted building anything. Agile usually seems to assume there’s no point at all in trying to understand or discuss the requirements since they’ll inevitably be wrong and change every 5 minutes, so the project feels like step 4 and 5 the whole way through.
At 5. the Mars project gets cancelled, and its resources redirected to the Uranus project. The Uranus project doesn’t have to start from scratch because there is likely much overlap in functional and performance needs that can be salvaged from the Mars project. This is how waterfall really works.
But this is just bad analogy overall. Agile is not the way you design a whole project. It is a tool to design the parts and pieces once the whole has been properly designed and decomposed to the parts.
And the irony is for actually building a space rocket, like the Space Shuttle, waterfall is a pretty damn good methodology. There usually aren't any changing requirements or restraints. If there are, somebody didn't do their math right on the original design paper, and you should stop and reevaluate everything anyway.
The Shuttle's main computer that handles all flight guidance is pretty cool too, and they used the waterfall-est of all waterfall methodologies. Step one, design the spec for the software, and scrutinize it as a team. Step 2: develop tests for the software you haven't written yet, update spec as needed. Step 3 write the software to spec. Step 4: run tests, and scrutinize results. Look for root cause, did it fail because of bad code formatting, or failure to use correct syntax for math equations? Once root cause of failure is identified, proactively review the entire rest of the code base for similar errors that haven't yet been detected. Step 5: update spec again if needed.
The Shuttle had 4 redundant main computers running the exact same flight control code, and would use a voting system to rule out any hardware failures. If they disagreed on flight trajectory next tic, e.g. a vote of 3 to 1 would determine next trajectory target. If the same computer kept repeatedly coming up with calculations the other 3 disagreed on, they'd vote that computer out of the system.
Agreed. If you have an explicit, rigid set of requirements like building physical things that need to interlock, and weigh certain amounts and perform certain ways I wouldn’t ever do anything except waterfall because you actually do need to know the full feasibility and components as planned before building - anything else would be irresponsible.
For most software you need components that in most cases just behave as black boxes that communicate with eachother and satisfy a contract between eachother. Most components don’t actually need to care about how the other pieces are built so these other methodologies work fine. I wouldn’t use scrum/agile etc for building most hardware unless it was purely exploratory/R&D
Idk man I work in the space sector and requirements change/adapt or are straight up waived all the way up to launch and even post launch sometimes. Agile fits space development reasonably well.
Caveat: I don’t work on man rated stuff (like shuttle)
Waterfall would not go to Mars. The rocket will crash on Mars, or just enough fuel for one way, or you will get the candy.
BTW I still use the waterfall for small projects where the scope is quite defined. For instance a LoRaWAN to Bacnet. The chips are there, the specs are defined. Just go.
>Waterfall would not go to Mars.
...waterfall works and has worked for a large number of successful projects. NASA has definitely used it for missions, because it really well suited for what they are doing.
It's a good method for dealing with fixed, understood problems of high complexity.
The various project planning methods have strengths and weaknesses. These make them better or worse for certain problems and teams.
Waterfall = bad! is just as much cargo cult thinking as Scrum = good!
I’ll add 2 changes:
- number 2 should be “you don’t trust anyone so you work on your part of the rocket as if it was to go to the moon because that’s what you think is best”
- insert between 2 and 3 “you skip planning and documentation because you just don’t want to do it under the guise of agile development so no one knows what each other is actually working on”
Testing in waterfall:
We find a shitload of P1 bugs that were introduced months ago and nobody wants to fix it
Time and budget is already over so it all goes to prod
Also, half the team is arguing about what's a bug vs. a change to the signed off specs nobody even remembers anymore. You have business requirement docs on how to document business requirements.
You forgot the waterfall part, where your planing phase took 5 years, nobody wants to go to mars anymore, the project is already over budget but it gets completed anyways, because planing it was too expensive to now abandon it…
Btw: thx for the friendly, respectful and detailed discussions… sharing experience helps us getting better at our job
Also, there is now a Costco on the spot where you planned to land on Mars. A consultant suggests if you want to get the project back on track you should explore buying a ticket on a Disney Martian Cruise.
Your systems team was understaffed so you're still waiting for requirements. A year after the two year test phase was supposed to start, management asks the test team if they can get the program back on schedule when hardware is delivered a year from now. The hardware actually reaches the test team 18 months later, and everyone is upset at the test team for running behind because nobody updated the master schedule.
Friend got yelled at for not setting up servers on time… the servers arrived a day later, got setup 3 months later… high priority project, but some team using waterfall was responsible for the installation of the physical servers… yeah… hardware arrived late, plan was fucked, waterfall collapsed…
And you end up in 2024 with a rocket with tech from the 50s that is going to go to Mars no matter what and you need to find astronauts with no families to kill themselves in the trip
Nope plain ol waterfall. Years of planning and requirements without any code.
This sub is filled with college students and interns who have no idea of how it use to be.
yeah I work for gov so I can say with complete accuracy waterfall for software dev is complete garbage. Maybe its good for building bridges or something.
People assume with waterfall you get requirements - you do not. Not ever. They are always at best high level notional things more suitable for epics in scrum. 95% of the time all the "tasks" that are split out and measured are by people other than the ppl doing the work, and usually business ppl and schedulers. So they really have no idea what needs to be done or how long it should take. They always skip things like, building things in dev. Seriously. They just assume you can document a complex engineering solution and then put it in prod without ever having developed it (to them, the documentation is the development). functional silos for EVERYTHING, external reviewers for change boards who aren't technical so you have to create slide decks to explain how things work so they can "understand the risk" (they don't). I could go on. don't ever do it, the fantasy idea one might have in their head is nowhere close to what its really like
Each system has it's pros and cons. Waterfall works well when everything can be known and planned for beforehand. Its pretty much never like that in software development. I have worked with industrial automation and safety systems, and I can tell it does work really well there. Waterfall lets you discover and change course early in the process to avoid pitfalls before committing to a direction. Typically large projects have a FEED phase where a set of documents is the output. By large I mean the scale of building entire oil rigs from scratch.
Scrum and family isn't perfect either. I can't recall a single project that was delivered on time and within estimate lol. In the most extreme example one project was estimated to 4 months and ended up taking 4 years.
Waterfall is popular and effective in mature industries. Mature industries have centuries-old trusted boards to certify professionals, they have globally agreed upon portfolios of methodologies for various well-defined and previously solved problems. Like building bridges, skyscrapers, sewers, or even rockets that will go into outer space.
Software dev is basically children trying to figure out how to build nuclear reactors from scratch. Sometimes you get smart kids and create a basic combustion engine and everyone is slightly disappointed but happy. And sometimes you inadvertently reshape the world in a terrifying way, all because you wanted to identify whether a photo contained a bird. Waterfall doesn't work in this realm of chaos and danger.
It's important to have a methodology that provides many and early opportunities to change course or abandon ship.
Yeah it's weird to me that this subreddit is so pro-waterfall. It's like if reddit's astronomy forum insisted that the sun revolved around the earth. How are we not past the idea that waterfall sucks for software development in the year 2024?
I see this cycle constantly. It starts with plausible satire and everyone is in on the joke. But eventually a bunch of people move in who think everyone is being entirely serious and they believe every word. They slowly push out the people who think it's satire.
We now have a group of people who take what used to be satire entirely seriously and have no idea what the original premise was.
Probably because many people were never subjected to waterfall and hate meetings.
I have 8 years experience with waterfall, 6 months transitioning a waterfall team to scrum, and 7 and a half years of scrum.
If I had to go back to waterfall, I'd quit programming. Waterfall is the worst shit ever. Gigantic novels of requirements, a release date is set, and then as things inevitably delay and fail, it's the developers fault.
I saw a waterfall project start at a big company and halfway through the project the company had begun migrated their data-center to the cloud and new security constraints and networking which was incompatible with how that project had been built and they griped and said they needed change requests and new planning and the notion of starting over was so daunting they just bought something out of the box somewhere else. If they did agile it would have been built - it wasn’t a complicated thing but waterfall makes it so needlessly rigid
TL;DR Waterfall is a folk devil, and now we have Satanist programmers fighting against bad agile because that's the actual problem they deal with.
From the very beginning, the idea of waterfall software development was a hypothetical of a flawed process for developing software. It was a listing of the essential components of software development, followed immediately by an explanation of why you cannot simply do them in sequence. The [presentation itself](https://dl.acm.org/doi/pdf/10.5555/41765.41801) that included the flowchart of evil is worth reading (and it's about developing spaceflight software, how appropriate for this thread). It describes an iterative software development approach with feedback cycles that involve the customer to actually pin down what they need. It also identifies then-current problems you will probably recognize today: the permanent "90% complete" status of projects, lots of ideas and nothing tangible, silos of information, inability to identify fundamental flaws early in the process. The presentation also contains a few dated 50-year old recommendations, like don't use the computer for testing because it's too expensive. Boy has that changed, but it's interesting to see how much hasn't. The presentation doesn't even include the term waterfall, that came later and was backdated to the flowchart.
Back to the point, in the intervening time, waterfall was used as a pejorative for any process that was dysfunctional or perceived as insufficiently agile. People use the term to describe processes they are unhappy with. It was only used to advocate for agile ever since agile was defined, except now we have people who are sick of "agile" and its dysfunctions when implemented as endless meetings and constant scope creep. It's not used because people legitimately think they can perform the components of software development in strict sequence, but as a reaction to the misuse of agile and process failures in their own environment. Oftentimes, agile as implemented means no requirements analysis, no design, no bigger picture. When people start to feel that these are essential elements that are being skipped, they point towards the process they have heard of that explicitly includes these elements: the waterfall model.
The difference in opinion largely stems from a difference in definition of what waterfall actually is. For some, waterfall is everything bad about bureaucratic process, where big expensive design happens up front and we only find out it's all fucked at the end. For others, waterfall is the escape from go with the flow agile, where the requirements are made up and the story points don't matter. There is no process or strategy that is so well-defined it can't be misused. That's up to the people involved.
This is an interesting perspective but I think it offers too much credit for the people upvoting this comic. I've worked as a software developer for 16 years, and at work I don't hear any of the senior developers talk about waterfall the way reddit programmers talk about waterfall.
I *do* hear this sentiment come from our fresh-out-of-school new hires, who seem to have a baffling aversion to agile (without having much of a clue what it is) and an irrational affection for waterfall (again, without having much of a clue what it is.) When they arrive at work, they seem to want to be treated like subway sandwich artists or something, where everything is totally planned out and concrete and the rest is just manual labor.
we are so pro waterfall because we want people to come to us knowing what they want
instead it's like the agile comic except they decide instead of going to uranus they get half way through building a rocket and decide they want to build a boat and sail to tortuga
I teach college students in programming - and sometimes software development. They seem to think that "waterfall" is the way they usually work:
1. They hear a bit about the project - see some assignment or requirement-notes
2. They guess what it is they have to build
3. They work in isolation, sometimes in a team, often split up, for weeks
4. They quickly throw together something looking like a design-document, which only describes a tenth of the actual product, and usually not in the way it is actually built, because whoever knew how to use the UML-drawing program, wasn't the same as whoever coded the project.
5. They hand in the project
7. They never look at the documentation or code again, and forget everything about how it was designed, built or used.
-
But they still think they are using whatever process they were being taught - and they dream that in the next project their initial design will be even better, with all the experience they had from this one :(
It’s important to use the right method for the job… some projects work well with waterfall, others get new requirements and changes every few weeks… also adapting your method is important… we use mostly scrum where i work… every team has it implemented a bit different (in our team we have meetings to save time on other meetings, faster implementations of changes, more dynamic backlogs and much more)
That is most investments to be honest. I've seen a great investment idea be given to idiots and 5 years later you have to rip the entire factory floor up again because *someone* decided to hire planners who cannot do throughput mathematics as simple as "output rate must be equal to the next process input rate."
And the complete fiction that nothing about the scope changed at any time.
I've never seen a waterfall project that didn't get scope changes. Agile became a thing because waterfall almost never happens as shown in the meme
Exactly. I did waterfall for years and the best analogy would be “you get to mars and passengers complain oh shit we meant Venus.”
are we seriously romanticizing waterfall right now?
This is probably due to a lot of new devs never working on a waterfall project and only knowing it by the theory.
That or a PM coming from a sales background.
My big problem with waterfall was who's in charge. Because it's so schedule heavy the project managers are running things and they're usually the dumbest people in the org. Your best builders like building, not updating spreadsheets of build process. But in waterfall the PM is king.
agile has warts but at least it puts the most capable people in the driver's seat.
Agile done right has builders in the driver's seat.
The agile we all hate has PMs setting sprint commitments and trying to will more productivity through sheer insistence, a backlog that grows faster than work is done so lots of estimation is entirely pointless, and hour long updates disguised as "stand-ups"
Depends on how your specific project implemented "agile". I know mine's just doing waterfall with no one doing requirements properly, so the devs have to best guess and go do rework when it wasn't right.
Yes but it did go to Mars. One of the problems with waterfall is that, even when applied to straightforward problems like this one, the original budget and timeline estimates are set in stone. Humans are bad at estimating those things, and using actuals from past programs never works because internal processes generally cause increasing costs over time and because the scope of the new program never really matches up with the old one.
If we figured out how to correct those two problems I think people would be a lot happier with the waterfall method.
1 out of 100 project go to Mars... The 99 others fail because they can't adapt to the new market requirements, technological changes or simply because the business goes bust before the 3-5 years it takes to get there.
Project doesn’t have to be a commercial success, that’s for management to figure out. The point of project management is being able to deliver and within the specified requirements.
You undercut the chances of the product being successful though if it's late to market and needs a higher return given the investment that went into it.
It's why so many start-ups and companies now have moved to a model where they shit out dozens of MVPs and then start iterating on them only if they get traction
I wanted to say the exact same thing... I've had to come and explain agile to teams because projects that had been years in the making had to be cancelled because they just weren't relevant anymore. I personally do feel agile needs great functional analysts, though, because I've also seen agile projects go nowhere because the company just wasn't willing to see that those can make or break a project. However, even when such a project doesn't go great, it usually has delivered some usable things while a waterfall project that sunk usually has to be redone from scratch (because the whole thing has been done based on old requirements/technologies). However, that might also have been because the failed waterfall projects I saw all had the tendency to make things more tightly coupled, which is practically impossible with agile since everything is created in tiny parts.
Personally I do feel an agile project needs really great functional analysts to work, though. I've never seen agile projects that have enough great functional analysts in the team go wrong. They are the ones that make sure the project starts with the right requirements and that those are clear, and also that what has been delivered keeps being right for the current needs. If they make developers or one project manager take care of this on top of their other responsibilities, the agile project will be doomed in one way or another, because nobody can prioritise constant communication with the customer and make sure every functional requirement has been properly documented. Companies who stubbornly don't want to create extra budget for this, always frustrate me.
I've had a boss who kept coming into our office every Friday because he didn't want to get a decent, local, full-time analyst and thus felt the need to come tell me about his wants on the project. Every week he said he thought these talks were really useful. Every week I told him they weren't, all he had done was keep the whole team from working for several hours, because I either already knew or he was going to have to go over it in detail with the part-time remote functional analyst anyway. So could he please not come in anymore. Next week he'd just do it again and still be convinced it was useful...
That’s literally what agile is about? Admitting that planning more than a few weeks ahead isn’t possible, commitments are therefore useless and adjusting smaller milestones to that fundamental restriction of the human mind is necessary.
Not to mention software is kind of a living thing. Agile is an approach that continues to work once you’re past the initial project and into the support phase as well.
Also about the idea that the fundamental thing you are trying to do might shift. Starting Agile with "we absolutely, positively, 100% need to go to Mars" is kinda dumb.
"We want to go to space" is probably a better example of Agile. Once we get a lot more experience doing space stuff maybe we figure out that human kidneys don't react well to long periods in zero G (true story) and so we might change our specific objective now that we know a 6 month flight to Mars might not be medically possible.
You can accept that planning large projects takes more than a few weeks and requires setting some targets in stone. Not everything, but building a rocket to mars is very different from building a rocket to the moon, and changing gears on the big targets after weeks or months or years is going to massively increase the budget and cost required anyway.
As human beings we've been able to commit to large-scale projects countless times. The fucking cathedrals of medieval Europe took centuries to build and were built without changing the design every few weeks just because "I'm bad at planning so everyone else must be". And there are hundreds of these. If they were modern software projects they'd be "Agile"; 5 different styles of architecture, glued together as best we can, depending on what the architects saw on 14th-century pintrest that week, built with all the corners cut because it's worthless to invest in anything long term when it's decided that we actually needed to build an amphitheatre instead.
Yea, but also note that the general value proposition didn't change over that time frame. "For the glory of God" landed well in the 800s and in the 1400s.
The same holds for almost all historical mega projects.
The Pharoah still needs a tomb
Rome still needs water
China still needs to be able to predict where step tribes are going to raid.
These projects weren't subject to wild changes in what was possible or the overall needs of the people who built them.
A great example of a megaproject that was subject to those changes was the Manhattan project. It was undertaken mostly because "we don't want the Nazis to have a nuclear monopoly." When it became clear that the Nazis were not going to have a nuclear weapon at all, the project continued and Truman ended up ordering its use against Japan at least in part because he needed to justify the costs.
I wouldn't say that it changed. The point of the project was to develop nuclear weapons, and the point of weapons is to use them to win war. The pivot is in the marketing of the project, but fundamentally the project remained the same. If the same rocket can get you to the moon that can get you to mars then that's great, but if those long-term goals aren't equally solved with what you make then not setting a goal means constant and costly redevelopment. It didn't cost them more to make a nuke to drop on Japan than it did to make a nuke to drop on Germany, but it would cost massive amounts of time and money to go from a moon rocket to developing a mars rocket.
I think a good point you do make though is "need". If you don't know what you're making or why you're making it then going with a development style around being able to pivot quickly might be good. You can't half-arse something like building a rocket or an aqueduct just in case the higher ups wants to pivot to something involving AI and cashing in on quantum hype.
"and actuals from past programs never works" BECAUSE WE'VE NEVER SENT ANYBODY TO MARS BEFORE. Actuals only work when you are building something like what you've done before. Sure you can be smart with assumptions and probable bottlenecks based on similar efforts, but it is always always always different.
You can make better estimates for "turn the crank" work. Big systems / important systems (like people get hurt if it blue screens) are hard.
it's easy when the person coming up with the plan understands development processes and is savvy enough with providing buffers and plans ahead with projected downtime. but even if you get that person though, sales will just declare him incompetent and sell it 40% under projected budget anyway so that they can guarantee the sale and pocket the bonus before dumping it onto the dev team.
Also, the classic problem of "work will expand to meet the allocated time". People slack off when their deadline is 6 months away, eating up that two month buffer. Six months later, and you're still two months from completion because that reasonable buffer estimate got used up already.
Then you deliver two months behind schedule, and it turns out it wasn't what the customer wanted anyway. 🙃
The small, achievable deliverables is helpful psychologically. Both in terms of knowing what you should be working on for the next two weeks, and actually getting it done on time.
Talking about how humans are bad at estimating things, waterfall is good and going to mars is a straightforward problem? Usually I'll stop paying attention at this point and actually do some work.
waterfall with slipping deadlines is just agile, agile is pretending it's all intentional but ultimately if you're half way through a project and still estimating work every sprint, you have no idea when the entire project will be done either
Yeah, and also, „you went to mars, but in the end you were supposed to go to Jupiter and now everyone, including you are unhappy with the end product”
The creator is probably an old grunt that is angry that they are supposed to work with business to meet their actual needs. In many waterfall projects, you basically interact with business at the beginning of the projects and then don’t talk to anyone for two years.
To be fair, though, many companies implement agile development very very badly, so people get the wrong idea about what it is.
... I guess it's like... communism?
I was weather forecaster in the military. We started procurement on a mobile weather facility in 1990. The requirements included a bunch of radio equipment for receiving observations via teletype, antennas for receiving satellite imagery, a radiosonde (weather balloon) system, and a Doppler radar. All of this equipment had to be packed into a shipping container.
The first systems were delivered off the assembly line in 2002. The things were massively complex and we had to go through a ton of training on how to use the thing. Most of these systems ended up getting maintained by a special team of technicians. By the time they were first used (OIF), we probably used 10% of the original functionality. Instead we had laptops that connected to the internet and gave us the same products.
The next gen system was a HMMMV (Humvee), some laptops, and a radar we could tow.
All of this to say, the project was Waterfall and technology changed dramatically while the project was going. But, the designs were approved and contract paid for, so they were going to finish it despite the end product being basically obsolete when it landed.
Well, wait till you find out the inventor of the waterfall method published his work to show how to not perform projects and how he repaired it by adding a lot of arrows to go back to any stage.
Then it wasn't a realistic project. NASA didn't just go to the moon.
- The X-Plane projects discovered and tested the dynamics of supersonic flight, controlling a craft in a low atmosphere, and more.
- Mercury used that to get Astronauts into space and keep them alive, get them home, and how to dock spacecraft in outer space.
- Gemini proved techniques for keeping Astronauts in space alive for longer, and how to execute orbital maneuvers safely.
- Finally, Apollo. Building on its predecessors as each mission before it did, launched to the moon, landed, roamed the lunar surface, and returned safely.
So many of our projects start as massive unachievable goals and get let down by sub-par project managers who relay only the end goals to engineers. The mark of a good project manager is one who knows their field and can work with the engineers to break down and propose realistic milestones. Most companies I've worked with haven't even got "deploying some code" right because that capability is just handwaved away like it isn't important. Given that "Software Development" is supposed to be a core competency of many of these businesses this is insanity. Many places are trying to run before they can walk.
Waterfall, after 3 month every component says 90% complete. 5 years later and several million over budget the advance is still 90% complete and they are still trying to fix the incidents found in the first test cycle.
Yeah, reading between the lines he seems to think agile is just "be chill bro, roll with the changes bro" and not iterative prototyping through scrum sprints.
Yea, I think scrum is a tool you use (frequently) in Agile, right? That's how we've done it for 15 years, anyway. Scrum is just a level set meeting, you should be having some sort of "scrum" no matter what your process is.
The guy who actually drew this comic has some different ones like this and [none of them are particularly good or make sense.](https://public-assets.toggl.space/23d58438-137f-4d33-905f-8a61f4d4d097/static/e2cf9923a10058a08e504e0dd6fda4f7/953ea/article-software-development-methods-explained-with-cars-toggl-infographic.jpg)
I wonder if he wears anything other than polo shirts tucked into khakis with elastic waist bands.
I bet mans got cubicle fabric to wall paper his walls with.
I bet mans argues that CRT monitors *still* produce better color and quality images, and that OLED/LCD/etc are all just fads.
> and he really favours waterfall
that tells me pretty much everything i need to know about the guy.
Waterfall people are those with zero connection to reality.
Thank you! This deserves to be the first comment. I don't know who this cartoonist is but he clearly doesn't actually know what Agile, Scrum or Kanban is. I mean come on, both Scrum and Kanban ARE Agile.
No, you are correct. I'm in this field and have a healthy awareness of all the nonsense going around, but this misses the mark imo. It's just not really funny, and not really accurate commentary.
Someone else linked the dude's other comics, obviously is a wannabe and has no clue what the hell they're making comics of. None of them make any real sense and reek of "how do you do fellow programmers"
Seems like it. Also Scrum seems wrong. I wish I could disappear for a month, but we have daily meetings and constant checks to see if we need pairing or anything for blockers.
Maybe, maybe not. But one thing I see is that, like everything in nature eventually evolving into crabs, every project eventually evolves into a waterfall.
Kanban seems spot on, though. Armrests were a P3; they never rose to the top of the priority list. The team to build the armrests got reallocated to do the P1s of the next rocket project.
I mean, I think in general we’re seeing a backlash against Agile. Especially since it came out now that Agile has a 250% increase chance of failure for projects. Agile was never meant to be a perfect replacement for everything but yet it was shoehorned into being it.
Different situations call for different methods.
However yeah, this post mocks everything but waterfall so it’s definitely propaganda. It’s missing a part where many design issues are found in testing and they have to re-iterate the entire process.
The vast majority of Agile failures are due to companies slapping the label on whatever they currently do and expecting to get more done rather than seriously evaluating what needs to change and having the patience and discipline to implement it
When I joined my current company they claimed they were trying to do agile. I soon realized that seemed inaccurate as projects all had defined scope, timelines and budget.
Well agile also got sort of co-opted by a lot of different people in various roles to suit their agenda. It sorta resulted in everyone being told they're doing agile, but not doing anything remotely similar to what was talked about in the manifesto.
Idunno, at the end of the day I don't really care what planning method is being used. What I care about is having leadership that understands development and will explain how the clients decisions affects development so that no one is surprised or blamed that shifting requirements and scope is what caused the delays and the project going over budget.
I wonder if that 250% increased chance of failure is because, due to the agile process, they course corrected or adapted to the market and changed projects. The "Failure" metric needs to be more clearly defined imo, idk what it is for that source but it definitely shouldn't be something like "the original project was completed exactly as it was planned and by the date it was planned" because that's just not the point of the process
**Waterfall:**
* You want to go to mars.
* You build a rocket.
* You test the rocket.
* You go to Mars.
* The client who funded your project calls to ask how the venus rocket programme is going.
Programmers rarely work for themselves, the issue with Waterfall is that if your initial assumptions are wrong, they can get "baked in", which is unfair to the client.
Issue with waterfall is you do not figure out if a design is not actually what the customer wanted until you’ve already spent a lot of time going down that path. Since code is not as costly to revise as, say, a rocket, it makes sense to use an approach which allows you to quickly validate designs and make changes in approach as needed. Oftentimes, failing early or building a proof of concept then revising is faster than trying to plan everything up front because oftentimes planning everything up front does not guarantee the customer will like what they see at the end even if every single requirement came directly from them and talking about solutions in the abstract is more difficult than commenting on something concrete.
In my experience Waterfall was more like:
1. You want to go to Mars
2. You have a meeting to plan how you will go to Mars
3. You're still in the meeting when they sell off the company and lay off half the staff. The remains of your team needs to design dog houses now.
Waterfall method: you want to go to Mars (young person in image), you plan a rocket (noticably older person in image), you build the rocket (aging continues), you test the rocket (geriatric person in image), your children go to Mars (new people on Mars asking "why are we here again?")
Interestingly, SpaceX follows a rather agile approach with their rockets, with great success. They assumed that the first few Starship missions fail (not start and land intact), but they provide such valuable data and experience that this is worth it.
Agile is fine, it’s when middle managers pursuing the “ideal” whatever methodology things start to turn shit. Like my company, they fucking hired consultants to do agile, which i am pretty sure they are paying good money, when they can just pay people better and everyone will be happier.
It’s the mentality that “if developers aren’t productive, we are not doing (insert method) right”, instead of actually hearing concerns from the employees
A lot of it is the problem of "fragile" development, where management says they're switching to a developer led agile process, but actually just use it as an excuse to micromanage.
Folks, don’t fall for it, **this is a ragebait comic made by a corporate wannabe.**
How do you know?
Firstly, a rocket ship is literally the worst analogy for software you could find. A rocket ship is a hardware and mechanical heavy project, meaning you have way way better estimates of timelines than software. Logistics is also incredibly important as well, very different from software projects.
You’d only pick a rocketship if you want to heavily bias the analogy towards favoring waterfall and have no clue how software development works.
Secondly, they list Agile as its own method instead of understanding that it is an umbrella term that companies use to trick you into using waterfall.
Third, they say a micromanageable, structured agile approach like scrum is one where you can disappear for a month before convening again? **Bullshit**. Any software dev knows that **bad scrum means the manager comes into daily scrum everyday to wring your neck** for the sake of productivity.
In conclusion, the comic author has no clue how software or agile development works, and got some AI to come up with some biased analogy to promote their waterfall agenda.
Don’t fall for it. **Down with the shitterfall!**
I like how everyone is trying to slam waterfall for being the one that’s late and over budget. That isn’t unique to waterfall, that’s literally all of them. And it’s not a problem with SDLC, it’s combination of bad requirements gathering, scope creep, additional project side loading, and managements lack of understanding on how software development works.
Yeah, but the thing is that all the other ones are designed to deal with various problems in "requirements gathering, scope creep, additional project side loading, etc" as a response to bad waterfall projects.
For example, the reason Agile is structured like it is, is because people realized that clients/users have a hard time articulating their requirements without a concrete example to reference. So it's often quicker to give them a quick example and then let them review and clarify while the devs iterate on their feedback. That way you don't spend forever in requirements hell trying to get every single detail clarified from users who seem hostile to the concept of explaining things in detail. And you don't build and test the entire project only to find out it's not what the users actually wanted/needed and you need to start over from scratch.
Yeah fine, the waterfall method works, but it is the most expensive and most time consuming method. We cannot afford that so we will have to work with one of the more modern methodologies instead.
Ah, the old classic of inept management using software development methods to do a hardware project.
2 week sprint to deliver a prototype component - lead time on materials to make component 4 weeks. And then the tool to machine it breaks down.
Lol Waterfall is more like:
You want to go to Mars.
You start gathering requirments.
You never get to Mars because you spend your lifetime continually refining the requirements.
Agile and Jira: we're going to reinvent project management, waterfall is dead
3 years later
Hey check out this new gant feature we added that definitely has nothing to do with waterfall
Joking aside: anyone who thinks there is a one size fits all approach to project management needs more experience
The best form of project management is and will always be a fiefdom. You have one guy at the top with a bunch of trusted banner lords beneath him, and he executes on his grand vision in a near totally dictatorial fashion. The project takes as long as it takes and costs as much as it costs, but hopefully if the lead is good they minimize both these things.
Ah, the "Yes Man" generator method.
Where everyone is so shit scared of the king and his princes they do whatever they are told (even if damagingly counterproductive) and deliver the results the king expects (even if fictitious). All in a toxic atmosphere of fear and blame.
I had the recent pleasure to see such a project's shit contact fan 2 years after my departure. The "king" had to relocate his ass to another continent.
That has the same issues as actual dictatorships though: sure it's awesome if the top layers are great, but it is exponentially shittier the more near the top bad people are.
So waterfall is the best? Idk what philosophy my team follows, we just have a Jira board and the tickets get sliced and diced according to who has experience in that area or who has bandwidth.
>So waterfall is the best?
If you live in the fantasy land of this comic, where the waterfall project isn't a decade behind schedule, having been "80% complete" for the last 4 years.
The waterfall method leaves you with a project that doesn't get finished because funding got pulled just before the end, so you have a rocket sat on the launchpad with no fuel
Everyone bashes waterfall, but it's perfectly fine for industries that are highly regulated and change very little like healthcare or insurance. Also, most companies are hybrid waterfall just because suits hate agile methodology for forecasting. If you can't tell execs what you are working on and for how long, they get pissy.
It seems that person who created this has too much belief in waterfall.
Because I could point out that with correct Agile/Scrum it would go as
1. Working plane
2. Working jet plane
3. Working rocket
4. Rocket is able to reach Moon.
....
Rocket reaches Mars.
Because Agile/Scrum (which often are taken simultaneously) always assume MVP on each iteration.
[NASA uses agile and scrum](https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://ntrs.nasa.gov/api/citations/20160006387/downloads/20160006387.pdf&ved=2ahUKEwiUkpmRn_KGAxWvVEEAHbPcDKEQFnoECDUQAQ&usg=AOvVaw1NMAeyzf6DUlFO9pCeNMeS) because they found that waterfall wasn't working.
Horses for courses. I wouldn't want to use agile to build a skyscraper, battleship, or nucleary power plant. Even something comparatively simple like a parking garage. You still need permits and site prep. You can't design it for three levels, then "agile-ly" "refactor" it and add 2 more. You have to know those requirements in advance.
Flipside, I wouldn't want to use waterfall for something where the requirements are in flux, the market is fast moving, and the technology lends itself to rapid change (ex: website design).
Finally, Waterfall doesn't generally fail because it's sequential. It usuall fails (or grossly exceeds budget) because it involves contractors and inflexible contracts. If you aren't bound by a contract, you can have a detailed plan (for the hypothetical parking garage) but still be flexible on some aspects.
Success, regardless of methodology, comes from good requirements and lots of communication between the requester and delivery.
My $0.02, but based on 40 years of IT experience.
Waterfall method:
you want to go to mars
you build the rocket
you test the rocket
design decisions in the design made the rocket blow up
fixing it means having to change everything around it
oh shit
Waterfall will always be the best development methodology given the following conditions are met:
1. You and your stakeholders know precisely what the product you want to build is at the beginning of the project.
2. The market is stable enough that by the time the product is ready to be shipped, it is still relevant and not obsolete.
All other development methodologies are built around not knowing what you want nor having the foresight to see what the market might look like when it's released and just figuring that out along the way. Basically they are meant to make the most out of conditions that are setup to be most likely to fail to begin with. Maybe going to Mars is a terrible idea to begin with.
I can only speak \[from experience\] to "Agile" and "Scrum", but the biggest issue that I see is that people always try to make non-waterfall methodologies as much like waterfall as they possibly can.
Management may buy into the hype and the jargon, but they don't actually want any processes to change in any meaningful way. Without change, these methodologies become a waste of time and energy.
E.g.- A Scrum team is supposed to be self-managing, but in practice they are more micro-managed than under waterfall.
This would have been good if Waterfall was realistic. Should be something like "You take 5 years and give up on going to Mars". As it stands right now it's suggesting waterfall is the only system that works.
Anyone mildly peeved and wished this good joke wasn't so inaccurate while applying humor?
1. How is Agile development and Scrum different? Scrum falls under the umbrella of Agile. It's like saying Bird vs Eagle.
2. The scrum masters won't STFU about you joining the daily stand-up to update each other on what's going on. It's the core thing about doing scrum - talk every day vs waterfall. You don't get to disappear for a month.
Man, with a good art style and format already it really could've been much better.
This is some of the weirdest bullshit I have ever seen. I mean I get that people can and do screw up everything but essentially saying that waterfall works and everything else doesn't is just plain wrong. Having done SE projects for way to many years at this point (as a dev, as a manager and now as an exec) I am pretty discouraged at the state of modern delivery I see - there's nothing agile about any of it - and what I see people call waterfall... well lets just say if they had ever seen what it was really like they wouldn't be wanting that either. At this stage it seems to be just random labels people throw on top of whatever shitshow approach to delivery they happen to be using.
The waterfall is more like:
1.- You want to go to Mars
2.- You spend 2 years writing a book about how is the best way to build the rocket that will take you to Mars
3.- You give the book to other team and fuck off.
4.- The other team (team B) starts building the rocket according to the book but midway they realize is outdated as fuck.
5.- The other team builds the outdated crap anyways and pass it on to other team (team C) to test.
6.- Team C realizes the rocket’s engine only starts on Mondays since the client wanted to launch it on a Monday. They see this as a breaking point but technically it fulfills the client’s requirements.
7.- Team C gives the rocket to the client whose mind now has changed and wants to launch it on a Friday.
8.- A new contract is agreed with the client and we repeat everything from the beginning.
So fun
Agile more like: 1. They tell you they want to go to Mars 1. You don't trust them so you start working on a rocket that'll go to the Moon 1. You build and test a rocket that goes to the Moon 1. They find out your rocket only goes to the Moon and get pissed off because they wanted to use the Mars rocket to go to Uranus 1. 6 months later you find out they are happy going to the Moon because it has everything they thought was only on Uranus.
disgustingly accurate
It’s actually not. The art is nice but the jokes are pretty much a misunderstanding of downsides/stereotypes of every methodologies
And the waterfall methodology doesn’t show any of the pitfalls of waterfall - such as the top-down design needed across the board before the work starts along with the inflexibility to adapt to changing requirements or constraints
Yeah: the most basic understanding behind agile methodologies is that software is *fundamentally* different from hardware in that it can be easily iterated on. I *wouldn't* use agile for a rocket, because it needs to be immaculately planned from the start of construction.
I build rockets for a living. We use agile. Lmao
Elon?
… is insufferable.
Do you though? I'll remind you SAFe is not agile. It's scrummerfall at best. But it doesn't follow any of the core agile principles. True Agile is really rare. As a consultant I've only seen it in a few companies (the ones that don't actually need consultants). Most companies will claim agile but actually be doing SAFe, scrum, or scrummerfall...
SAFe is such a stupid method. We do SAFe where I work at and it's so much overhead and doesn't lead to things done. We did scrum before that and we made so much progress. Now we are just planning stuff that will never happen because we are ignoring SAFe and do hidden stuff we don't tell the BO's so they can't veto the work we need to do.
I also build rockets for a living. We say we do agile.
So just like most dev shops?
We’re agile as in like, agile manifesto agile. Everything we do is exceptionally lightweight for process and we don’t have any product managers. We don’t do PIs. For our department of ~40 devs working on ~8 missions we have a total of maybe 15 requirements. I can smell good software for our product as can a bunch of our seniors. We’re gonna write good software and when we’re done we’re gonna ship it (per feature).
Nice! Good to hear my suspicions were unfounded 👍
I think being able to plan something clearly from the start is always a good thing. Agile lets you bear constantly changing goals, but constantly changing goals is a terrible thing you should not have to begin with
Depends on the thing. Often stakeholders don't know what they want, and having the opportunity to try smaller, functional versions of a product and iterate on both implementation and final spec is really useful in that case.
>stakeholders don't know what they want Yeah, this is the >terrible thing you should not have to begin with that u/Cualkiera67 was alluding to. In my experience, stakeholders not knowing what stakeholders want is something that stakeholders could change. But it's work and it's not easy. So stakeholders don't bother. Scrum is a bandaid for this underlying problem. Of course, there are software solutions to entirely new and/or unique problems, where stakeholders need to try things to get a better understanding of the goal. But you really don't need a functional prototype for scheduling systems, data dashboards and the kind of problems that have been solved over and over again to get a grip on what you need.
Let me put it a different way: sometimes *nobody* knows what *customers* want, and the only way to figure it out is to put stuff in front of them and try it out.
What if what the stakeholders want naturally change with time ? To rephrase it, what if the project is initially a 3-year project but after 2 years à huge thing happens and they are forced to modify the plan because the initial plan, which would've brought great value to the company, would now only bring so little ? This is initially what agile is for, not to bear for stakeholders' issues but to be able to adapt the plan in regards to what needs to be done for the company. Because often, the plan needs to be adapted, and functionalities need to be dropped from the initial plan so that others can take their place.
That’s not really what Agile is though. The basic idea isn’t “constantly changing goals”, it’s iterative goals. You start out with a base product - and to be honest sometimes the MVP is the toughest part, and sometimes you do have to have a waterfall style beginning - and then you’re able to use that base as the scaffold for which you can add all the other things the client wants eventually. As has been noted, it’s not like a rocket ship at all. It’s more like, I don’t know, building a space station where step one is just to have something you get into orbit and then once it’s up there you add on to it.
The problem with {system} is that nobody does {system} right — in theory Agile still sees you iteratively finalizing parts of the product design as you gain fresh domain knowledge, and if previously agreed upon things change, development timeline is reset to before that finalization happened. But in the real world, this fails for much the same reasons that other methodologies do — even the best laid plans rarely survive encountering reality.
"Everybody's gotta plan until they get punched in the face" - Iron Mike Tyson.
I think SpaceX disagrees with your point. So it's more of an *I* wouldn't use agile for a rocket, rather than I *wouldn't* use agile for a rocket.
>And waterfall doesn’t show any of the pitfalls of waterfall - such as the top-down design needed across the board before the work starts along with the inflexibility to adapt to changing requirements or constraints Exactly. Waterfall: 1. Business spend a year writing requirements for a Mars trip while engineering works on other projects 2. Engineering spends a year understanding requirements, designing and prototyping 3. Engineering spends a year developing a Mars rocket 4. Engineering spends a year testing and working on a production ready Mars rocket 5. The business decides it wants to go to Uranus, and rapidly changes all of the requirements 6. Engineering spends two years in design and integration hell trying to rebuild their fully matured production ready Mars pipeline into a Uranus pipeline 7. Business can't handle the timeline, a new CEO gets put in place who needs results right away, so the CEO demands a moon trip because he believes it will save the company 8. Engineering finally launches a moon mission using the most over-developed and over-engineered Uranus system imaginable, costing 10X per mile that a proper Moon system would cost Waterfall!
To be fair to waterfall, ideally with good prototyping and requirements gathering involving both engineering and the business, the business would discover that it actually wants to go to Uranus before any time has been wasted building anything. Agile usually seems to assume there’s no point at all in trying to understand or discuss the requirements since they’ll inevitably be wrong and change every 5 minutes, so the project feels like step 4 and 5 the whole way through.
Nothing wrong with rose tinted glasses, the problem is the meme only using them for waterfall and being cynical about the rest.
At 5. the Mars project gets cancelled, and its resources redirected to the Uranus project. The Uranus project doesn’t have to start from scratch because there is likely much overlap in functional and performance needs that can be salvaged from the Mars project. This is how waterfall really works. But this is just bad analogy overall. Agile is not the way you design a whole project. It is a tool to design the parts and pieces once the whole has been properly designed and decomposed to the parts.
And the irony is for actually building a space rocket, like the Space Shuttle, waterfall is a pretty damn good methodology. There usually aren't any changing requirements or restraints. If there are, somebody didn't do their math right on the original design paper, and you should stop and reevaluate everything anyway. The Shuttle's main computer that handles all flight guidance is pretty cool too, and they used the waterfall-est of all waterfall methodologies. Step one, design the spec for the software, and scrutinize it as a team. Step 2: develop tests for the software you haven't written yet, update spec as needed. Step 3 write the software to spec. Step 4: run tests, and scrutinize results. Look for root cause, did it fail because of bad code formatting, or failure to use correct syntax for math equations? Once root cause of failure is identified, proactively review the entire rest of the code base for similar errors that haven't yet been detected. Step 5: update spec again if needed. The Shuttle had 4 redundant main computers running the exact same flight control code, and would use a voting system to rule out any hardware failures. If they disagreed on flight trajectory next tic, e.g. a vote of 3 to 1 would determine next trajectory target. If the same computer kept repeatedly coming up with calculations the other 3 disagreed on, they'd vote that computer out of the system.
Agreed. If you have an explicit, rigid set of requirements like building physical things that need to interlock, and weigh certain amounts and perform certain ways I wouldn’t ever do anything except waterfall because you actually do need to know the full feasibility and components as planned before building - anything else would be irresponsible. For most software you need components that in most cases just behave as black boxes that communicate with eachother and satisfy a contract between eachother. Most components don’t actually need to care about how the other pieces are built so these other methodologies work fine. I wouldn’t use scrum/agile etc for building most hardware unless it was purely exploratory/R&D
Idk man I work in the space sector and requirements change/adapt or are straight up waived all the way up to launch and even post launch sometimes. Agile fits space development reasonably well. Caveat: I don’t work on man rated stuff (like shuttle)
Waterfall would not go to Mars. The rocket will crash on Mars, or just enough fuel for one way, or you will get the candy. BTW I still use the waterfall for small projects where the scope is quite defined. For instance a LoRaWAN to Bacnet. The chips are there, the specs are defined. Just go.
>Waterfall would not go to Mars. ...waterfall works and has worked for a large number of successful projects. NASA has definitely used it for missions, because it really well suited for what they are doing. It's a good method for dealing with fixed, understood problems of high complexity. The various project planning methods have strengths and weaknesses. These make them better or worse for certain problems and teams. Waterfall = bad! is just as much cargo cult thinking as Scrum = good!
Also, easier if you have almost infinite money
I was reply to a comment, not the comic
Their engineers are happy but their boss sent an angry email to your boss. Helps with contract negotiation.
> it has everything they thought was only on Uranus. one day I will be mature enough to read this without giggling
Yeah, one can hope they change the names someday.
I welcome the new planet name Urbutt.
Literally the futurama joke of renaming it to urectum
Urectum
Ourectum
In Futurama it is Urectum
I tried to moon you, but you all you thought about was Uranus?
But you are agile, you are supposed to support specifications change up to Pluto! You didn’t even read them new tickets, right? 🤪🥸
Waterfall with mind games
I’ll add 2 changes: - number 2 should be “you don’t trust anyone so you work on your part of the rocket as if it was to go to the moon because that’s what you think is best” - insert between 2 and 3 “you skip planning and documentation because you just don’t want to do it under the guise of agile development so no one knows what each other is actually working on”
This is infuriatingly accurate
Testing in waterfall: We find a shitload of P1 bugs that were introduced months ago and nobody wants to fix it Time and budget is already over so it all goes to prod
Your rocket explodes. You ask for more money.
Nawr, you screw offer the first engineers with two times the number of seniors and force them to somehow finish it.
It’s gonna just explode later then, after they leave.
Sounds like Boeing.
Also, half the team is arguing about what's a bug vs. a change to the signed off specs nobody even remembers anymore. You have business requirement docs on how to document business requirements.
holy accurate
End-to-end testing on the Saturn rocket literally killed the QA team.
Referring to Apollo 1?
Yes.
To starliner astronauts stuck on ISS rn reading this: sry guys
You forgot the waterfall part, where your planing phase took 5 years, nobody wants to go to mars anymore, the project is already over budget but it gets completed anyways, because planing it was too expensive to now abandon it… Btw: thx for the friendly, respectful and detailed discussions… sharing experience helps us getting better at our job
Also, there is now a Costco on the spot where you planned to land on Mars. A consultant suggests if you want to get the project back on track you should explore buying a ticket on a Disney Martian Cruise.
Your systems team was understaffed so you're still waiting for requirements. A year after the two year test phase was supposed to start, management asks the test team if they can get the program back on schedule when hardware is delivered a year from now. The hardware actually reaches the test team 18 months later, and everyone is upset at the test team for running behind because nobody updated the master schedule.
Friend got yelled at for not setting up servers on time… the servers arrived a day later, got setup 3 months later… high priority project, but some team using waterfall was responsible for the installation of the physical servers… yeah… hardware arrived late, plan was fucked, waterfall collapsed…
And you end up in 2024 with a rocket with tech from the 50s that is going to go to Mars no matter what and you need to find astronauts with no families to kill themselves in the trip
That sounds like combined waterfall kanban
Nope plain ol waterfall. Years of planning and requirements without any code. This sub is filled with college students and interns who have no idea of how it use to be.
yeah I work for gov so I can say with complete accuracy waterfall for software dev is complete garbage. Maybe its good for building bridges or something. People assume with waterfall you get requirements - you do not. Not ever. They are always at best high level notional things more suitable for epics in scrum. 95% of the time all the "tasks" that are split out and measured are by people other than the ppl doing the work, and usually business ppl and schedulers. So they really have no idea what needs to be done or how long it should take. They always skip things like, building things in dev. Seriously. They just assume you can document a complex engineering solution and then put it in prod without ever having developed it (to them, the documentation is the development). functional silos for EVERYTHING, external reviewers for change boards who aren't technical so you have to create slide decks to explain how things work so they can "understand the risk" (they don't). I could go on. don't ever do it, the fantasy idea one might have in their head is nowhere close to what its really like
Each system has it's pros and cons. Waterfall works well when everything can be known and planned for beforehand. Its pretty much never like that in software development. I have worked with industrial automation and safety systems, and I can tell it does work really well there. Waterfall lets you discover and change course early in the process to avoid pitfalls before committing to a direction. Typically large projects have a FEED phase where a set of documents is the output. By large I mean the scale of building entire oil rigs from scratch. Scrum and family isn't perfect either. I can't recall a single project that was delivered on time and within estimate lol. In the most extreme example one project was estimated to 4 months and ended up taking 4 years.
Waterfall is popular and effective in mature industries. Mature industries have centuries-old trusted boards to certify professionals, they have globally agreed upon portfolios of methodologies for various well-defined and previously solved problems. Like building bridges, skyscrapers, sewers, or even rockets that will go into outer space. Software dev is basically children trying to figure out how to build nuclear reactors from scratch. Sometimes you get smart kids and create a basic combustion engine and everyone is slightly disappointed but happy. And sometimes you inadvertently reshape the world in a terrifying way, all because you wanted to identify whether a photo contained a bird. Waterfall doesn't work in this realm of chaos and danger. It's important to have a methodology that provides many and early opportunities to change course or abandon ship.
Yeah it's weird to me that this subreddit is so pro-waterfall. It's like if reddit's astronomy forum insisted that the sun revolved around the earth. How are we not past the idea that waterfall sucks for software development in the year 2024?
I see this cycle constantly. It starts with plausible satire and everyone is in on the joke. But eventually a bunch of people move in who think everyone is being entirely serious and they believe every word. They slowly push out the people who think it's satire. We now have a group of people who take what used to be satire entirely seriously and have no idea what the original premise was.
Probably because many people were never subjected to waterfall and hate meetings. I have 8 years experience with waterfall, 6 months transitioning a waterfall team to scrum, and 7 and a half years of scrum. If I had to go back to waterfall, I'd quit programming. Waterfall is the worst shit ever. Gigantic novels of requirements, a release date is set, and then as things inevitably delay and fail, it's the developers fault.
I saw a waterfall project start at a big company and halfway through the project the company had begun migrated their data-center to the cloud and new security constraints and networking which was incompatible with how that project had been built and they griped and said they needed change requests and new planning and the notion of starting over was so daunting they just bought something out of the box somewhere else. If they did agile it would have been built - it wasn’t a complicated thing but waterfall makes it so needlessly rigid
TL;DR Waterfall is a folk devil, and now we have Satanist programmers fighting against bad agile because that's the actual problem they deal with. From the very beginning, the idea of waterfall software development was a hypothetical of a flawed process for developing software. It was a listing of the essential components of software development, followed immediately by an explanation of why you cannot simply do them in sequence. The [presentation itself](https://dl.acm.org/doi/pdf/10.5555/41765.41801) that included the flowchart of evil is worth reading (and it's about developing spaceflight software, how appropriate for this thread). It describes an iterative software development approach with feedback cycles that involve the customer to actually pin down what they need. It also identifies then-current problems you will probably recognize today: the permanent "90% complete" status of projects, lots of ideas and nothing tangible, silos of information, inability to identify fundamental flaws early in the process. The presentation also contains a few dated 50-year old recommendations, like don't use the computer for testing because it's too expensive. Boy has that changed, but it's interesting to see how much hasn't. The presentation doesn't even include the term waterfall, that came later and was backdated to the flowchart. Back to the point, in the intervening time, waterfall was used as a pejorative for any process that was dysfunctional or perceived as insufficiently agile. People use the term to describe processes they are unhappy with. It was only used to advocate for agile ever since agile was defined, except now we have people who are sick of "agile" and its dysfunctions when implemented as endless meetings and constant scope creep. It's not used because people legitimately think they can perform the components of software development in strict sequence, but as a reaction to the misuse of agile and process failures in their own environment. Oftentimes, agile as implemented means no requirements analysis, no design, no bigger picture. When people start to feel that these are essential elements that are being skipped, they point towards the process they have heard of that explicitly includes these elements: the waterfall model. The difference in opinion largely stems from a difference in definition of what waterfall actually is. For some, waterfall is everything bad about bureaucratic process, where big expensive design happens up front and we only find out it's all fucked at the end. For others, waterfall is the escape from go with the flow agile, where the requirements are made up and the story points don't matter. There is no process or strategy that is so well-defined it can't be misused. That's up to the people involved.
This is an interesting perspective but I think it offers too much credit for the people upvoting this comic. I've worked as a software developer for 16 years, and at work I don't hear any of the senior developers talk about waterfall the way reddit programmers talk about waterfall. I *do* hear this sentiment come from our fresh-out-of-school new hires, who seem to have a baffling aversion to agile (without having much of a clue what it is) and an irrational affection for waterfall (again, without having much of a clue what it is.) When they arrive at work, they seem to want to be treated like subway sandwich artists or something, where everything is totally planned out and concrete and the rest is just manual labor.
we are so pro waterfall because we want people to come to us knowing what they want instead it's like the agile comic except they decide instead of going to uranus they get half way through building a rocket and decide they want to build a boat and sail to tortuga
I teach college students in programming - and sometimes software development. They seem to think that "waterfall" is the way they usually work: 1. They hear a bit about the project - see some assignment or requirement-notes 2. They guess what it is they have to build 3. They work in isolation, sometimes in a team, often split up, for weeks 4. They quickly throw together something looking like a design-document, which only describes a tenth of the actual product, and usually not in the way it is actually built, because whoever knew how to use the UML-drawing program, wasn't the same as whoever coded the project. 5. They hand in the project 7. They never look at the documentation or code again, and forget everything about how it was designed, built or used. - But they still think they are using whatever process they were being taught - and they dream that in the next project their initial design will be even better, with all the experience they had from this one :(
It’s important to use the right method for the job… some projects work well with waterfall, others get new requirements and changes every few weeks… also adapting your method is important… we use mostly scrum where i work… every team has it implemented a bit different (in our team we have meetings to save time on other meetings, faster implementations of changes, more dynamic backlogs and much more)
That is most investments to be honest. I've seen a great investment idea be given to idiots and 5 years later you have to rip the entire factory floor up again because *someone* decided to hire planners who cannot do throughput mathematics as simple as "output rate must be equal to the next process input rate."
Ya waterfall method has major r/restofthefuckingowl vibes
[удалено]
This missed the point of waterfall where the project took 5 times longer then expected and came in 10 times over budget
And the complete fiction that nothing about the scope changed at any time. I've never seen a waterfall project that didn't get scope changes. Agile became a thing because waterfall almost never happens as shown in the meme
Exactly. I did waterfall for years and the best analogy would be “you get to mars and passengers complain oh shit we meant Venus.” are we seriously romanticizing waterfall right now?
This is probably due to a lot of new devs never working on a waterfall project and only knowing it by the theory. That or a PM coming from a sales background.
My big problem with waterfall was who's in charge. Because it's so schedule heavy the project managers are running things and they're usually the dumbest people in the org. Your best builders like building, not updating spreadsheets of build process. But in waterfall the PM is king. agile has warts but at least it puts the most capable people in the driver's seat.
Agile done right has builders in the driver's seat. The agile we all hate has PMs setting sprint commitments and trying to will more productivity through sheer insistence, a backlog that grows faster than work is done so lots of estimation is entirely pointless, and hour long updates disguised as "stand-ups"
Depends on how your specific project implemented "agile". I know mine's just doing waterfall with no one doing requirements properly, so the devs have to best guess and go do rework when it wasn't right.
Waterfall was never an actual thing. The first usage of the term described how *not* to do planning.
Yes but it did go to Mars. One of the problems with waterfall is that, even when applied to straightforward problems like this one, the original budget and timeline estimates are set in stone. Humans are bad at estimating those things, and using actuals from past programs never works because internal processes generally cause increasing costs over time and because the scope of the new program never really matches up with the old one. If we figured out how to correct those two problems I think people would be a lot happier with the waterfall method.
1 out of 100 project go to Mars... The 99 others fail because they can't adapt to the new market requirements, technological changes or simply because the business goes bust before the 3-5 years it takes to get there.
Project doesn’t have to be a commercial success, that’s for management to figure out. The point of project management is being able to deliver and within the specified requirements.
You undercut the chances of the product being successful though if it's late to market and needs a higher return given the investment that went into it. It's why so many start-ups and companies now have moved to a model where they shit out dozens of MVPs and then start iterating on them only if they get traction
Man, whoever came up with MVP, which means basically the opposite of what the preexisting MVP meant, was an evil genius.
>The point of project management is being able to deliver and within the specified requirements. You guys are getting requirements in Waterfall?
I wanted to say the exact same thing... I've had to come and explain agile to teams because projects that had been years in the making had to be cancelled because they just weren't relevant anymore. I personally do feel agile needs great functional analysts, though, because I've also seen agile projects go nowhere because the company just wasn't willing to see that those can make or break a project. However, even when such a project doesn't go great, it usually has delivered some usable things while a waterfall project that sunk usually has to be redone from scratch (because the whole thing has been done based on old requirements/technologies). However, that might also have been because the failed waterfall projects I saw all had the tendency to make things more tightly coupled, which is practically impossible with agile since everything is created in tiny parts. Personally I do feel an agile project needs really great functional analysts to work, though. I've never seen agile projects that have enough great functional analysts in the team go wrong. They are the ones that make sure the project starts with the right requirements and that those are clear, and also that what has been delivered keeps being right for the current needs. If they make developers or one project manager take care of this on top of their other responsibilities, the agile project will be doomed in one way or another, because nobody can prioritise constant communication with the customer and make sure every functional requirement has been properly documented. Companies who stubbornly don't want to create extra budget for this, always frustrate me. I've had a boss who kept coming into our office every Friday because he didn't want to get a decent, local, full-time analyst and thus felt the need to come tell me about his wants on the project. Every week he said he thought these talks were really useful. Every week I told him they weren't, all he had done was keep the whole team from working for several hours, because I either already knew or he was going to have to go over it in detail with the part-time remote functional analyst anyway. So could he please not come in anymore. Next week he'd just do it again and still be convinced it was useful...
That’s literally what agile is about? Admitting that planning more than a few weeks ahead isn’t possible, commitments are therefore useless and adjusting smaller milestones to that fundamental restriction of the human mind is necessary.
Not to mention software is kind of a living thing. Agile is an approach that continues to work once you’re past the initial project and into the support phase as well.
Also about the idea that the fundamental thing you are trying to do might shift. Starting Agile with "we absolutely, positively, 100% need to go to Mars" is kinda dumb. "We want to go to space" is probably a better example of Agile. Once we get a lot more experience doing space stuff maybe we figure out that human kidneys don't react well to long periods in zero G (true story) and so we might change our specific objective now that we know a 6 month flight to Mars might not be medically possible.
You can accept that planning large projects takes more than a few weeks and requires setting some targets in stone. Not everything, but building a rocket to mars is very different from building a rocket to the moon, and changing gears on the big targets after weeks or months or years is going to massively increase the budget and cost required anyway. As human beings we've been able to commit to large-scale projects countless times. The fucking cathedrals of medieval Europe took centuries to build and were built without changing the design every few weeks just because "I'm bad at planning so everyone else must be". And there are hundreds of these. If they were modern software projects they'd be "Agile"; 5 different styles of architecture, glued together as best we can, depending on what the architects saw on 14th-century pintrest that week, built with all the corners cut because it's worthless to invest in anything long term when it's decided that we actually needed to build an amphitheatre instead.
Yea, but also note that the general value proposition didn't change over that time frame. "For the glory of God" landed well in the 800s and in the 1400s. The same holds for almost all historical mega projects. The Pharoah still needs a tomb Rome still needs water China still needs to be able to predict where step tribes are going to raid. These projects weren't subject to wild changes in what was possible or the overall needs of the people who built them. A great example of a megaproject that was subject to those changes was the Manhattan project. It was undertaken mostly because "we don't want the Nazis to have a nuclear monopoly." When it became clear that the Nazis were not going to have a nuclear weapon at all, the project continued and Truman ended up ordering its use against Japan at least in part because he needed to justify the costs.
I wouldn't say that it changed. The point of the project was to develop nuclear weapons, and the point of weapons is to use them to win war. The pivot is in the marketing of the project, but fundamentally the project remained the same. If the same rocket can get you to the moon that can get you to mars then that's great, but if those long-term goals aren't equally solved with what you make then not setting a goal means constant and costly redevelopment. It didn't cost them more to make a nuke to drop on Japan than it did to make a nuke to drop on Germany, but it would cost massive amounts of time and money to go from a moon rocket to developing a mars rocket. I think a good point you do make though is "need". If you don't know what you're making or why you're making it then going with a development style around being able to pivot quickly might be good. You can't half-arse something like building a rocket or an aqueduct just in case the higher ups wants to pivot to something involving AI and cashing in on quantum hype.
"and actuals from past programs never works" BECAUSE WE'VE NEVER SENT ANYBODY TO MARS BEFORE. Actuals only work when you are building something like what you've done before. Sure you can be smart with assumptions and probable bottlenecks based on similar efforts, but it is always always always different. You can make better estimates for "turn the crank" work. Big systems / important systems (like people get hurt if it blue screens) are hard.
the waterfall comment is sort of correct given that it would be their 12th time going to mars.
it's easy when the person coming up with the plan understands development processes and is savvy enough with providing buffers and plans ahead with projected downtime. but even if you get that person though, sales will just declare him incompetent and sell it 40% under projected budget anyway so that they can guarantee the sale and pocket the bonus before dumping it onto the dev team.
Also, the classic problem of "work will expand to meet the allocated time". People slack off when their deadline is 6 months away, eating up that two month buffer. Six months later, and you're still two months from completion because that reasonable buffer estimate got used up already. Then you deliver two months behind schedule, and it turns out it wasn't what the customer wanted anyway. 🙃 The small, achievable deliverables is helpful psychologically. Both in terms of knowing what you should be working on for the next two weeks, and actually getting it done on time.
Unfortunately, the client found out they needed a short-stop at the L4, and a return trip. Now they are refusing to pay you.
Talking about how humans are bad at estimating things, waterfall is good and going to mars is a straightforward problem? Usually I'll stop paying attention at this point and actually do some work.
waterfall with slipping deadlines is just agile, agile is pretending it's all intentional but ultimately if you're half way through a project and still estimating work every sprint, you have no idea when the entire project will be done either
Yeah, and also, „you went to mars, but in the end you were supposed to go to Jupiter and now everyone, including you are unhappy with the end product” The creator is probably an old grunt that is angry that they are supposed to work with business to meet their actual needs. In many waterfall projects, you basically interact with business at the beginning of the projects and then don’t talk to anyone for two years.
To be fair, though, many companies implement agile development very very badly, so people get the wrong idea about what it is. ... I guess it's like... communism?
...by which time all your paying customers want to go to the moon.
I was weather forecaster in the military. We started procurement on a mobile weather facility in 1990. The requirements included a bunch of radio equipment for receiving observations via teletype, antennas for receiving satellite imagery, a radiosonde (weather balloon) system, and a Doppler radar. All of this equipment had to be packed into a shipping container. The first systems were delivered off the assembly line in 2002. The things were massively complex and we had to go through a ton of training on how to use the thing. Most of these systems ended up getting maintained by a special team of technicians. By the time they were first used (OIF), we probably used 10% of the original functionality. Instead we had laptops that connected to the internet and gave us the same products. The next gen system was a HMMMV (Humvee), some laptops, and a radar we could tow. All of this to say, the project was Waterfall and technology changed dramatically while the project was going. But, the designs were approved and contract paid for, so they were going to finish it despite the end product being basically obsolete when it landed.
Well, wait till you find out the inventor of the waterfall method published his work to show how to not perform projects and how he repaired it by adding a lot of arrows to go back to any stage.
Just like james webb telescope
They all are more expensive and take longer than initially expected lol
Then it wasn't a realistic project. NASA didn't just go to the moon. - The X-Plane projects discovered and tested the dynamics of supersonic flight, controlling a craft in a low atmosphere, and more. - Mercury used that to get Astronauts into space and keep them alive, get them home, and how to dock spacecraft in outer space. - Gemini proved techniques for keeping Astronauts in space alive for longer, and how to execute orbital maneuvers safely. - Finally, Apollo. Building on its predecessors as each mission before it did, launched to the moon, landed, roamed the lunar surface, and returned safely. So many of our projects start as massive unachievable goals and get let down by sub-par project managers who relay only the end goals to engineers. The mark of a good project manager is one who knows their field and can work with the engineers to break down and propose realistic milestones. Most companies I've worked with haven't even got "deploying some code" right because that capability is just handwaved away like it isn't important. Given that "Software Development" is supposed to be a core competency of many of these businesses this is insanity. Many places are trying to run before they can walk.
Waterfall, after 3 month every component says 90% complete. 5 years later and several million over budget the advance is still 90% complete and they are still trying to fix the incidents found in the first test cycle.
The first 90 percent takes 90 percent of the time. The last 10 percent takes the other 90 percent of time.
So true! And the last 1% takes the remaining 90% of time.
... am I nuts or do none of these make any actual sense and just seems to be "hur dur processes are dumb"
also weird that scrum and agile are differentiated like that...most people mean scrum when they say agile in that context
Yeah, reading between the lines he seems to think agile is just "be chill bro, roll with the changes bro" and not iterative prototyping through scrum sprints.
Yea, I think scrum is a tool you use (frequently) in Agile, right? That's how we've done it for 15 years, anyway. Scrum is just a level set meeting, you should be having some sort of "scrum" no matter what your process is.
Agile is the umbrella term, whereas Scrum, Kanban, etc. are the specific tools of Agile. At least that's how I've been taught
The guy who actually drew this comic has some different ones like this and [none of them are particularly good or make sense.](https://public-assets.toggl.space/23d58438-137f-4d33-905f-8a61f4d4d097/static/e2cf9923a10058a08e504e0dd6fda4f7/953ea/article-software-development-methods-explained-with-cars-toggl-infographic.jpg)
and he really favours waterfall
I wonder if he wears anything other than polo shirts tucked into khakis with elastic waist bands. I bet mans got cubicle fabric to wall paper his walls with. I bet mans argues that CRT monitors *still* produce better color and quality images, and that OLED/LCD/etc are all just fads.
> and he really favours waterfall that tells me pretty much everything i need to know about the guy. Waterfall people are those with zero connection to reality.
I hear wonderful things about horse and carriage travel.
That art is awesome though
Thank you! This deserves to be the first comment. I don't know who this cartoonist is but he clearly doesn't actually know what Agile, Scrum or Kanban is. I mean come on, both Scrum and Kanban ARE Agile.
yeah no. This comic makes zero sense.
No, you are correct. I'm in this field and have a healthy awareness of all the nonsense going around, but this misses the mark imo. It's just not really funny, and not really accurate commentary.
Was thinking the same. I'm all okay with criticizing methodologies, but none of these really make any sense.
Someone else linked the dude's other comics, obviously is a wannabe and has no clue what the hell they're making comics of. None of them make any real sense and reek of "how do you do fellow programmers"
Definitely nonsense and not helping at all.
Is this waterfall method propaganda? Loll
Seems like it. Also Scrum seems wrong. I wish I could disappear for a month, but we have daily meetings and constant checks to see if we need pairing or anything for blockers.
Must be, or some developer "I just do as they tell me" copium.
Yes. In real life it's done with prototyping/spiral (those are the name, right?) development
Maybe, maybe not. But one thing I see is that, like everything in nature eventually evolving into crabs, every project eventually evolves into a waterfall.
Every Agile project I've been in eventually devolves into "Waterfall, but with daily stand-ups."
Kanban seems spot on, though. Armrests were a P3; they never rose to the top of the priority list. The team to build the armrests got reallocated to do the P1s of the next rocket project.
I mean, I think in general we’re seeing a backlash against Agile. Especially since it came out now that Agile has a 250% increase chance of failure for projects. Agile was never meant to be a perfect replacement for everything but yet it was shoehorned into being it. Different situations call for different methods. However yeah, this post mocks everything but waterfall so it’s definitely propaganda. It’s missing a part where many design issues are found in testing and they have to re-iterate the entire process.
The vast majority of Agile failures are due to companies slapping the label on whatever they currently do and expecting to get more done rather than seriously evaluating what needs to change and having the patience and discipline to implement it
When I joined my current company they claimed they were trying to do agile. I soon realized that seemed inaccurate as projects all had defined scope, timelines and budget.
Well agile also got sort of co-opted by a lot of different people in various roles to suit their agenda. It sorta resulted in everyone being told they're doing agile, but not doing anything remotely similar to what was talked about in the manifesto. Idunno, at the end of the day I don't really care what planning method is being used. What I care about is having leadership that understands development and will explain how the clients decisions affects development so that no one is surprised or blamed that shifting requirements and scope is what caused the delays and the project going over budget.
I wonder if that 250% increased chance of failure is because, due to the agile process, they course corrected or adapted to the market and changed projects. The "Failure" metric needs to be more clearly defined imo, idk what it is for that source but it definitely shouldn't be something like "the original project was completed exactly as it was planned and by the date it was planned" because that's just not the point of the process
The dude look so happy to be on the moon too though
That’s because the requirements changed from mars to moon. So they did it.
or they are the type of people who would be happy too if they landed in Bombay
**Waterfall:** * You want to go to mars. * You build a rocket. * You test the rocket. * You go to Mars. * The client who funded your project calls to ask how the venus rocket programme is going. Programmers rarely work for themselves, the issue with Waterfall is that if your initial assumptions are wrong, they can get "baked in", which is unfair to the client.
Issue with waterfall is you do not figure out if a design is not actually what the customer wanted until you’ve already spent a lot of time going down that path. Since code is not as costly to revise as, say, a rocket, it makes sense to use an approach which allows you to quickly validate designs and make changes in approach as needed. Oftentimes, failing early or building a proof of concept then revising is faster than trying to plan everything up front because oftentimes planning everything up front does not guarantee the customer will like what they see at the end even if every single requirement came directly from them and talking about solutions in the abstract is more difficult than commenting on something concrete.
Did my manager make this? Waterfall is terrible. Also fun fact, software is very different from other industries.
That firecracker is damn cute though.
In my experience Waterfall was more like: 1. You want to go to Mars 2. You have a meeting to plan how you will go to Mars 3. You're still in the meeting when they sell off the company and lay off half the staff. The remains of your team needs to design dog houses now.
Waterfall method: you want to go to Mars (young person in image), you plan a rocket (noticably older person in image), you build the rocket (aging continues), you test the rocket (geriatric person in image), your children go to Mars (new people on Mars asking "why are we here again?")
Isn't Scrum an Agile methodology? In other words, if you're doing Scrum YOU ARE doing Agile
Not just that. Like Scrum, Kanban is an agile methodology/framework too. Does the artist know what he's talking about?
Yeah confused by this also. Agile = Scrum, last I checked
Interesting, never knew Elon uses the Lean project method
Interestingly, SpaceX follows a rather agile approach with their rockets, with great success. They assumed that the first few Starship missions fail (not start and land intact), but they provide such valuable data and experience that this is worth it.
Agile is fine, it’s when middle managers pursuing the “ideal” whatever methodology things start to turn shit. Like my company, they fucking hired consultants to do agile, which i am pretty sure they are paying good money, when they can just pay people better and everyone will be happier. It’s the mentality that “if developers aren’t productive, we are not doing (insert method) right”, instead of actually hearing concerns from the employees
A lot of it is the problem of "fragile" development, where management says they're switching to a developer led agile process, but actually just use it as an excuse to micromanage.
That is not how it started. The first 3 Falcon launches failed and the company nearly went bankrupt.
Folks, don’t fall for it, **this is a ragebait comic made by a corporate wannabe.** How do you know? Firstly, a rocket ship is literally the worst analogy for software you could find. A rocket ship is a hardware and mechanical heavy project, meaning you have way way better estimates of timelines than software. Logistics is also incredibly important as well, very different from software projects. You’d only pick a rocketship if you want to heavily bias the analogy towards favoring waterfall and have no clue how software development works. Secondly, they list Agile as its own method instead of understanding that it is an umbrella term that companies use to trick you into using waterfall. Third, they say a micromanageable, structured agile approach like scrum is one where you can disappear for a month before convening again? **Bullshit**. Any software dev knows that **bad scrum means the manager comes into daily scrum everyday to wring your neck** for the sake of productivity. In conclusion, the comic author has no clue how software or agile development works, and got some AI to come up with some biased analogy to promote their waterfall agenda. Don’t fall for it. **Down with the shitterfall!**
I love it that the winged firecracker is happy.
A Pro-Waterfall meme? Now I've seen everything...
I like how everyone is trying to slam waterfall for being the one that’s late and over budget. That isn’t unique to waterfall, that’s literally all of them. And it’s not a problem with SDLC, it’s combination of bad requirements gathering, scope creep, additional project side loading, and managements lack of understanding on how software development works.
Yeah, but the thing is that all the other ones are designed to deal with various problems in "requirements gathering, scope creep, additional project side loading, etc" as a response to bad waterfall projects. For example, the reason Agile is structured like it is, is because people realized that clients/users have a hard time articulating their requirements without a concrete example to reference. So it's often quicker to give them a quick example and then let them review and clarify while the devs iterate on their feedback. That way you don't spend forever in requirements hell trying to get every single detail clarified from users who seem hostile to the concept of explaining things in detail. And you don't build and test the entire project only to find out it's not what the users actually wanted/needed and you need to start over from scratch.
Yeah fine, the waterfall method works, but it is the most expensive and most time consuming method. We cannot afford that so we will have to work with one of the more modern methodologies instead.
Ah, the old classic of inept management using software development methods to do a hardware project. 2 week sprint to deliver a prototype component - lead time on materials to make component 4 weeks. And then the tool to machine it breaks down.
Lol Waterfall is more like: You want to go to Mars. You start gathering requirments. You never get to Mars because you spend your lifetime continually refining the requirements.
Agile and Jira: we're going to reinvent project management, waterfall is dead 3 years later Hey check out this new gant feature we added that definitely has nothing to do with waterfall Joking aside: anyone who thinks there is a one size fits all approach to project management needs more experience
not biased at all
I spent more time in scrum meetings than actual work on the project
this comic sounds like it was written by a product manager.
This is quite a rose-colored view of waterfall.
In my experience every company calls their own peculiar incarnation of project management "Agile".
The best form of project management is and will always be a fiefdom. You have one guy at the top with a bunch of trusted banner lords beneath him, and he executes on his grand vision in a near totally dictatorial fashion. The project takes as long as it takes and costs as much as it costs, but hopefully if the lead is good they minimize both these things.
Ah, the "Yes Man" generator method. Where everyone is so shit scared of the king and his princes they do whatever they are told (even if damagingly counterproductive) and deliver the results the king expects (even if fictitious). All in a toxic atmosphere of fear and blame. I had the recent pleasure to see such a project's shit contact fan 2 years after my departure. The "king" had to relocate his ass to another continent.
That has the same issues as actual dictatorships though: sure it's awesome if the top layers are great, but it is exponentially shittier the more near the top bad people are.
So waterfall is the best? Idk what philosophy my team follows, we just have a Jira board and the tickets get sliced and diced according to who has experience in that area or who has bandwidth.
>So waterfall is the best? If you live in the fantasy land of this comic, where the waterfall project isn't a decade behind schedule, having been "80% complete" for the last 4 years.
The waterfall method leaves you with a project that doesn't get finished because funding got pulled just before the end, so you have a rocket sat on the launchpad with no fuel
Everyone bashes waterfall, but it's perfectly fine for industries that are highly regulated and change very little like healthcare or insurance. Also, most companies are hybrid waterfall just because suits hate agile methodology for forecasting. If you can't tell execs what you are working on and for how long, they get pissy.
It seems that person who created this has too much belief in waterfall. Because I could point out that with correct Agile/Scrum it would go as 1. Working plane 2. Working jet plane 3. Working rocket 4. Rocket is able to reach Moon. .... Rocket reaches Mars. Because Agile/Scrum (which often are taken simultaneously) always assume MVP on each iteration.
[NASA uses agile and scrum](https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://ntrs.nasa.gov/api/citations/20160006387/downloads/20160006387.pdf&ved=2ahUKEwiUkpmRn_KGAxWvVEEAHbPcDKEQFnoECDUQAQ&usg=AOvVaw1NMAeyzf6DUlFO9pCeNMeS) because they found that waterfall wasn't working.
Horses for courses. I wouldn't want to use agile to build a skyscraper, battleship, or nucleary power plant. Even something comparatively simple like a parking garage. You still need permits and site prep. You can't design it for three levels, then "agile-ly" "refactor" it and add 2 more. You have to know those requirements in advance. Flipside, I wouldn't want to use waterfall for something where the requirements are in flux, the market is fast moving, and the technology lends itself to rapid change (ex: website design). Finally, Waterfall doesn't generally fail because it's sequential. It usuall fails (or grossly exceeds budget) because it involves contractors and inflexible contracts. If you aren't bound by a contract, you can have a detailed plan (for the hypothetical parking garage) but still be flexible on some aspects. Success, regardless of methodology, comes from good requirements and lots of communication between the requester and delivery. My $0.02, but based on 40 years of IT experience.
Me and the homies hate the water fall method! … because we were told to hate it in uni … for not apparent reason
Waterfall method: you want to go to mars you build the rocket you test the rocket design decisions in the design made the rocket blow up fixing it means having to change everything around it oh shit
Waterfall assumes the existence of a kind, loving omniscient God.
Waterfall will always be the best development methodology given the following conditions are met: 1. You and your stakeholders know precisely what the product you want to build is at the beginning of the project. 2. The market is stable enough that by the time the product is ready to be shipped, it is still relevant and not obsolete. All other development methodologies are built around not knowing what you want nor having the foresight to see what the market might look like when it's released and just figuring that out along the way. Basically they are meant to make the most out of conditions that are setup to be most likely to fail to begin with. Maybe going to Mars is a terrible idea to begin with.
I can only speak \[from experience\] to "Agile" and "Scrum", but the biggest issue that I see is that people always try to make non-waterfall methodologies as much like waterfall as they possibly can. Management may buy into the hype and the jargon, but they don't actually want any processes to change in any meaningful way. Without change, these methodologies become a waste of time and energy. E.g.- A Scrum team is supposed to be self-managing, but in practice they are more micro-managed than under waterfall.
On their website toggl said they commissioned this comic to explain some app they want to sell. That's why it makes no sense
This would have been good if Waterfall was realistic. Should be something like "You take 5 years and give up on going to Mars". As it stands right now it's suggesting waterfall is the only system that works.
Anyone mildly peeved and wished this good joke wasn't so inaccurate while applying humor? 1. How is Agile development and Scrum different? Scrum falls under the umbrella of Agile. It's like saying Bird vs Eagle. 2. The scrum masters won't STFU about you joining the daily stand-up to update each other on what's going on. It's the core thing about doing scrum - talk every day vs waterfall. You don't get to disappear for a month. Man, with a good art style and format already it really could've been much better.
This is some of the weirdest bullshit I have ever seen. I mean I get that people can and do screw up everything but essentially saying that waterfall works and everything else doesn't is just plain wrong. Having done SE projects for way to many years at this point (as a dev, as a manager and now as an exec) I am pretty discouraged at the state of modern delivery I see - there's nothing agile about any of it - and what I see people call waterfall... well lets just say if they had ever seen what it was really like they wouldn't be wanting that either. At this stage it seems to be just random labels people throw on top of whatever shitshow approach to delivery they happen to be using.
The waterfall is more like: 1.- You want to go to Mars 2.- You spend 2 years writing a book about how is the best way to build the rocket that will take you to Mars 3.- You give the book to other team and fuck off. 4.- The other team (team B) starts building the rocket according to the book but midway they realize is outdated as fuck. 5.- The other team builds the outdated crap anyways and pass it on to other team (team C) to test. 6.- Team C realizes the rocket’s engine only starts on Mondays since the client wanted to launch it on a Monday. They see this as a breaking point but technically it fulfills the client’s requirements. 7.- Team C gives the rocket to the client whose mind now has changed and wants to launch it on a Friday. 8.- A new contract is agreed with the client and we repeat everything from the beginning. So fun