At times, the world of business can feel like a hype train. Concepts like DevOps and Agile start to appear more simple and straightforward the more popular they get, with their widespread success often masking the work and complexity that goes into using them in practice.
The truth is that when it comes to non-prescriptive ways of working, and DevOps in particular, implementing them requires the input of one or several experienced practitioners. Businesses also find the process of implementation to be one of ongoing improvement, with practitioners constantly on the lookout for new tools, skills, and ways of working to incorporate into their unique management style.
This is certainly the case with ‘DevOps cultures’. These cross-functional teams have staff with significantly varied skills and backgrounds, all responsible for the overall success of the services they create and support. Previously siloed teams find themselves working together in a way that encourages them to share insight and suggest further improvements wherever possible. DevOps pipelines must also evolve to meet the changing demands of the digital and IT sphere, with elements like security having a great deal more prominence now than they did ten years ago.
In essence, creating a DevOps culture is far from a simple affair. Rather, it is a process of continuous reoptimization and improvement, with senior DevOps engineers constantly working to optimize their pipelines while still sticking to the tenets that have made DevOps so successful.
That is not to say that businesses should feel put off about utilizing DevOps. Rather, it’s simply important to make yourself aware of the challenges of first implementing a DevOps culture and how to tackle them in a way that makes the process expedient, efficient, comprehensive, and fluid enough to suit the unique needs and characteristics of your business.
Award-winning online training provider Good e-Learning recently got in touch with the DevOps Institute and its subject matter experts to gain some insight on how to tackle the challenges of creating a DevOps culture.
Let’s take a look at what advice the experts have for businesses getting started with DevOps!
Integrating Dev and Ops
GEL: “Breaking down silos is not always easy. Developers usually want to work quickly, with new releases and innovations churned out at a rate that should, in an ideal world, keep the company ahead of the competition. Operations staff, on the other hand, prioritize stability. Their goals must be aligned and responsibilities shared. What is the best way for DevOps engineers to accomplish this?”
Nadeem Augustine: “Over the past few years, having been a DevOps leader and implementing best practices and tech across different organizations, the hardest change is the culture, especially when organizations have a huge staff complement and are set in their traditional ways of working.
“What I found the best way to tackle the life of DevOps is to start with a small team/ business unit. This way, you show not only the value but also the benefits and the quick turnaround time for having the Dev and Ops teams work together as opposed to separate teams.
“I personally found that when going big and trying to force down, the adoption does not work. People do not see the value or understand what DevOps means, and you create a negative view or get resistance. Having had the opportunity to roll out DevOps in a few organizations, and having failed at first with the top-down approach or big bang in some cases, the best way that I have found is to take everyone on the journey and get the tech staff of the org to help set this up as they will be the key role players in this operation.”
Evolving legacy infrastructures
GEL: “If a company has been using a legacy system, it may be resistant to large-scale change. This can also make it vulnerable to competitors. In some cases, this means switching to microservice architectures, but this is not always the best option. How should a DevOps engineer’s approach vary depending on the size and nature of legacy infrastructures, and how can they minimize disruption to essential services and products?“
Peter Maddison: “Take a careful look at what business problems you can solve. Identifying and mapping value streams can be incredibly valuable to find constraints. These will be your initial focus points.
“Even so, keep in mind it will take time for people to come over to adopting new ways of working. One database leader we worked with took 6-months to come around to the automation of database change requests. After this, he became one of the biggest advocates.
“As with all my answers, ensure you are focusing on an actual business problem. Start small, demonstrate success, and broadcast it. The people who come to you will be far more bought into ensuring progress.”
Nadeem Augustine: “Understand the landscape by doing a VSM, know your systems, tools, and processes in order for you and the team to make an informed decision. Legacy always comes with an aspect of risk. This means people, processes, and systems.
“Focus on what matters first. If there is an app/tool that can change within a short space of time, then start there and transition to modern technology. By doing this, you create a following and buy-in from people as they start to see the value of having to move into new ways of working.”
Choosing the right tools
GEL: “There are a variety of competitors in the DevOps marketplace. DevOps engineers must be able to choose the right tools for the job AND make sure they are well-integrated. Certain tools are also standard for DevOps engineers, while others may cause team members to clash and develop new silos. How can a DevOps engineer choose the right tool for a new DevOps culture? What do they need to take into account?”
Peter Maddison: “Consider you have tiers. You can create a paved road, the easy way, that will take into account organizational concerns. However, your shining stars of teams will likely be held back by such a platform, so let them go, let them learn, and integrate those learnings back into the platform for the rest of the organization.
“Avoid integration nightmares and the proliferation of tools with equivalent capabilities by including teams in the discussions. Wherever possible, keep it simple and avoid having to build or create your own integrations. Look for toolsets that work well together.
“Remember, you can’t keep everybody happy.”
Nadeem Augustine: “This needs to be considered not only by an engineer but by the overall organization, as these tools will play a key part in delivering value and consistency across the org. Tools are important but would be easier to adapt to if the process is mapped out. Build the process and framework, and then choose a toolset that matches that. Standardization is key as this will help with overall value saving in an organization.”
Resistance to change
GEL: “This is natural when shaking things up in a business. How can a DevOps engineer sell the benefits of DevOps to stakeholders and team members? How can a DevOps culture be implemented without anyone having to build everything from the ground up? How can DevOps engineers prevent complacency when first implementing a DevOps culture?”
Peter Maddison: “Don’t assume it is the DevOps engineer’s job alone. Starting a program called “DevOps Transformation”, hiring or restructuring into a new “DevOps Team”, then charging them to “do DevOps” is a sure-fire way to create an ineffective silo. If you are inflicting DevOps on people rather than inviting them to come on a journey, you’ll have problems.
“Instead, try this: 1) Map outcomes, value streams, dependencies, and capabilities. Focus on solving the most valuable constraints (at its simplest cost/impact though other forms of value will likely exist). 2) Communicate, communicate, communicate. If you are not tired of talking about it, you are not communicating enough. 3) Wherever possible, keep the platform open. Let the delivery teams contribute. It is their process, not the DevOps teams.”
Nadeem Augustine: “The key here is to create visibility of what DevOps is and what it can do to help us as an organization. There is a lot to consider, including people, processes, and tools, as well as how people react to change, especially after being in the comfort zone for years.
“I would take it by doing apps/areas that matter and can be quickly converted into a DevOps model, i.e., small process, small teams, small apps. Map out key processes and use that as a start for a VSM. Create showcasing groups of what’s coming and what’s new. Get the teams on training and get them to help map out the journey as they will be the key drivers of DevOps. With communication and visibility, the adoption of DevOps will cause less resistance to change, as people will feel valued and included in the journey.”
Nadeem is a certified DevOps Leader with over 12 years of experience working in Dev and Operations. He currently works as the Head of DevOps for Oldmutual, as well as the Chief Operating Officer for Americo.
“I believe DevOps bridges the gaps between, not only the gap between Dev and Ops but also the gap between our management. This allows and creates an environment whereby titles don’t really matter, and we all work together to achieve one goal. Repeatable and reliable process!
“I used to be an Operations person and being in an environment that is always to blame for incidents due to bad deployment, unstable infrastructure. I used to always find ways to close those gaps and make sure the dev and ops teams work together. It was always a challenge, but since then, DevOps has become a thing of the past. Having the ability to share and help other orgs go on this journey is something I am passionate about.”
The DevOps Institute
The DevOps Institute is a professional membership association whose mission is to advance the human elements of DevOps by creating a safe and interactive environment where our members can network, gain knowledge, grow their careers, support enterprise transformation, and celebrate professional achievements. We connect and enable the global DevOps community to drive change in the digital age. DevOps Institute ambassadors are pioneers in DevOps and some of the world’s most foremost thinkers and advanced practitioners of DevOps ways of working who volunteer to share their wisdom and expertise with the humans of DevOps, globally.