Just realized one of my partners works with the waterfall methodology. I told him I'm sorry i cant work with him. What do you think?

You can ask them to try an agile process and then if they don't like it, then you can discuss the process and see what worked and what didn't and why. Then you'll both learn from the experience. Otherwise, you are just dividing the people. But also, generally - you are making the right move. I wish I had told 20 clients that right off the bat.

@sheriffderek according to him, agile is a stupid teenager way of working 🙄

So you decided in advance that you can't work with him, then put that plan into action by telling him, and now you're testing that by asking on DevRant?

Hmm, good thing you avoided doing waterfall. ;)

@Grundeir i want to know who is right here. Me or him? He's an older guy so I need to know what I'm saying and doing is as per todays trends :)

@appmaker Ah. Well, agile isn't a noun, but - he sounds like a fool. It's really hard to convince people to look at things differently when they don't feel the same about design, especially marketing teams whose only ammo is mockups and decks. A new way of selling ideas is in order.

@Grundeir hahahahahahahahahah

@appmaker Well, each project is different, and agility may involve some water - but he's stubborn and you aren't a salesman. I've seen agile approaches that are just as silly as any waterfall. You have to move toward your goal in baby steps and if it's just a boring website... there may not actually be any real goal or 'design.' But you can say you are right... and you'd likely be right... but really... you can say you are right when you prove it to him.

@appmaker The majority of developers probably agree that agile is better. However, there are still plenty of people who think otherwise.
I am definitely of the opinion that agile has the potential to be far more effective. However, many people do it wrong and kill their productivity in the long run. For instance, agile does not mean: don't write documentation ever. Not writing documentation is stupid and will bite you in the ass.

I see you are full stack, that doesnt really work well with waterfall, but small projects tend to get done way faster so its worth considering

@RazorSh4rk Actually, agile really starts to shine with large projects. I don't think the difference is very noticeable for small projects. A one-sprint project is just waterfall, after all.

The real power, in my opinion, is the fact that you make small, incremental changes. This reduces the time that was wasted if a change isn't going in the right direction.

Ask yourself this question. Is it fully and 100% clear what needs to be build. If yes then document the hell out of it and use waterfall. If no use agile. If you can't be sure what to build waterfall isn't for you.
Case is in most web development related work customers don't know what they want even if they say so. Because as soon as they see the product they wanted, they would like to add changes or it isnt what they expected.

Good luck!

Did you explained him what you meant by Agile??? Because to me it's as vague as big data, web 2.0 or "computer guy".
What i do, is agile software development by trying to apply it's fundamentals and using kanban/lean and some events and artefacts from scrum... I have never done Agile...
And a good waterfall is always better than a bad/lazy scrum

So it was about a web project regarding payments. So I told him lets make an MVP and then lets go into details from there. But we spent 6+ hours just to design a user registration table and its related relationship tables. Im a full stack dev so I pictured how the MVP would be right when we spoke about the project. I exactly knew what the MVP needed. Many good ideas end up not getting completed because people go into too much details. What I believe is that we should have an MVP ready and then add on the "required" + "legally required" add ons to the product when we plan to launch. Please correct me here if im wrong anywhere.