A Deep Dive on Delivering DevOps Transformation

For any successful transformation exercise there are three main components that are critical. People, tools and processes. When focusing on a DevOps transformation in an organization, it is best described as a journey through multiple levels to achieve full maturity in implementation. We would often find that each level addresses at least one of the components mentioned at the start, i.e people, tools and processes. 

While starting the journey, there is usually a driver or sponsor in an organisation who kicks off the process. The person then might involve internal teams or a 3rd party to support their organisation’s journey towards full maturity. 

When working with organisations who have enlisted our professional services, I usually like to divide the journey into multiple phases that each has a specified deliverable of reaching a particular maturity level. I will be describing these phases which have now become part of our framework for DevOps transformation

Phase 1  – Discovery of state

Initial Audit – Identifying the maturity Level

From our experience with these transformation exercises at CirrusHQ, we define and identify the maturity levels as follows

• Level 0 – No awareness of DevOps
• Level 1 – Aware of DevOps – Defining the needs and requirements
• Level 2 – Planning the implementation of DevOps
• Level 3 – Organised Implementation and Governance
• Level 4 – Optimisation of DevOps practises and Intuitive Implementation

One of the first steps while going through the transformation process is to identify at which level an organisation is currently in their journey. This process will also usually involve identifying key stakeholders through discovery workshops that are held at multiple levels. The identified level of maturity is usually directly proportional to the length of the transformation exercise. This phase also usually identifies any potential gaps of knowledge and areas of improvement.

If these audits are done internally, it is just human nature to create a possibility for false positives and negatives. Hence it is usually better to have a 3rd party perform this audit with a set of objective eyes 

An audit report of the current state matched with targeted areas of transformation with benefits will usually be created and supplied to the organisation as a deliverable, at the conclusion of this phase 

Phase 2  – Cultural Transformation

When starting with Phase 2, for any organisation that has been identified as between level 0-3, there is always a certain amount of Cultural transformation that will need to be implemented. This involves the following

Educating the executive management

The executive management layer is targeted to get them on board with the transformation going through the organisation, with the help of the executive sponsor and the audit report created during Phase 1. The benefits of DevOps are evangelised to them in form of workshops and talks in a targeted manner with numbers that reflect effort and potential benefits. These numbers include TCO (Total Cost of Ownership) and also feature as a supportive argument reflecting the benefits that come out of the investment into transforming the organisational practises. 

Some of the benefits that would be highlighted include smoother delivery of changes, feature releases becoming more rapid contributing towards increase of business value and better change control with increased confidence in the maintenance of the application. 

Any and all concerns from the management are addressed and the plan of implementation starts to get created. This step ensures there is awareness of the transformation across the organisation and makes sure the management is excited about the upcoming change, which is always essential for a successful transformation. 

Training the teams

Based on the organisation’s level of maturity, the principles of DevOps are explained to the teams in workshops with the language designed to target both technical and non-technical members of teams. Their pain points in their existing processes, identified during Phase 1 are addressed and information on how these will be modified are shared with them. Training is also provided on the changes to process or new processes that will be implemented, in the form of workshops and training exercises. 

The training also focuses on enabling the teams to work closely with each other and gives them an introduction of the tools and processes that will be implemented to enable them to manage their work and related dependencies and streamline communication. There is also targeted training provided to different roles in the team in regards to these tools and processes. 

Lean Agile Training

A lot of the DevOps principles align with Lean agile methodologies. The workshops for the product owners revolve around training and coaching them to quantify the features that create business value into small deliverables that can be passed on to the teams as part of sprint planning. The training to the project managers and service delivery managers and the teams will also focus on the core principles around small and reversible changes that create value and enable the flow and establish a continual release cycle with a tight feedback loop on the outcomes. Also focussed training on how automation underpins the devops practises and areas that will be automated and the processes surrounding it are provided during this stage

Organisational transformation

Organisational transformation becomes a natural conclusion of cultural transformation in an organisation. New roles may be created and responsibilities of existing roles will evolve and change. Since part of the DevOps transformation involves changes to flow of information, the levels of management and team structures may also end up changing. 

Phase 3 – Process Transformation

This phase involves implementation of DevOps practises and scaling it up for the organisation. Streamlining of processes and thought leadership are encouraged as well during this. The tools and processes identified during Phase 1 and 2 are now ready to be implemented and rolled out. Though there are various methods of deploying these, we usually recommend deploying the DevOps tools and processes to a small project and then scale it up to all projects and functions across the organisation. The reason for this being, the implementation acts as a Proof of Concept and it ensures that this successful implementation is measured and is visible to executive management and hence increasing the confidence in the overall implementation for the organisation. It also ensures that a continual feedback loop is implemented and hence the transformation itself follows a lean agile approach. 

Tools and Automation

One of the biggest process changes involves exploring and implementing an Automation from ground up approach. This would involve automating infrastructure provisioning, code reviews, patching and security improvements, build phase, testing, artifact management, deployments and operational monitoring and alerting. There are a variety of tools available for these purposes. There is also an upcoming blog series where myself and some of my colleagues will be reviewing the AWS provided toolsets to enable DevOps in an organisation

Sharing Documentation

As the next step, scaling up the process implementation. 70% of this involves documenting and sharing the processes, the associated policies and the tools usage across the organisation and projects in it. The remaining 30% involves modifying these policies and processes to suit any specific requirements. This documentation is stored and shared in the form of Knowledge base and a repository of process and policy documents. 

Operationally, it’s advised each of the workloads have a playbook and runbook created for it. These enable a consistent response to issues, by documenting a process to investigate and respond. The underpinning principle of DevOps of continual improvement is to be applied here as well with continual review and improvement being made to these documents as well by having a cadence to ensure they are updated and empowering the team members to keep these updated.

Governance 

Some of the governance regarding the processes will already be covered by automation of compliance for security and code quality. However a governance framework and a governance body needs to be established to ensure that the policies and processes that surround are being followed across the organisation. There can be one or many governance bodies based on the organisational structure and the level of adoption and their main concern is ensuring the devops practises are being followed and being evangelised. 

Their main goal is to make these processes become intuitive in implementation and continually improved upon, and this is where the governance body plays a part. From my experience, the governance body is usually relied upon a lot more at the start of Phase 3 and when an organisation is at Level 4 maturity, they only need to be involved minimally at key points and act as a checkpoint or stage-gate for choices.

I do hope this brief explanation of our transformation methodology and how we help organisations along their journey has been helpful and if you do want to have a discussion on how CirrusHQ can assist you in your DevOps journey, feel free to drop us a line at info@cirrushq.com or via our contact page.