I worked at a place where, while it was never called "waterfall", it was absolutely the way things worked. I think it naturally evolves this way:
1) a software project, when finished, turns out not to fulfill all of the things people wanted
2) "we should plan more carefully next time, so that all the requirements are identified at the beginning"
3) the next software project starts to resemble waterfall, but still misses some requirements
4) "we should spend more time on the requirements phase next time, so we don't miss anything"
5) etc.
It is the natural method that large organizations end up with, in the absence of any philosophy saying otherwise. It's not the natural method that startups or small organizations end up with, probably, because it involves a ton of meetings first, before anything is done, and that is something that happens more in large organizations.
Waterfall is what you get when it is always the safer option to say, "wait, let's spend more time planning out and getting buy-in". There may not be many places that call it "waterfall", but there are a lot of places that do it. Some of them even call it "agile".
The way you can tell you're in one of these dysfunctional companies in my experiences is at the moment you, as a software developer, have to attend TWO meetings in one day. Companies that have too many meetings tend to have middle managers with only one goal for all these meetings: "Covering their ass." They treat these meetings as a way to collect evidence to be used later to prove that they weren't at fault when the project fails to meet it's objectives.
I'd say more than 5 meetings a week for an IC rather than two in a day. (I have 3 meetings a week, but two of them are coincidentally on the same day). Managers will naturally have more meetings.
I agree, you're right. I didn't think of it that way because most agile teams have a mandatory scrum meeting in the morning every day anyway. So a meeting is always literally the first thing you do...or at least it's your first interruption that comes right about the time you begin concentrating.
It's super counter-productive too because in the morning is when I'm at my most productive and a guaranteed interruption every single morning is horrible.
> It's super counter-productive too because in the morning is when I'm at my most productive and a guaranteed interruption every single morning is horrible.
At least in my bubble, tech seems to be skewed heavily towards night-owls. I winder if putting the meeting in the morning is due to people assuming that, since they aren't productive in the mornings, neither is anybody else.
In my 20s and 30s I wasn't productive in the morning mainly because chances are I was out half the night drinking. Since hitting my 40s, I'm most productive in the morning, because I'm never out late.
1) a software project, when finished, turns out not to fulfill all of the things people wanted
2) "we should plan more carefully next time, so that all the requirements are identified at the beginning"
3) the next software project starts to resemble waterfall, but still misses some requirements
4) "we should spend more time on the requirements phase next time, so we don't miss anything"
5) etc.
It is the natural method that large organizations end up with, in the absence of any philosophy saying otherwise. It's not the natural method that startups or small organizations end up with, probably, because it involves a ton of meetings first, before anything is done, and that is something that happens more in large organizations.
Waterfall is what you get when it is always the safer option to say, "wait, let's spend more time planning out and getting buy-in". There may not be many places that call it "waterfall", but there are a lot of places that do it. Some of them even call it "agile".