DNA of DevOps Corruption

Apr 10, 2019

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.

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.

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.

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.