Corruption is defined as a deviation from the original or the correct. To translate to DevOps terms, it is important to understand the original objective of DevOps. DevOps means to support building a culture that unlocks the potential of teams through collaboration and communication to achieve successful business outcomes. In turn, corruption within DevOps can be the self-replicating characteristic that corrupts the initiatives of DevOps.
Having understood the objective of DevOps in simple terms, we can look at the key characteristics of DevOps and how they can become corrupted. The paths to embracing DevOps are beyond any specific technology, tool or practice, so it is important to stick to the original intent to avoid corruption. The DevOps values used to achieve these outlined objectives are defined in CALMS: culture, automation, lean, measure, and sharing. The future of DevOps is all about trust and integrity. The models of building trust begin with transparency, communication, and inclusion.
Team Structures: avoiding organizational characteristics that might corrupt DevOps
We often come across terminology describing the development team and the operations team. So what makes a DevOps team? The standard values of DevOps teams are sharing the goals for an organization. It is crucial that each individual understands how their role, and the role of each team member, can contribute to the business outcomes. However, for a DevOps team to be successful, you need to create a team without creating new silos through lateral, horizontal or hierarchical barriers. The need is to develop goal-oriented, cross-functional contributions.
DevOps can be used to bridge the gap through an open-minded approach by understanding the challenges in building teams that collaborate better. Upskilling individuals, teams, and leaders on soft skills are essential. If you’re wondering what soft skills your team needs, check out 4 essential soft skills every DevOps team needs.
Also, ensure business leaders are introduced to technology so no one loses sight of how changing technology can become an enabler. When losing sight of these initiatives, it is easy for your DevOps transformation to become corrupted. A disconnect between teams and individuals will only widen the gap between each team member and drives you farther away from your transformation objectives.
Technology practices: avoiding technical characteristics that might corrupt DevOps
We have numerous tools and applications available today which support the adoption of DevOps values. I love the quote, “My favorite tool is a hammer because it is light-weight, easy to carry, and it has multiple uses.” However, the hammer used for building technical characteristics can lead to automating a self-replicating failure in the name of DevOps. Without mapping the value stream and understanding the critical flow, we can develop uncoordinated efforts that leave functional units to resolve on their own. Without focusing on an upskilling complementary tool, any DevOps transformation is bound to fail. Technology itself cannot solve every problem. The key to resolving problems is understanding the key blockers within the flow.
While looking at technology practices it is important to consider how lean practices eliminate waste and add efficiencies through automation. This is how we model integrity in systems while becoming more transparent and achieving the objectives of DevOps.
Process Framework: the creation of processes that might cascade DevOps failure
Enough has been written about ITIL versus the DevOps ways of working and process alignment. But, in times where the “DevOps-as-a-service” concept is on the rise, it’s important to understand the primary need for such a service. What value does it offer? How does it improve the overall flow? Looking back into the values of DevOps and you’ll see that one key element is lean; how we understand at each step, what the value is and seek to improve the flow. Basically, the offering of “DevOps-as-a-service”, is geared toward the fact that each team focuses on high-value tasks.
In order to avoid death by overproduction, we must plan for solutions that are fit for purpose, to avoid “anti-patterns”. It is important to consider the concept of overproduction, inventory handling and context switching. To relate it to the software development world, the process that does not reduce waste due to overproduction will produce too much to which no one can consume and it creates no value.
It does not matter if we are faster than light-producing different features, it can become an “anti-pattern” for DevOps. An inventory of features that limit our productivity will create an overhead of managing features that no one cares about. If you do not have a mechanism where everyone communicates how improvements have helped achieve a business outcome, the cultivation of best practices will never gain momentum. The results of process improvements should be measurable and accounted for by overall profitability.
Lastly, to summarize, set clear goals, make it shareable, prepare your team, motivate the people to take up this journey and lead the change to avoid DevOps corruption. Each subset of a DevOps adoption is essential to a successful transformation and will ensure your organization’s adoption will avoid corruption.