In this post, we are looking at a high level at some of the things you can do to implement DevOps in your company.

This is day 7/100 in the 100 Days of DevOps series.

Before we look at this in more detail. Why do companies move to DevOps? We’ve already introduced the broad topic of DevOps in this series. Rather than look at generic reasons, let’s look at something more scientific.

According to the 2019 DORA State of DevOps Report, top performers in DevOps deliver code faster, have fewer bugs, and resolve incidents more quickly. Some of the highlights from that report include the following statistics backing up the previous statement:

  • 208 times more frequent code deployments
  • 106 times faster lead time from commit to deploy
  • 2,604 times faster time to recover from incidents
  • 7 times lower change failure rate

Companies that embrace DevOps practices simply get more done. By utilizing a single team comprised of cross-functional members all working in collaboration, DevOps organizations can deliver with maximum speed, functionality, and innovation.

Walkthrough of DevOps transformation

A number of steps exists towards a successful transformation, it’s a long process. The complexities involved in transforming large enterprises means the need for buy in at the highest level to make this successful and implement the changes that are required. The steps you would look to take for a transformation would be as follows:

  • Initial planning workshops
  • Establish a Centre of Excellence
  • Set up governance of the transformation
  • Establish an in-take process
  • Identify and initiate pilots
  • Assessment of current capabilities
  • Scale out the DevOps transformation

Let’s look at these areas in more detail.

Initial planning workshops

Participants must include all of the towers that comprise the solution delivery. Along with operations, security, and development, business participation is required. I always recommend that the workshops in this step be led by an experienced external consultant or coach. The key here is to gain executive support and to establish common goals and understanding of what a DevOps program will entail.

Establish a Centre of Excellence

Creating a Centre of Excellence (CoE) is inadequate if it is not at the appropriate organizational level and enterprise authority. It must be led by a business leader who has the support and buy-in of all towers. Representatives from all delivery towers, as well as vendor organizations, are active participants in the CoE. These participants must be chosen with caution.

Diagram showing the inputs and outputs for a CoE.

You should note the timeline is pointing down in the diagram, this means starting your conversations at the top. My recommendation would be having either the CEO or COO responsible from a sponsorship perspective in the transformation.

Set up governance of the transformation

This is the most important step in changing the organization’s culture. The roles and responsibilities of practitioners will change as a result of Agile and DevOps. To succeed, they will require awareness, enablement, and empowerment. It is critical that they understand collaboration between organizations that have historically had animosity in order to break down these organizational walls. KPIs must shift away from individual metrics and toward overall customer business outcomes.

Establishing governance is not as hard as it is made to sound. Your program governance consists of three main things, communication plans, an enablement program, and established KPIs.

Your communication plan involves frequently publicizing your program objectives, milestones and successes. From an enablement perspective, this needs to be looking at Agile fundamentals for your business leaders so they understand the critical elements. Enablement also includes starting to look at platform and toolchain education for those teams as well as deeper training on DevOps approaches such as continuous integration, continuous deployment, continuous testing, and continuous feedback and improvement.

Establish an in-take process

The first sprint that onboards the program sets the tone for the rest of the sprints. It is not so much a matter of tools and processes as it is of the proper sizing of tools and processes. The selection of accelerators, tool chain, and development methods must be purpose-fit. Once established, the intake process must be communicated throughout the organization. Collect feedback and evolve and mature on a continuous basis.

The success of sprints comes down to best practices. These best practices help enforce consistency and help provide repeatable results across not only pilot teams but also for when the transformation is scaled up. Ensuring you have defined practices for trunk based development patterns, branching and merging strategies for your source control, test automation patterns and processes around test driven development as well as continuous integration are keys to success at this stage.

Identify and initiate pilots

When applied to a specific portfolio of applications or a domain solution, this step has the best chance of success. Prior to this workshop, I strongly advise opening some working sessions to identify an area of development work that represents a portfolio to scale to the enterprise.

The goal of this step is to conduct a value stream mapping exercise with participants from all towers for a specific application. This must be done in sufficient detail to identify the end-to-end as-is process, tooling, manual and automated processes, as well as the skills and people involved.

Assessment of current capabilities

Understanding the pockets of DevOps which exist in your organization is really important. Some of those pockets may be more mature than you realize and you may be able to take some of the good practices already in place and use them in other parts of your transformation.

These assessments can be done in a number of ways but it needs to be something that is repeatable, as you will need to reuse these assessments throughout your transformation in order to check your progress and realign if needed. Assessments need to be broad and detailed.

Scale out the DevOps transformation

The penultimate step is to take feedback from pilot metrics and scale them by running multiple release trains from various application portfolios. It is insufficient to simply perform daily builds and automated deployments. Continuous feedback and optimization are the final pieces of the DevOps puzzle.

Notice I mentioned this is the penultimate step. Actually, you should never finish, just because you have negotiated transformation does not mean you are finished. This opportunity is one to take what you have learned from your pilot groups and give feedback to sponsors, product owners and stakeholders.

Up next

In the next post, day 8/100, we look at DevOps is Not a Job Role!