At a time when technologies and market conditions can change on a dime, it doesn’t make sense for companies to craft five-year strategic plans. Here’s what they should do instead
7 DevOps lessons learned in 2018
Learn from your peers' DevOps mistakes – before you hit trouble. DevOps experts talk burnout, adoption strategy, talent, and more
5. Bring DevOps from the standup to the boardroom
Mik Kersten, CEO, Tasktop: “I believe that we will look back at 2018 and see it as the year that DevOps walked out of the weekly standup and into the boardroom. I was amazed by the number of great discussions and presentations that I witnessed this year on how DevOps impacts the business, finance, regulation, and company strategy as a whole. The point at which I witnessed the tide turning was marked by the fireside chat that Gene Kim did with Christopher O’Malley at the DevOps Enterprise Summit conference in Las Vegas. The message was around the need for a common language that focuses more on value delivery than the details of technical practices. I tried to capture some of the importance of that journey with the release of my book Project to Product. The book is intended to help the DevOps movement make this transition by providing a new managerial framework that spans the gap between the business and technology.”
6. Don’t be afraid to retire old tech
Anders Wallgren, CTO, Electric Cloud: “In 2018, we saw organizations move more and more towards new tech (like Kubernetes, containers, and serverless), and we learned that it will become increasingly important to decommission old technologies. As it stands right now, it’s often something that organizations never do. The analogy we like to use is it’s like hanging onto a broken TV because you might someday have a use for the power cord: It might be time to clear out some of the clutter. We expect that lesson to be greater understood in 2019.
As organizations adopt technologies like Kubernetes, it’s time to consider that these technologies will be around for a long time – and it’s ok to ditch some of your old tech stack. In fact, we learned that holding onto that old technology can mean you are limiting your performance and scalability for the future. While it can be comforting to have the tried-and-true technology of the past in your back pocket, moving on from that can mean expanding your IT organization’s capabilities and impact.”
[ Want to help others understand Kubernetes? Check out our related article, How to explain Kubernetes in plain English. ]
7. The right adoption pattern may be a combination
Ian Buchanan, developer advocate, Atlassian: “I’ve seen a couple of DevOps adoption patterns. One is a central ‘DevOps team’ driving standard CI/CD tooling. The intent fits with advice from DevOps thought leaders: Reduce global complexity. However, such a ‘one size fits all CI/CD’ approach doesn’t address the variation across different teams within an enterprise. Teams are often drawn into challenging standards across functions, fighting about developer practices and tools, such as programming languages and version control tools. With only a mandate to address CI/CD tooling, many centralized DevOps teams struggle with adoption.
Conversely, another pattern is to enable ambitious and autonomous teams to embrace DevOps tools and practices. Again, the intent fits with common DevOps advice: First prove that new ways of working fit the enterprise, then spread. These experimental teams have had a high rate of success in delivering projects with high levels of automation but have faced considerable headwind in converting their team-level experience into enterprise-level knowledge. One of the most common obstacles is the idea of applications ‘in maintenance mode,’ where the appetite for retooling is low. Over time, the sprawl of legacy applications creates crippling complexity that leaves little room for embracing new ways of working.
At Atlassian, we have both high levels of team autonomy and a focus on reducing global complexity. Our central architecture team collects and shares recommendations (not mandates) about languages, libraries, and tools. Teams trust the recommendations to make them more productive, but will also experiment when they see an opportunity for even greater gains. Teams have room to change their mind later and to unroll dead-end technology decisions. To share our success, we have published health monitors and playbooks that help empowered teams and enterprises embrace DevOps ways of working.”
[ What do great agile leaders do differently? Read How to be a stronger DevOps leader: 9 tips. ]