A take on self-replicating characteristics that corrupts DevOps
Corruption is defined in simple terms as a deviation from the original or the correct. It originates primarily through abusing power for personal gain. Translate this in DevOps terms, the original objective of DevOps is defined, in one way, to support building a culture while unlocking the potential of teams through collaboration and harnessing relationships to achieve successful business outcomes.
Having understood the objective of DevOps in simple terms, let’s take a plunge into the key characteristics to outline the patterns of how they can become corrupted. The choice of paths to embrace DevOps are beyond any specific technology, tool or practice, but if the path does not deviate from the original intent, then the chosen path is healthy. The DevOps values to achieve the outlined objectives are defined in CALMS: culture-automation-lean-measure-sharing. The future is all about trust and integrity. The models of building trust begin with transparency, communication & inclusion.
Team Structures, creating organization characteristics that might corrupt DevOps
We often come across terminology describing the development team and the operations team. Then there is the discussion about the DevOps team, but what is a DevOps team? What is the purpose this team will serve? Let’s revisit the values of DevOps as having shared goals for the organization. It must be understood by each individual how their role, and the role of each team member, contribute to the business outcomes, without creating new silos through lateral, horizontal or hierarchical barriers. The need is to develop goal-oriented, cross-functional contributions.
The desired outcome is to bridge the gap through an open-minded approach by understanding the challenge in building teams that collaborate better. Upskilling individuals, teams & leaders on soft skills, and ensuring business leaders are introduced to technology, so no one loses sight of how changing technology can become an enabler. In addition, we need to establish opportunities for teams & individuals to write business cases which naturally bring alignment across the various functions.
Technology practices: creating technical characteristics that might corrupt DevOps
We have numerous tools and applications available today which support adoption of the DevOps values. An often-heard quote; “my favorite tool is a hammer because it is light-weight, easy to carry, and it has multiple uses.” This hammer could also be fit for building technical characteristics that lead to automating a self-replicating failure in the name of DevOps. Without mapping the value stream and understanding the critical flow, un-coordinated efforts that leave functional units to resolve their own DevOps maturity level, without focused upskilling on complementary tooling, is bound to fail. Technology itself is not solving any problem by itself. The core of resolving the problem is in the understanding of the key blockers in the flow.
Looking at technology practices it is important to consider Lean practices to eliminate waste & add efficiencies through automation. This is how we model integrity in systems while becoming more transparent and achieving the objectives of DevOps.
Process Framework: creating processes that might cascade DevOps failure
Enough has been written about ITIL versus DevOps ways of working & process alignment. We will try to investigate the next steps of process improvement in the context of DevOps. In times where “DevOps as a service” concept is on the rise, let’s take a dive into the primary need for such a service? What value does it offer? How does it improve the overall flow? Again, we look back into the values of DevOps and find one key element is lean; basically, how we understand at each step, what the value is & seek to improve the flow. Basically, the offering of “DevOps as a service”, is geared toward the fact that the team focuses on the high-value tasks.
In order to avoid death by overproduction, and efficiencies that plug and play “DevOps services” can bring, we must plan for solutions that are fit for purpose, as well as the maturity level of the organization, to avoid “anti-pattern”. It is important to consider the concept of overproduction, inventory handling & context switching. To relate it to the software development world, the process that does not reduce waste due to over-production, producing too much which no one can consume or creates no value, it does not matter if we are faster than light to produce those features, it is an “anti-pattern” for DevOps. Inventory of features that limit our productivity by creating an overhead of managing features which no one cares about or is not useable, in any way is a waste. If we do not have a mechanism where we communicate how improvements have helped achieve a business outcome, the cultivation of best practices will never gain momentum. The result of process improvements should be measurable & 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.
In our next article from the editorial desk of Capital Carbon Consulting in the DevOps series, we will investigate the operative structures & alignment with lean, agile & DevOps. These come in many shapes and sizes so let’s discuss it in our next article.