THANK YOU FOR SUBSCRIBING
Tools are a necessary but not sufficient condition for the success of any Continuous Delivery strategy. As in the early days of industrialisation, the political reaction of companies and workers to the introduction oftools can either help or hinder the change process. Automation of build and deployment pipelines using DevOps tooling will implicitly change some of the roles and responsibilities of software engineers and testers. It requires a change in skills sets and culture as well as potentially making some roles or even departments redundant. There is likely to be passive or even active resistance to the process of change by employees. In addition, any real or perceived change to the image, influence, or scope of control of existing organisational structures may cause such structures toput up barriers making it difficult to gain momentum or, at worst, to block change altogether.
Kurt Lewin suggested that organisations go through three stages of change – unfreezing, change (or transition) and refreezing. In the unfreezing phase, he suggested anticipating the reactions of organisations to the potential change using Force Field Analysis. He recommended developing tactics and actions to enhance the positive forces for change and reduce the power of the negative forces in the transition phase.
Figure 1 gives examples of some of the forces which were encountered when implementing a Continuous Delivery strategy in some recent projects. The positive forces for change included executive support, the drive for faster delivery of features and early indications of support from the development teams. The negative forces were mainly cultural issues such as reluctance from some teams to adopt new tooling along with the perceived loss of power by some stakeholders.
To address these forces, it was important to know what power DevOps and other stakeholders had in the process for change (see figure 2). DevOps were a new team who had low influence and power within the organisation however they were working with development teams whowere enthusiastic to collaborate (evangelists). To strengthen the positive forces, the DevOps team agreed a strategy based on “Adoption by attraction” and “Build it, Own it, Run it”.
The DevOps team initially worked very closely with the architecture and development teams to review the product architecture and identify opportunities for componentisation. They then worked with the development team to develop build and deployment processes using “pipeline as code” held in standard source control. These common pipelines were built using an inner source framework which allowed contributions from other development teams.The pipelines were easy to understand and copy which enabled formal handover to development teams for the“Build it, Own it, Run it” objective.
Development teams were so enthusiastic that they “sold” the value through normal daily interactions with other teams (gossip). An internal social media channel facilitated faster resolution times to queries from development teams. This built momentum in the adoption of the tools and enabled internal self-help taking the load off the central service teams supporting the toolset. It also provided feedback to the central teams on future requirements. Showing the “art of the possible” by delivering components as independently deployable immutable modules was vital in developing confidence in this approach and increasing the positive forces for change. This was highly successful and resulted in other development teams being eager to join this journey. This built momentum and belief outside the DevOps team and proved successful in increasing the speed of deployments to all development environments.
To propagate this model to production, however, required the support of the operations teams who owned those environments. Here there were strong negative forces resisting changeas they had separate processes for deployments to production. Initially, DevOps worked with these teams to try to persuade them to adopt the new model however, it became apparent that these teams had detractors with high power and low belief (figure 2) who were blocking change. A change of strategy was required because this could only be resolved by someone with higher power and influence. Fortunately, there was a major restructuring by executives (enabler) which resulted in the responsibility for all deployments for production being transferred to the DevOps team. “If you cannot change the person, change the person!”Over time, this enabled the common pipelines to deliver immutable containers to all environments from development to production. All this was achieved with fewer total resources than required in the two separate teams.
Even though this new transition is now in the “refreezing” phase, there is still more change required which will require a new force field analysis. For example, new pipelines require additional testing earlier in the process (“shifting left”). This means scrum teams and product owners will have to be persuaded to do this extra work which could be perceived as reducing their perceived velocity for new function. At the same time, the test organisation may feel its future is threatened in the long term. On a larger scale, moving to fully managed services in the cloud can make a large part of the internal Data Centre operating procedures redundant including those departments responsible creating more potential resistance to change.
In summary, anticipating reactions of organisation and planning for change using force field analysis can significantly improve the adoption of DevOps.The benefits are significant however it is vital to address the political forces for and against change.