In September we hosted the fourth in our series of DevOps Leaders Roundtable events. Meeting in a virtual setting, we decided to take a slightly different approach for this event, by analysing some of the best strategies when companies introduce DevOps into their businesses. The event was a great success, with some interesting insights shared between some of the best minds in DevOps.
The aim of this event was to provide a platform for leaders in DevOps to contribute their experiences of implemeting DevOps, and what they’ve learned.
Below Co-Host, Grant Smith, Consultant at Zoopla, gives a rundown on the evening.
What are the best strategies when introducing DevOps into organisations?
The primary purpose of this discussion is to help some of our peers. There are still organisations that haven’t made the leap to DevOps yet. One of the observations that has come out of the current pandemic is that those organisations who have already embraced cloud computing and DevOps were much better prepared for remote working than those organisations who are still invested in on-premise solutions and specialist (or from our perspective siloed teams).
Technology isn’t the hard problem anymore, culture seems to be the chief problem now. The strategies that work are about finding the core problem the organisation faces and addressing those problems.
We have found that just as you can’t join the art world, you create an outpost and let the art world come to you. The same is true for DevOps.
Large organisations with hundreds of engineers can spend millions on DevOps and still fail. If you start small, build capability, show the metrics, and operate with autonomy then DevOps can sell services into the projects.
An alternative approach is to consider an assurance approach rather than a mass-adoption approach. Security driven DevOps implementation using automation to prove security controls are being met and what implements those controls. The solutions coming out of DevOps can provide guardrails ensuring controls are continuously met, this can be a great approach in financial organisations.
This assurance/security driven approach is an example of DevOps addressing the core problem the organisation faces.
Understanding the organisational context makes it possible to form the strategy. Senior leadership buy-in makes adopting DevOps easier. Infrastructure is a great place to start as in most pre-DevOps and pre-Cloud organisations it’s considered a blocker as it can never deliver quickly enough and it’s inflexible. Once infrastructure is delivering benefits. Consider the skills teams need. Hybrid working practices don’t work, people always fall-back to their old ways of working. Start with a team that’s hungry to change and willing to do the work. A core platform team is a good place to start a DevOps transformation because these teams have an expectation that they will run a service over a long period of time whereas feature teams have to learn this expectation. Take the successes from that platform team and roll these capabilities out to the feature teams and encourage teams to set their own goals for DevOps adoption this invariably leads teams to accept and embrace running their own services.
Another approach we’ve seen work is turning enterprise applications into products using what had been learned about DevOps. The examples given were large enterprise HR systems and ERP systems. These are some of the toughest systems to work with. Introducing DevOps working practices, including deployment pipelines had a knock-on effect of vastly increasing the rate of releases.
If you’re working with the C-suite and their desire for digital transformation and remote working then it’s possible to educate them on the value of loosely coupled delivery value streams to the customers and then empowering those teams with infrastructure-as-code, and experimentation solutions and agile ways of working. Bringing DevOps into an organisation as a whole requires this kind of holistic approach. Education on agile and systems thinking are a great place to start with building a DevOps culture across a whole organisation.
When organisations state that they want DevOps or Continuous Delivery or Cloud. The first thing to do is to ask why they want these things and what problems they want to solve. Usually the answer is better or faster delivery or cheaper hosting. From this point it is essential to build an understanding of the organisation. Once the culture is understood a pilot scheme can be started. Platform capability can be built and service offerings can be defined and built. Once some capability has been built that knowledge of the organisation’s culture can be used to work with their structures and processes, rather than fighting them. Using automation tools will rapidly overload the systems and processes and then these organisations will come to see how these methods are superior to their old manual processes.
Don’t fight stupid, build more awesome. Unless your sponsor is the CEO someone will have more authority than you and will crush your DevOps approach. The poor state of organisational leadership in the UK is the major stumbling block to organisational transformation. Given the choice we would all choose to incubate a new company within the old legacy organisation that way we can build a healthy and action oriented culture. When we do that the next logical step is to re-integrate that approach back into the main company. This invariably kills the value. Service by service, application by application we can transform those organisations but the likelihood of this working across the whole organisation is very low. Without c-level top cover organisational transformation will eventually be obstructed and devalued.
There can be a clash between transformational change and incremental revenue growth. The two perspectives are somewhat confrontational. Trying to pitch transformational change to someone only interested in incremental revenue growth is very difficult and becomes death by a thousand cuts.
It is common for large organisations to walk headlong into anti-patterns such as having DevOps teams or tooling teams in the development organisation. It’s easy to use the right words but it’s much harder to work the right way. One way large organisations present challenges to transformation projects is demanding that capabilities are immediately available across the whole organisation. Having created a CI pipeline there’s then a demand for that pipeline to support the ancient legacy systems or it doesn’t have value.
It is possible to turn the conversation away from DevOps and on to new capabilities teams need such as the ability to release rapidly, experimentation, tagging and analytics and audience segmentation and implementing these requires a DevOps culture and technology capabilities. A value based conversation can be the right way to start a high-calorie conversation, eventually this will come back to platform and pipelines but it doesn’t need to start there. This is also a great way to counteract this approach that unless something benefits across the organisation it’s valueless because the value of any change regardless of how small and isolated can always be estimated.
There is no one size fits all approach to how to implement DevOps. It depends on the goals of the organization and it also depends on who is sponsoring the change. There are opportunities to build credibility and sometimes this can be done by implementing controls.
If you are interested in speaking at our next event, or attending one don’t hesitate to contact Third Republic or even the host Adam Elliott-Smith directly.
