DevOps is transforming the ways organizations are building and delivering software to their customers. But far too often, I see organizations struggling to see tangible benefits because they have only slapped together a few tools instead of making the required changes. Many organizations are proclaiming their devotion to DevOps but aren’t really embracing DevOps at all.
These indicators can help you determine if your organization isn’t quite ready yet to practice DevOps.
1. Silos are commonplace
When most organizations start a DevOps journey, they treat it as something they can buy, some special tiger team they can build, or something that can be tacked on. This mindset leads to continuing to maintain traditional organizational silos while just renaming the teams: Development becomes the “Agile Team,” and Operations becomes the “DevOps Team.”
Developers will continue to try to rapidly deliver changes (often at the expense of quality), and Operations will continue to slow-roll deployments, just now with more automation that doesn’t serve the true business needs.
Without bringing the “Dev” and the “Ops” together, you can’t drive collaboration that results in more repeatable, frequent delivery of high-quality code.
If you have a DevOps team, you’re doing DevOps wrong! Start bringing your developers and operations together with one stand-up and work from there.
2. You’re not really using agile
A colleague once told me, “You can do agile without DevOps, but you can never do DevOps without agile.” The more I work with highly functional DevOps organizations and those that stagnate for years after getting started, the more I realize that statement couldn’t be more accurate.
DevOps practices like continuous integration, continuous deployment, and continuous delivery are natural progressions of agile practices, like small iterations of working code. If you’re attempting to actually implement continuous delivery on a waterfall project that releases to production once or twice a year, you will not be able to practice enough deployments to production to expect automation to be free of defects and a high level of risk.
If you find yourself in this situation, it’s time to seek out an agile coach or an expert in agile transformation who can help you with your journey and ensure the investment in DevOps pays off.
3. Failure is not an option
In IT, people and cultural aspects are often deemed too difficult or taboo to address, but it is essential to DevOps. Organizations can have all the right tools and even write code in an agile manner, but an inability to adopt the cultural aspects of DevOps will cause failure.
Is your organization so risk-averse that it is unwilling to experiment with new technologies? Is public shaming or “closed-door” scolding the go-to for management? Is losing your job, access, or ability to deploy to production a possible outcome of a failure? If so, your culture is not conducive to DevOps.
Any failure should be treated as a learning opportunity, with a postmortem and action items to make sure the mistake is caught the next time. When the failure is deemed a shared failure (from engineer to manager) and everyone simply acts like it’s another day, then you will find your organization has adopted the right cultural philosophy needed for DevOps mastery.
Originally posted on TechWell Insights.
