Turning the Ship Towards Continuous Delivery: How to Embrace DevOps in a Slow-to-Adopt Organization


Turning the Ship Towards Continuous Delivery: How to Embrace DevOps in a Slow-to-Adopt Organization

Turning the Ship Towards Continuous Delivery:  How to Embrace DevOps in a Slow-to-Adopt Organization

DevOps is not a new concept. It’s been more than ten years since Devopsdays launched for the first time in Belgium, and the methodology hasn’t slowed down since. These days, in fact, 25% of companies have 3-5 years of DevOps experience, while another 37% have 1-3 years of DevOps practice under their belts. That means more than half of modern organizations have embraced the idea of bridging Development and Operations teams in order to shorten dev cycles, deploy releases more frequently, improve product quality, and ultimately increase customer satisfaction.

Then, of course, there are the other 38% of businesses. The slower adopters often suffer from “big ships turn slowly” syndrome. It’s not that they don’t get the benefits of deeper integration between teams, it’s that operational and cultural change can be cumbersome. In some industries, such as manufacturing, this is compounded by organizational history. When you come from a mindset of handing something off and being done with it, the idea of continuous delivery can be a major shift.

What does it take to begin turning the ship at more conservative companies? In my time as Director of Cloud Development at Insite360, the software arm of retail fuel giant Gilbarco Veeder-Root, I’ve found the following steps to be effective on our journey to DevOps.

1. Start with customer needs

Change never happens for the sake of change. At its core, DevOps improves the customer experience, so customer needs make sense as a starting point. Today’s consumers of any technology product expect high-quality performance, speed, reliability, and continuous improvement. All of these imperatives require the agility to advance your software in a consistent way. If/when customers begin to complain that your product isn’t moving quickly enough to meet their needs, you have the spark to light the DevOps fire.

2. Consider the long-term strategy

My organization, like many others, is currently navigating our move to the cloud. We aim to consume more cloud services internally as well as deliver a completely software-as-a-service product to our customers. For both of these objectives, DevOps is a prerequisite. Cloud enables and supports the breakdown of traditional silos as well as the speed necessary to keep up with modern business. DevOps puts the processes in place to ensure that the potential benefits of cloud become a reality.shared_platform_fuel_truck

3. Focus on the toolset

DevOps proponents often say “People over process over tools.” I agree with this sentiment in theory. In practice, however, I have had more success with “If you build it, they will come.” Making the leap from slow, infrequent, manual releases to automated, continuous delivery demands good tools. If you put the right infrastructure in place, people will gravitate towards simpler, more elegant workflows, adopting the new processes and embracing the shift.

  • For us, the technical foundation began with a CI/CD platform through which we could automate the deployment process. It’s critical to automate every step of the pipeline. We can get code in our repository quickly from the development teams, make a build, configure a server, deploy application files, and execute test in an automated fashion so the results are promptly promoted through environments. Additionally, any networking type setups and security updates are done quickly and efficiently through our pipeline.
  • Monitoring is crucial as well. An intelligent dashboard tells us how our services are performing, not only in the context of customer support, but in the marketplace in general. Our dashboard includes everything from how many service calls we’re making to how many events are getting processed through the system to what services we are actually packaging and delivering to our end users. It makes our data consumable and allows us to measure what we want to show, not what the data easily serves up.

4. Adjust your release cadence

With the right toolset in place, you’re ready to accelerate the release cadence. This process is at the heart of DevOps, and can be as much of a psychological shift as a technical one.

  • My organization originally suffered from large, infrequent releases. It was a vicious cycle: because releases were so big, and testing was so manual, they usually had quality problems. The blowback from those quality problems made people reluctant to release again, so releases got held further, which made them bigger, so they got even worse. These big releases also, of course, included more data and more change, which confused customers and made it harder to get feedback on each new element in order to improve.
  • Evolving to smaller, more frequent releases doesn’t only depend on your data pipeline. It also means helping team members get over their fear of breaking things and get past the idea that small releases will interrupt the customer and the product. It necessitates a “show, don’t tell” strategy in which you just start deploying releases more quickly, even if everyone isn’t on board. Ease detractors’ minds by demonstrating how small releases let you figure out what’s wrong quickly, get clearer feedback, and fix things faster. The “fail fast” philosophy is a big change for many people, but once folks see its impact in action, the shift typically happens more smoothly.

5. Encourage experimentation

As your team gets more comfortable with the new tools and processes, continue to lean into the DevOps methodology.

  • For instance, once your new, smaller, faster release cadence has stabilized, encourage experimentation. Show your team how tightly aligned processes can surface more meaningful data (and more of it) that lends itself to trying new things. Give people confidence that they’re not going to ruin the product or introduce security vulnerabilities, because the processes in place don’t allow it. Highlight how DevOps works as a safety net to not only streamline day-to-day operations but to facilitate innovation and growth.
  • Operationalize experimentation by emphasizing measurement. Create SLAs for new capabilities and monitor them religiously. Consider techniques like blue-green deployments and canary releases to mitigate risk around deployments. Eventually, you will have enough lockstep processes and cultural change in place that experimentation becomes natural to the overall organization.  

DevOps isn’t just a flavor-of-the-week IT trend. It represents a fundamental change to the way teams have traditionally worked together (or not) to deliver customer value. We are still relatively young in our DevOps journey, but the results are already striking. We release as often as we can so we can get feedback as quickly as possible. Then we fix what’s broken, or make what’s working better. It’s both simple and game-changing, and done right, it can be a dramatic differentiator for the business.



William Wong
Cloud Operations Director at Insite360

William has a passion for getting results and isn’t afraid to experiment. He has a strong belief that you get things done quickly which is why devops is so important to him. Automating the simple things in software is important for quick feedback, uptime and availability. His years in different parts of software development teams provides a unique perspective not typically gained in a cloud operations role. William has spent a majority of his career in the petroleum industry with software development and is excited for the next chapter of Insite360's transition to cloud computing and platform as a service.