In my recent post, a guy was arguing about this. His point was, with waterfall model it is not possible to embrace DevOps.
Reference: reddit.com/r/devops/comments/7qihtg/waterfall_mod…
Everyone else's comments are pretty spot-on, but I will add this tidbit.
I give every team the chance to prove themselves. Just like Photoshop - you can get the same thing done in a million different ways - and it's not about the tools you use, but how you use them.
However, having said that...
If I see that Agile methodology is being tarnished with constant interrupts and blockers (by a rather traditional stockholder and product owner, "scrumbag"), it's time to go waterfall. A-Z. Otherwise, your full product will never see the light of day, and in my experience, it will be using things that are nearing or have reached EoL.
DevOps mainly deals with how you integrate your code & deliver. It doesn't matter if you are using Agile or Waterfall.
But, yes when you combine Agile & DevOps together you can achieve better collaboration & faster releases.
If you're running a company, your team is definitely doing one of these things; designing a feature, coding a feature, fixing bugs or selling a feature to your clients in a broad sense. You then have a priority on what to build/fix and when to build/fix, often decided by the person in charge. Then there's a deadline (weekly, fortnightly or monthly); which people meet (which is good) or do not meet (in which case you do a retrospective of what went wrong and make sure it never happens again). And whenever something is ready you ship your code and you don't let it rust in your staging branch or staging machines, you want it to you reach your users, if you're not doing that regularly, then you might as well shut shop and call it a day.
Waterfall model is where your workflow moves from top to bottom, requirement analysis and design, writing code, testing and delivery. Whilst often criticised for the lack of of inflexibility, all the other models are variants of the waterfall model with more flexibility. DevOps culture is mainly about getting code to your users as soon as they're tested and ready. So, when your testers sign it off, you ship it. So, I don't see why DevOps culture won't go hand in hand with Waterfall, unless I have gotten the definitions of Waterfall and DevOps Culture wrong.
Regardless of what goofy market-speak business model hoodoo-voodoo is allegedly being used, I think what it really comes down to is who you have assigned to what. PEOPLE are what makes the difference, not some goofy organizational plan. To that end letting people do what they are trained for and what they know how to do is how you succeed.
... and that's REALLY a problem with double-talk buzzwords like "waterfall" and trying to strictly keep things "flowing" top to bottom. The people at the bottom usually just get crapped on thanks to the people higher up in the organization not even knowing enough to be making certain decisions.
I see it all the time where you have the marketing/salespeople who don't know enough about what the coders can even do to even be talking to the customers. They up-sell the impossible, under-sell the possible, and promise a sky that can never be delivered. You end up with upper and middle managers who couldn't code their way out of a piss soaked bag with a hole in the bottom saying "You're gonna use these framework" regardless of if they even apply to the project at hand or are any good, just because they read about it in Forbes or some "professional lecturer" pulled their Jim Jones routine at one of those circle-jerk echo-chamber "developer conferences".
At BEST concepts like "waterfall" or "agile" are nothing more than trying to come up with one all-reaching unified plan for every situation that ends up fitting none. At WORST it is just more of the industry's penchant for bullshit bingo.
I've been programming for 40 years, 32 of that professionally... I've seen this BS before under different names, we'll likely see it again in a decade under all new names. It's still the same double-talk "execuspeak" bullshit so common to academic settings and boardrooms that just gets in the way of what's REALLY important, delivering results.
Which is why any REAL businessman would see right through it in a second for the effete "talk the talk but can't walk the walk" nonsense it really is.
Hey PavanKumar Belagatti ,
What I feel is, might be that guy got a wrong definition of DevOps and he is assuming that "DevOps only do deployments". As Siddarthan Sarumathi Pandian mentioned that waterfall is a top to bottom approach we might see very minimal deployment activity. DevOps hold the responsibility of quick shipment & monitoring of your environment and while facing challenges DevOps team should have to take a quick action on it. When i think from as a end user they don't want to wait for 1 day for a new fixes or a feature and that deliverable are very important. And sharing the quick fix is not the end of story we also have to keep an eye on that, if something went wrong what all action can be taken up , what's the role back plan and these all responsibilities DevOps usually takes up. Even in waterfall if you have given a build and you have monitor as well and issue happens in production immediate action is needed. Also we are getting everyday some new stuffs in terms of technology so the migration of new environment, technology scalibility, new operation plan also is now pitched by DevOps team and which is also applicable for Waterfall model this what i feel. If we will dig more there will be hell lot of evidence we will get why we can have DeOps for all the Software Model.