The benefits of DevOps are plenty: improvements in product quality, minimal cost production, faster deployment times and a greater sense of ownership and work satisfaction from engineers.
But while the benefits of shifting to a DevOps model may be clear, understanding how to do it can be a lot less straightforward. For companies ready to start implementing a DevOps culture, the first step is to throw out the rulebook.
“I think one of the common mistakes leaders make who want to adopt DevOps is that they think they can read it in a book and implement it,” Damien Jones, CEO of Blue Pisces Consulting Inc., said.
The foundation for DevOps culture is communication, a shared vision and the right tools. However, it’s a culture that’s meant to evolve. Not all DevOps methodology works the same for every team or project. Adjusting communication techniques and tools is part of the strategy.
Successful directors know when to step back from their DevOps team and let them ideate. Giving them the room to learn from failures will also give them the freedom to collaborate and succeed.
Jones implements three C’s in DevOps culture at Blue Pisces: communication, collaboration and coordination. There is no rulebook; executing DevOps requires adjusting its methodology for each project. From there, openness to adaptation and change helps evolve DevOps into the best fit for the company.
How did you go about implementing a DevOps methodology within your tech organization?
Implementing DevOps in an organization takes the threes C’s: communication, collaboration and coordination. You must gain buy-in from your peers that may lead other segments and work with them to ensure a smooth transition. It is imperative to remember that DevOps hinges on partnership, a common goal and that everyone is part of something bigger than themselves. Being a servant leader in this time of implementation will serve you and your team well. Once you have the methodology in place, don’t be afraid to adapt and evolve it to fit your organization. Iterating and refining the process over time will ensure a much stronger, flexible and scalable solution for your technology organization.
From your experiences, what are the key characteristics of a strong DevOps culture?
When it comes to DevOps, I like to say it’s about “working in the gray, not the black and white.” In other words, given the nature of DevOps and the need to be collaborative and partner with your business leaders, it’s important to avoid drawing hard lines and rather be comfortable with working in the gray area. That’s not to say you should have to overextend your team all the time, but be a willing partner in the true sense of the word. It’s OK to take a little more, or a little less, if the greater good is being served.
A good example is that as a very notable client began implementing DevOps, it was really being led by infrastructure-oriented teams rather than application developers. Where you might expect developers or release engineers to build pipelines to meet their deployment strategy, it was the infrastructure team building pipelines to match the code deployment methodologies and educating the development teams on various tools and integration strategies to surround CI/CD. That was OK. It worked and the teams all evolved. Over time this could be handed back to development teams who were in a much better position to own this than had it just been thrown in their laps.
One of the common mistakes leaders make who want to adopt DevOps is they think they can read it in a book.”
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
I think one of the common mistakes leaders make who want to adopt DevOps is that they think they can read it in a book and implement it. Oftentimes, they understand the general concept and think “that makes sense, I get it,” and then struggle to implement it successfully. DevOps is not a textbook or playbook that you can just take and follow. It is a culture. It’s something you have to build, nourish and continuously evolve. To do this right takes experience paired with a strong understanding of your enterprise capabilities, talent and appetite for change. In other words, don’t be afraid to ask for help. But be careful when searching for that help as companies like to throw the word DevOps around without having practical experience.
Pluto TV, like most companies, didn’t begin with a DevOps team. Lloyd said that in order to execute a DevOps culture without causing disruption to the business, it’s important to set boundaries and have clear definitions of roles. DevOps leaders need to be experts in the infrastructure and automation, but also communicative in how their team should implement those processes.
How did you go about implementing a DevOps methodology within your tech organization?
We needed to make a fundamental shift in thinking. We focused on automated processes and tools as opposed to a rapid “results-first” methodology. It’s required a balancing act of providing for the operational needs as an organization and thinking how to best solve potential issues further down the line. A DevOps culture can’t be built in a silo.
A DevOps culture can’t be built in a silo.”
What are the key characteristics of a strong DevOps culture?
An interactive process, communication and transparency of goals. It also requires a bit of evangelism to act as a representative for DevOps as a focus. We work to provide a working proof of concept early, transitioning to MVP and then a fully baked pipeline for the organization.
What advice do you have for other leaders who want to adopt a DevOps model in their organization?
Set boundaries and clear definitions of roles. Most organizations don’t start with a DevOps process, so DevOps resources often have to become experts not only in providing new infrastructure and automation but must do so in a way least disruptive to normal business.