DevOps is not a standard. It is more a philosophy described by a loose set of concepts and tools, many rooted in the agile methodology and continuous delivery. That often causes confusion about the potential scope of DevOps, and makes it difficult to determine a definitive start and end point for a DevOps initiative. Moreover, DevOps requires significant cultural and organizational change, which can be hard to achieve and sustain.
So now we know what DevOps is, here we propose eight steps to a sustainable DevOps transformation, based on the use of a modified version of the Kotter change framework (1):
“Deliver it faster and less expensively”. The two most common requests from the business—whether it is to deliver digital transformation, find more agile and cost-effective alternatives to internal IT, or other requirements.
IT organizations must become fully aware of the urgency to change in order to stay relevant for the business.
In the context of dev/ops this urgency is measured by release velocity, turnaround time for new features and other metrics. Benchmarking helps here: comparing delivery time results with other equivalent companies using DevOps tools, for example. Any deficiencies can be brought up through a value stream analysis with a TIMWOOD waste analysis.
For successful DevOps transformation, identify a team which is both supportive of the change and able to communicate progress. Include senior IT management from operations and development, plus key stakeholders in DevOps processes.
The DevOps vision for continuous delivery should be aligned with the business vision. It should be broad enough to cover all aspects of DevOps, but sufficiently narrow to guide decisions in the subsequent change process.
Gartner use the term “boundary objects” to denote things that can be “interpreted differently across different communities, but that posses enough common understanding to make them useful mechanisms to communicate with and improve knowledge”.[1] Boundary objects are thus considered a possible way to align on major concepts; the objects are flexible to local requirements, yet robust enough to maintain a common identity across sites. A DevOps/continuous deployment roadmap is also a necessity, encapsulating important themes and their priorities on an approximate timeline. Avoid detailed project plans, on the basis that DevOps should follow an agile approach and is all about continuous improvement.
Should the whole organization adopt DevOps or should DevOps remain limited to those areas in which the need for agility ultimately beats strong process compliance needs, risk mitigation and availability requirements?
There is no definite answer to this, but keep in mind:
- DevOps is a lot about culture. In the long-term it will be difficult to maintain a single organization, built upon two different cultures.
- IT systems are often inter-dependent; simple changes have to be implemented across an array of systems.
Communicate the vision, strategy and roadmap again and again. Moreover, start to live the cultural values of continuous delivery, such as avoiding blame, putting individuals before the process and promoting transparency.
Many aspects of the vision—such as reduced process complexity and a revised understanding of collaboration—should already diffuse into the company culture even if “full” DevOps is not in place yet.
The guiding coalition needs to remove obstacles (such as too many process steps or approvals and rigid system access rights). These potentially limit the ability to experiment with new tools or methods. Indeed, any systems or structures that seriously undermine the vision should be replaced. Likewise, risk taking and nontraditional ideas, activities, and actions should be encouraged.
For successful DevOps deployment and transformation it’s important to deliver visible performance improvements, preferably a couple of pilot projects using established DevOps teams.
When choosing the pilot team, ensure:
- The team can be trusted to manage continuous delivery
- The application is a good fit in terms of architecture and technology
- The DevOps benefits are apparent to the business
Use the credibility derived from successful pilots to change systems, structures and policies that don’t fit the continuous delivery vision.
Have the different teams implement their own “flavors” of DevOps, best suited to their specific environment.
These teams can leverage the experience, processes and tools developed through the pilot, but are not required to do so as long as their implementation fits into the overall continuous delivery vision.
Avoid governance frameworks, which run contrary to the concept of agile.
Articulate the connections between the new behaviors and corporate success with continuous delivery. To do this, you need the right metrics in place, linked to top-level KPIs. At this stage the entire business system has to be adopted to the new culture so that the change becomes part of “business as usual”.
This “institutionalization” also needs to be supported by metrics, incentive schemes and the appropriate style of management.
(1) John P. Kotter, The Heart of Change, 2002
[1] Gartner, How to Scale DevOps Beyond the Pilot Stage, Cameron Haight, 11 March 2015, https://www.gartner.com/doc/3003922/scale-devops-pilot-stage
