DevOps with waterfall? Don't waste your time
Can you do DevOps in a waterfall culture?
Sure. You can run sprints across a frozen lake too, but you won't get anywhere. If you try to optimize delivery in a waterfall-siloed world, you'll exert lots of energy and feel like you're working hard, but you probably won't deliver the business results you could. You'll keep people busy improving their silos, but you won't really deliver faster. And to the rest of us watching from the agile shore, you'll look pretty comical.
This isn't about only improving development or operations — it's about both. It's about improving the business by delivering solutions to the business at whatever speed it needs. DevOps is about changing everything so that IT is no longer the bottleneck and can respond to business needs. It's a combination of processes, best practices, and techniques that enable IT to deliver business solutions faster than ever before, with remarkably high quality.
If you're using the waterfall methodology for development and doing the "dev" part of DevOps, you still can optimize and accelerate build processes and implement automated testing and practices to streamline development. But your new code won't get to users until the next release cycle, and all that speed will have been wasted.
If you're on the "ops" side of DevOps, then you work on automating deployment, infrastructure as code, and making the delivery and deployment of code and infrastructure fast, efficient, and reliable. But if the project can't complete testing for another 12 weeks, you'll have to park your Ops Ferrari and wait for the development team to catch up.
DevOps is not about optimizing only one part of the delivery chain
It's about including everything from beginning to end. It's about discipline, focus, and feedback. It starts with understanding the fundamental wisdom from Goldratt's "The Goal": Optimizing in silos can be counterproductive, and you only deliver true value to the business when the entire process speeds up.
DevOps with watefall doesn't work... unless you're DevOps Borat
I've had many arguments about whether the DevOps model works in waterfall-type development projects. I guess it does, if you're DevOps Borat and you live in a reality distortion bubble.
Word "impossible" is not exist in devops vocabulary. Instead we are use "done by Q4".
— DevOps Borat (@DEVOPS_BORAT) March 7, 2013
Waterfall-style projects aren't fast, iterative, or responsive to change. These projects have long cycle times and many hand-offs between parties before anything can be released. Waterfall is designed to work that way.
When you do DevOps on a waterfall project, what you're really doing is streamlining a sub-process. But if you are not actually shortening the end-to-end release cycles and delivering faster to the customer, then what the heck are you doing, really? What business benefit did you deliver faster? None. Implementing DevOps in a waterfall world is an example of siloed thinking, an exercise that optimizes the parts rather than the whole. But you won't find transformative value unless you optimize the entire life cycle.
That is where agile comes in. There's simply no reason to use industrial manufacturing processes such as waterfall to build software anymore. The waterfall method evolved from traditional engineering project management disciplines where much of the work was predictable and repeatable. Building software is inherently different. Software is much more flexible and pliable than concrete or steel. With software, you can be iterative and incremental to deliver value much faster.
When done right, an agile project is both disciplined and structured and can easily be compliant with Capability Maturity Model Integration (CMMI) level four or five process standards. If your goal is to accelerate business value, then it should form the foundation your development teams build upon to increase the velocity of application delivery and decrease cycle times.
You may believe you're doing DevOps in a waterfall world, but unless you're accelerating business value, you probably aren't. Take a hard look at your constraints, and determine what's holding you back. If your waterfall development process is the bottleneck, then perhaps it's time to introduce agile.