Like digital transformation and Agile development, DevOps has evolved from a niche specialism to an almost commoditised approach to the SDLC for digital-ready businesses.
DevOps is a philosophy that automates and integrates processes between software development and operations teams. But it’s much more than a suite of automation tools. DevOps aims to shorten the SDLC and enable continuous delivery to release high-quality software.
Learn more about DevOps in our primer
Like Agile, there’s no standard approach or blueprint for DevOps. And that can present a myriad of challenges for organisations which can disrupt their attempts to introduce DevOps or put them off the practice altogether.
Paul Hooper, Francis North Group’s CTO, identifies common challenges with introducing DevOps and shares his tips for overcoming them.
Inertia
Resistance to change can derail the best intentions. To change the working culture, all the affected teams need to understand what the DevOps journey will be, Hooper says. One of the most constructive ways to overcome inertia is to be clear about your goals and direction of travel. This must be backed by commitment from all layers of the organisation.
This can be one of the most challenging aspects of a DevOps project. Francis North’s consultants educate, mentor, direct and support in-house teams to help them come on the journey to DevOps. This is an effective way to provide on-the-job training to the people who will eventually own the processes, philosophy and tools.
That said, we often encounter teams or individuals who firmly resist any change in their practices. It’s common to hear that a particular system or application “can’t use DevOps” because of its age or fragility. Francis North is yet to see an organisation where this is true.
Our consultants can demonstrate the many benefits of DevOps to technology teams who aren’t familiar with it, turning them from detractors into supporters. This capability is critical to the successful introduction of DevOps.
Culture
When clients engage us to provide focus on a DevOps project, our focus is on proving the work, earning trust from in-house teams, gaining their support and working collaboratively through any issues. Over time, trust and credibility grow because of the quality of our work.
“We identify a targeted increment of improvement that will form the basis of the approach. This demonstrates value to the client and helps the overcome any cultural resistance,” Hooper says. Francis North’s consultants are just as sensitive to the solution as they are to how the client will interpret and adopt it.
It’s also critical to have support from senior leadership to help the technology function understand the cultural change needed for DevOps. Executives and senior leaders can champion the change with communication, support, time and financial investment. It’s also important for the leadership group to support the transition to internal capability.
Believing it’s just for internet giants
We’ve all seen the presentations about DevOps that references the internet giants like Facebook, Amazon, Google and Apple. It’s true that these companies are at the cutting edge of software engineering, but they’re also leading the world in innovation. That means some technology leaders wrongly believe DevOps isn’t for them.
The reality is that if your technology function isn’t practicing DevOps, your competitors are. And that means they’re moving faster than you. Moving quickly to respond to changing customer and staff needs is the only way to stay ahead in business. That became acutely clear during the COVID lockdowns when so many traditional companies needed to go online to keep up with their customers.
Being afraid
“We’ve always done it this way” is the death knell for innovation in any organisation. Fear is a terrible reason to avoid any technical or cultural change, including DevOps. There was similar resistance to Agile ways of working but it’s now the standard way to deliver software all over the world.
Focusing only on the tools
Every engineer wants their own toolset, meaning it’s too easy for DevOps projects to focus only on the tools rather than the practice of the overall outcomes.
“We lay down the tooling framework to provide structure or a blueprint. The decisions about tools need to align with that to ensure the strategic vision is achieved,” Hooper says.
Failing to define the benefits up front
Because there isn’t a standard approach to DevOps, it can be difficult to know when an implementation has been successful.
The Francis North approach is to quantify the benefits against agreed outcomes. These outcomes always include speed, agility and cost. A specific outcome could be to free up capacity within a development team, so they can do other activities. A DevOps approach would be to automate the team out of this situation to create bandwidth for that other work.
A good DevOps practice will always remain true to the philosophy of removing barriers between development and operations teams to increase productivity and reliability.
Learn more about our DevOps practice.
