Author : Balaji T
A transformation works only when it is treated like a transformation & not just as an information. Too many organizations fail to adopt DevOps because their leaders do not manage the transformation with the focus & effort it needs. They fall into common anti-patterns of adoption.
Some key anti-patterns are listed here:
1. The DevOps “project” – There is no such thing as a DevOps project. Adopting DevOps is not something that is done once & then done with. Adopting DevOps is a transformation that needs to impact everything – processes, automation with tools, platforms, & culture & this impact needs to be ongoing so that the end result is a culture of continuous improvement.
2. Lack of ownership – While the executives may own the DevOps transformation itself, having a clear ownership of the individual transformation capabilities, across processes, tools, platforms, and culture, is essential. This ownership must occur all the way down to the grassroots level. You cannot bring about change without clear ownership & responsibility of who is responsible for changing what, with what resources, & by when. You do not transform by edict.
3. A wrong focus on just metrics – A DevOps transformation requires, as a prerequisite, the identification of the right metrics to focus on improving. However, an overly focused emphasis on rewarding improved metrics can be harmful. If people are measured & rewarded to improve a certain set of metrics & there is no focus on learning, then if & when metrics are not improving, the teams begin to “game” the metrics. This results in a toxic culture.
4. DevOps adoption in islands – DevOps adoption starts with pilot projects. However, the goal of the pilot projects is to learn & replicate successful practices & lessons learned in other projects. A common anti-pattern occurs when executives keep this replication isolated to their domain – their own unit, division, or program. If their domain is self-contained & does not interact with the rest of the organization, such an adoption will fail to show desired results. It will certainly not transform the organization as a whole. In my Agile Mentorship Program (AMP), I teach my mentees on the section “Play:Starting with Pilot Projects“, I will also teach the value of selecting the right pilot projects & leveraging the lessons learned from each pilot project.
5. Change of organization reporting structures – The “squad & tribe” team model results in the creation of cross-functional teams & teams that are small but that can scale to larger structures as tribes. There are, however, many common anti-patterns that lead to incorrect organizational restructuring for DevOps: in the name of New leadership roles, New Silos & DevOps teams (not a true cross-functional squad)
- New leadership roles –Naming someone VP of DevOps, & having the Dev and Ops teams report to him/her, solves very few problems. Decision making, conflict resolution, budget allocation, & some communication may become easier, but you still have two siloed organizations that did not change & that are no closer to having better communication, collaboration, & trust.
- New silos – The other approach to reorganization that does not work is the creation of new silos. Many organizations redistribute their stakeholders into new reporting structures that do not foster cross-functional collaboration across the required functions but are limited to stakeholders included in the new teams. This only results in old silos being replaced by new ones.
- DevOps teams – There has been a lot of debate on the strengths & weaknesses of creating DevOps teams. These DevOps teams typically only have Dev & Ops practitioners. This does not add sufficient value because other practitioners are left out. It is not a true cross-functional squad. Furthermore, several organizations make this DevOps team a required stakeholder to every project. That ends up making it no more than another bureaucratic team that now has to approve actions by projects.
6. Outsourcing DevOps adoption – While consultants, experts, vendors, & contractors are all usually essential to help bring the process, tools, platform, & cultural transformation expertise into an organization, the ownership of the DevOps transformation cannot be outsourced. If the team does not see their own executives taking ownership & leading the transformation, the willingness & urgency to change will not be driven across the entire organization. Cultural inertia cannot be overcome by an outside consultant or by reading this article !
7. Communication & Collaboration – There needs to be true, direct communication & collaboration between stakeholders. Can they really do so, or do they always need to go through their respective reporting chains to communicate ? Is collaboration done solely through tickets ? Are there chargeback requirements that stifle stakeholders working across organizational boundaries ? Does a request to a supplier always trigger a formal change-request process ?
8. Contracts – This becomes a challenge with external vendors & suppliers. If there are rigid contracts in place that require vendors & suppliers to only communicate in a certain manner or that require that every change in the way a process is executed go through a formal change process of the contract, there can be no DevOps.
Addressing these anti-patterns is the responsibility of the executives leading the transformation. This can result in some tough decisions & aggressive changes. New collaboration tools may need to be deployed. Management will need to give up control to allow free communication & collaboration. Collaboration across functional silos that is limited to communicating through tickets alone will need to be eliminated altogether. Self-service catalogs of critical IT services will need to be made available to practitioners. Contracts will need to be renegotiated. Vendors may need to be changed if need be.