Agile has been around for almost 20 years, and as such, it has continued to evolve. One of the more interesting things to come out of the Agile methodology is the DevOps movement. Agile is by no means a strict process, but instead a set of principles to consider when determining how to best develop software, with some practices outlined to help achieve these goals; mainly, working software that satisfies the customer’s (potentially) changing desires.
Over the years, Agile has faced many criticisms. Most of these have come from people implementing Agile poorly and blaming Agile for their own failures. Some people go so far as saying that Agile is dead. Rather than be contradictory to Agile, its goal is to be complimentary, build off of Agile, and strive to deliver some of the promises and principles of Agile that many organizations struggle with.
What is DevOps?
Most discussion I hear about DevOps is centered around releasing software faster and more frequently. And while this is certainly one of the major metrics to show effective DevOps practices, that is short sighted of the DevOps mentality.
DevOps is all about increased communication between Development and Operations, and breaking down barriers between teams, and ensuring no part of the organization is siloed off from the others. Similar to how Agile forces Developers and Testers to work together, DevOps is meant to have the Operations folks join this collaborative effort. While often this does lead to increased release speed, that’s not always the case. It doesn’t necessarily mean you’re doing DevOps wrong if you’re not achieving increased release speed.
There can be many reasons for not releasing rapidly including: bottlenecks in testing, fixed release cycles, user requirements, or even regulatory restrictions. Rather than focusing on throwing software at your customers as fast as possible, DevOps is about empowering the entire team to have a holistic view of quality on the application thus stopping much of the finger pointing that goes on during releases. The true end goal is to have the ability to release software in a robust, repeatable fashion, anytime, with a known quality and risk factor.
Providing tools and methods to let Developers deploy and test locally, and having Operations provide robust pipelines providing insight to quality metrics about the software is advantageous. Not only can the software be released more rapidly, but the organization can easily decide if it should be released.
What About DevSecOps?
In the last 2 to 3 years, DevSecOps has been a major buzz word around many organizations. The supposed idea is that DevSecOps is DevOps with security included as well. But if the goal of DevOps is to focus on robust releases, while understanding more about what you’re releasing through metrics and quality data, security must be included in this, otherwise you’re just releasing vulnerable software quicker. The portmanteau of DevOps is not meant to say we are including Developers and Operations, and leaving out everything else, but instead, think of Development and Operations as book-ends, with DevOps including everything in between as well; testing, security, performance, etc.
To me, the only difference between DevOps and DevSecOps is marketing. It’s a buzz word that came about because too many people have implemented DevOps without security, are suffering, and rather than say, we did it wrong, came up with a new term. You see this in a lot of places, not just in DevOps.
In consulting, I have gone into countless organizations talking about DevOps, Agile, or even test automation, and I hear the same thing, oh, we tried that, and it didn’t work. Once I dig around some, what I typically find out is that yes, it doesn’t work, because you did it wrong. What you tried wasn’t Agile, you just had long status meetings you called daily standups and had sprint plannings without including the business or testers. You saw overhead grow, and didn’t get any benefits, because you focused on some processes, not the principles (in this case collaboration). As a result, the whole organization is turned off to Agile.
The same thing has happened with DevOps, and so to recover, they then need a new thing to try, essentially rebranding the original idea to one that your organization hasn’t rejected yet. I’ve found DevXxxOps everywhere. DevTestOps, DevSecPerfOps, and my personal favorite, BusManDevTestSecPerfOps. I’ve heard people brag about how much more inclusive and better their brand of DevOps is, and sometimes, I let them off the hook. They’re achieving what they need, which is breaking down barriers, and getting the whole organization involved and communicating in the software development process, which is what they needed in the first place.
Where To Go From Here
Remember, the goal of DevOps to increase collaboration across the entire organization so that you have the ability to reliably release useful software rapidly to the organization. What you want to call it, is up to you, but in my opinion, all the other names out there for DevOps are just fluff. They are all about people blaming DevOps for their own failures in understanding the intent of and being able to successfully implement a DevOps culture.
It’s important to note that, just as Agile isn’t a set of tools, DevOps is about a cultural mindset and set of principles. We don’t have our Agile engineers off to the corner, we engage the whole team in Agile practices. Similarly, we shouldn’t have DevOps engineers who ‘do the DevOps’, instead we want cross functional teammates who all participate in DevOps practices.
There is a lot of information out there about DevOps, particularly, different brands of DevOps, like DevSecOps. I’d encourage you all to read more on it, make up your own decisions, and figure out what the best practices you can bring to your team to help improve your software. I definitely recommend reading The Phoenix Project, or anything written by Gene Kim, Jez Humble, or Nicole Forsgren. Good luck, and remember, at the end of the day, we’re all on the same team, we all want working software.
