What does a "DevOps Transformation" contain?

Question

Some consulting companies are promoting a service called "DevOps Transformation". Multiple big companies are talking about the subject at conferences and meetups around the world.

What does such "DevOps Transformation" entail? How does it look like in actionable terms, both for successful transformations, and failed ones.

Answer 1

I need to put my answer to this question in the context of what DevOps is, more specifically within the DevOps transformations I have been part of, DevOps is the ownership of the full Software Development Lifecycle. All of the practices in the chart are an important part of DevOps, and they enable and underpin both Systems Thinking and Amplification of Feedback Loops.

However, the key differentiator between CI/CD and DevOps is the actual operation of software in a production environment, where it can deliver value to its customers and the business it serves.

As a consultant participating in or leading a DevOps transformation I have the following aspects in the front of my mind:

• Culture: As Dave quite rightly pointed out a Culture of Continuous Experimentation and Learning is critical to the success of any transformation. From a DevOps perspective this comes down to how do we engender a culture that is supportive of the chosen DevOps model, this model could be "You Build It, You Run It" or it could be more along the lines of Google's Site Reliability Engineering practice.

• Operating Model: This is the part of the business proposition that articulates how the organisation will be delivering value, generally by articulating the People, Process and Tools used tied together at a high level. Without an operating model, you have no blueprint for the way the organisation adopt the practices that the culture defines, this, in turn, leads to a lack of clarity and divergent behaviours.

• C-Level Aircover: It is often our job as consultants working within transformation programmes to make radical changes to the way business works. You are going to upset people, and some people won't like the changes - it is important that you have "air cover" from above to change things and move forwards.

Once the high level is in place it is important to find something you can realistically deliver:

1. Start as small as possible, ideally, once you have some people who understand the culture, a sketch of an operating model and buy-in from the executives create the "Minimum Viable Project", don't attempt to boil the ocean by introducing DevOps to an audience of thousands. Set an achievable goal:
   • Automate the creation of the infrastructure from Product X.
   • Automate the delivery of Product X into Azure across all environments.
   • Hand-back support from outsourcer Y to a development team in London.
   • Create a set of tests around our riskiest feature and run them in continuous integration.
2. Great you have some success under your belt now it is time to start baking this into more teams, add another couple of teams into the mix and get them up and running. Don't be afraid to offer "White Glove Support" at first to assist them in the transition; they will need a lot of hand-holding over the coming weeks and months.
3. Now you have several early adopters following a new way of working; you have some critical mass, it is time to start evangelising the work you are doing with a wider audience:
   • Hold regular show-and-tell sessions ask the early adopters to demonstrate how successful they have been.
   • Offer drop-in sessions to allow other parts of the organisation to explore how they can come on board with your team.
   • Enable the creation of Communities of Practice focusing on specific disciplines: Continuous Deployment, Automated Testing, Business Communication, Risk Management, Monitoring and Alerting, etc.

4. Stay the course and close off the transformation by onboarding the rest of the organisation. Understand the relationship between the Gartner Hype Cycle and the Adoption Lifecycle. Prepare for the Transformation Programme to fall into the "Trough of Disillusionment", stay the course and keep the end goal in sight.

   

For a deeper exploration of the final point read Geoffrey A. Moore's Crossing the Chasm. I could quite literally write a book about how to deliver a DevOps transformation, however by the time I had finished it there would probably be no more DevOps transformation work for me to do.

Answer 2

DevOps tends to break down across three major dimensions:

Culture
DevOps culture emphasizes high levels of trust, collaboration and communication between all stakeholders, especially Dev, Ops, and Security. The natural tension and competition between these groups creates friction, and often dysfunction. DevOps is (arguably) first and foremost about aligning efforts between these teams.

Process
DevOps development processes align closely to Agile processes. Ops is encouraged to take up Agile-like practices to better align to Dev efforts. DevOps-aligned processes are designed to support high velocity and fast feedback loops throughout the development/delivery lifecycles. Continuous Integration, Continuous Delivery, and Continuous Improvement (kaizen) are focus areas of DevOps process.

Technology
DevOps isn't a tool, but it is supported by tools. There are whole families of tools supporting a range of areas including Continuous Integration, Source Control, and Application Lifecycle Management.

A "DevOps Transformation" must address elements of all three, but not necessarily all equally at the same time. There is a natural progression and "critical path" for transformation. The argument could be made, for example, DevOps is dependent on some form of Agile practice, at least within the Development team/teams. Issues with culture may need to be addressed before investment is made in tooling.

References:
Culture: https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
Technology: https://xebialabs.com/periodic-table-of-devops-tools/