Ensuring that your DevOps transformation creates  real value

In his blog “Enterprise DevOps Transformation”, Abel Wong from Microsoft describes the lessons learnt while undertaking Microsoft’s DevOps transformation journey. In summary, Microsoft transformed their entire company from a waterfall-oriented business (delivering new versions once every three years) to delivering new features every three weeks, with multiple bug fixes and patches being deployed daily. Many of the lessons learnt echo our experiences with DevOps transformations at our clients.  

Our experiences with DevOps have led us to identify the following key success factors:

1. DevOps should not be treated like a checklist of activities that needs to be worked through. It needs to be central to an organisation’s approach to solutions design. It should drive all design work and follow a continuous improvement ethos that sits at the heart of how the organisation delivers solutions, one function at a time. In many situations, we have witnessed DevOps being treated as just another governance model. In these situations, DevOps rarely delivers the value expected.  
2. The freedom and agility of DevOps is best delivered with a simple governance framework that everyoneadheres to, with clear ownership and accountability present throughout the DevOps process. Everyone needs to understand their role and the role of all the other software engineers (including third party software engineers).
3. Co-location (from a time zone perspective) of all software engineers on a particular feature team is essential. This includes third party engineers from software vendors that are involved in the feature. In our experience, presence is key. You are either actively engaged on the team or you are not. When using DevOps, it is therefore very important to ensure that all software engineers (including third party software vendor engineers) on each function team remain accountable for making themselves available in an agreed time zone for the duration of the function team’s existence.
4. In our experience, complete involvement in the features design process is a key determinant of success, so all software deploy engineers should be deployed in a reasonable way. Overloading key resources is unlikely to produce optimal results.
5. Driving development by feature makes a lot of sense as it ensures that both software developers and quality assurance (QA) people are resident in the same feature team. But this only produces optimal results if you have a commonly agreed and understood enterprise architecture that is up to date and relevant to all feature teams (a common hymn sheet).
6. Like Abel and his team at Microsoft, we have found that three-week sprints deliver the best results, but only when enabled and supported by key metrics such as an engineering scorecard. As Abel points out, these score cards should not be used to reward or punish software engineers, but rather be used as a continuous improvement tool. We have found that this approach, coupled with ensuring that software engineers remain accountable for all the bugs they create, produces the best results.
7. In our interactions with clients relating to DevOps transformation we have found that many of the challenges can be directly attributed to the fact that accountability is not obvious and uniform across the client’s organisation. As a result, these clients tend to work in dysfunctional silos with a significant gap between development and QA.

It has become very apparent to us that when undertaking a DevOps transformation, everyone working in DevOps must have a common understanding and appreciation for what DevOps is and what value is expected from the DevOps transformation.

If this is not clearly articulated up front the DevOps teams tend to go through the motions dictated by the DevOps governance process (the interpretation of which differs to some degree amongst teams) without fully appreciating why the things being measured are important and how they can and should be used to continually improve the DevOps process.

A good way to address this would be to have an onboarding process for all developers and QA people that clearly articulates the value of DevOps to the organisation and which gets everyone to sign up to a formally managed DevOps continuous improvement process. The next important step is to walk the talk by having a very active management process that holds everyone accountable to what they have signed up to.

WiRD invites you to explore Microsoft’s blog (148) Enterprise DevOps Transformation – YouTube) and to share your experiences with DevOps with our community comment on our LinkedIn or on our Blog.

We believe that DevOps, well deployed, will remain a key factor in software engineering success for a long time to come and are very excited about the promise that DevOps holds when deployed correctly.