Agile Development is a Scam
ฝัง
- เผยแพร่เมื่อ 21 ส.ค. 2024
- Discover the truth about the agile development process and why the waterfall method might just be the answer you're looking for. In today's video, I, Alex Berman, share my experiences as an AI entrepreneur, revealing the pros and cons of different SaaS development strategies. Let's dive into the real cost of agile vs. waterfall and understand how to build a profitable SaaS company.
🎯 Key Highlights:
My journey from buying Simple Apps to selling it for profit.
Waterfall vs. Agile: Which is more cost-effective?
The secret to building a minimum viable product that sells.
Tips for ensuring your SaaS provides real value to its users.
👉 𝐈𝐟 𝐲𝐨𝐮 𝐥𝐢𝐤𝐞 𝐭𝐡𝐢𝐬 𝐯𝐢𝐝𝐞𝐨, 𝐩𝐥𝐞𝐚𝐬𝐞 𝐥𝐢𝐤𝐞 𝐢𝐭 𝐚𝐧𝐝 𝐬𝐡𝐚𝐫𝐞 𝐢𝐭.
👉 𝐃𝐨𝐧'𝐭 𝐟𝐨𝐫𝐠𝐞𝐭 𝐭𝐨 𝐬𝐮𝐛𝐬𝐜𝐫𝐢𝐛𝐞 𝐭𝐨 𝐦𝐲 𝐜𝐡𝐚𝐧𝐧𝐞𝐥 𝐟𝐨𝐫 𝐦𝐨𝐫𝐞 𝐮𝐩𝐝𝐚𝐭𝐞𝐬.
/ @alexberman
Connect with us:
Instagram: / alexbermanofficial
LinkedIn: / alexanderberman
Twitter: / alxberman
Website: www.alexberman...
Stay connected and explore more:
🔹 Courses: alexberman.gum...
🔹 Consulting: email10k.com
🔹 Tools: alexberman.com...
I was a software engineer starting in 1992. I retired fairly recently. I observed a major shift in the industry. In the beginning of my career, science, and its principals, were the overriding factor in decision making. Empirical evidence ruled the day. The teams, the engineers, had ACTUAL engineering chops.
Fast forward, and education standards in university have shifted. Less engineer and scientific principals taught/pushed, so they can crank out "developers" instead of engineers, because the industry need more code writers, but couldn't wait for REAL engineers.
Then that brings us to SCRUM, and other agile methods. Never mind that agile methods have been around since the 60's, we're going to pretend it is all new, as we spring up a billion dollar agile consulting industry.
A BUNCH of claims then get made about how much more superior agile methods are over the strawmanned "waterfall" method, so they can sell training.
**And nobody, demanded EMPIRICAL evidence that these claims were ACTUALLY true**
**The once science based industry became a faith based cult. Driven not by science, or scientists, or engineers, or by empirical evidence.**
Software engineering is an applied science, and scientific testing and experimentation, is the path with an unmatched track record in finding what is real, and what is not.
The very few empirical studies done into SCRUM, have shown that the claims, are thus far, 100% false.
How did we get into this state? Lower engineer education standards, coupled with scientifically uneducated management types that think faith, "muh gut", is a valid decision making strategy.
Faith is belief in something, that has no evidence or insufficient evidence, showing it is true, sometimes, even believing in something, that has time and again, shown to be false.
Faith is the opposite of science, and rationality. Bring the science back, and most of this is fixed.
Agreed
Instead of testing people for their natural proclivity for science/technology, bad managers have put in place processes that test for the ability to memorize specific solutions and recite them under pressure. Most developers I know outside of big tech spend most of their free time learning or doing something related to science or math, but most people I've met that work in big tech do nothing related to technology, science or math outside of work other than practice for interviews or build quick money grab apps/websites
As a developer, I have found that 'agile' has almost entirely become a scam at this point. Almost every company that says 'agile' just means waterfall with a lot more meetings. The old milestones with stabilization periods are better than the current popular version you find in most lower status companies. Mix in SCRUM's arbitrary 2 week deadlines and lots of corners get cut. If you read how they build the xbox that sounds like an actual solid agile process based on kanban and forecasting.
Agreed. You’re basically agreeing to a blank check
As a developer I don't think agile is a scam, I think it's just a really bad management framework that somehow became the standard. Meetings every day to give a status update is a stupid idea and are rarely productive, but my performance is judged by how I interact in those meetings so I have to bullshit my updates to not get fired. Planning sessions to break down work into detailed manageable chunks and vote on the complexity of the work in the ticket is a great idea, but dividing the context of a feature into several tickets just to fit the work into a 2 week timeslot (and more often, a few days max per ticket) is stupid. It stretches the work out over a long period of time, while also burning out devs for no reason
this video cleard my alot confusion abt agile model, tbh this model is vry profitable for the development companies providing resources of developers, I guess may thats why its pushed too much😅 pls lmk if I m wrong 😁
Yes it makes a lot of money for the agencies and nobody knows how to do the MVP correctly except for successful founders
@@AlexBerman yes I totally agree
It's a crazy model for both sides, from the perspective of the dev shop owner, it ties you to hourly billing and meetings; it prevents you from transitioning to more strategic work.
Hey Alex! Love the work you are doing.
Guess what- First like and comment again.
Haha nice!
Hey Alex, I like your videos but you are using these terms wrong. The approach you describe has nothing to do with waterfall or agile approach it has to do with founder doing customer research, knowing what he wants, and having a path to revenue. If you'd be using pure waterfall then you wouldn't be able to change the scope during development, which I bet you have changed.
Agile works for large teams, were you have developers, designers, researches and product managers and can work fast. They constantly test functionalities, write user stories and grow.
In case of one or two founders, this often does not work, because 2 founders have often no skill or capacity to test, design prioritize features. So this "waterfall" as you call it works. You have time to focus only on absolutely necessary features (not nice to haves), build it, and try to sell it. Then once you'll reach limits you can have another development "batch". The moment the tool growth will start to skyrocket you will need agile though:D. But then you will have the funding and skilled people to absorb this capacity.
What you are saying is correct in theory. It has not been my experience working with half a dozen agencies on high 5-6 figure projects in multiple countries
@@AlexBerman regardless of the terms I think you are on very right track with doing super minimal builds first and trying to sell them first. That it agile or lean actually :P
@@AlexBermanYour mistake was hourly rates and retainers. If you do fixed price per milestone, like it seems you're switching to, it works well. MVPs are agile, not waterfall
basically doing an MVP.
I thought you did cold emails
Yes
I must say, that this is bullshit :(. Agile and Scrum are so powerful when used properly and accordingly to the book. It's proved million times already that it works and has lots of advantages comparing to other methodologies like waterfall. It's true though that it needs to be used thoughtfully and sometimes it's not a good choice, but in most cases IT IS.
Agile and Scrum suck, for developers in particular.
Can it, scrumbag.
first give me $100
Why?
LOL @@AlexBerman
cause i am first @@AlexBerman