Principles of DevOps: Establish and sustaining high performance

For many enterprises embarking on a DevOps transformation, the journey can be daunting. Where do you start? What early wins can you achieve to gain much needed early momentum? Defining the mission, objectives or even the framework for a DevOps transformation is easier said than done. In this blog post, I will delve into the underlying principles of DevOps and discuss how embedding them in the DNA of the organizational culture is the first step to establishing and sustaining high performance.

The CAMS acronym—Culture, Automation, Measurement, Sharing—was coined by Gene Kim and it embodies the key principles of DevOps. It can be envisioned as a pyramid with each layer acting as the foundation for the next. Without the subsequent layer, the full benefits at each level cannot be achieved.¹

Culture
The backbone to any organization is its culture. Culture is enduring and pervasive, drives the beliefs and behaviors of its employees; in other words, it can be considered the “way of life” of an organization. There’s been decades of research into organizational culture but for DevOps, we can focus on these key components:²

• Learn to trust
• Understand motivations
• Eliminate blame
• Embrace smart failure
• Focus on bottlenecks and flow
• Eliminate unplanned work
• Be continuous
• Form dedicated, cross-functional teams
• Love transparency
• Build autonomy, mastery and purpose

In another blog post, I will delve deeper into each of these elements. For now the key point is it that culture is the underlying foundation on which a high a performing organization is built. Changing culture is the most difficult and challenging endeavor—it differentiates good and poor leadership and it has to be driven from the top down and incentivized.

Learning to trust is another key attribute for any organization even though its meaning is shallowly understood. Patrick Lencioni explains in “The Five Dysfunctions of a Team” that trust is the ability of an organization, team, individual to lay bare their vulnerabilities and expose themselves without fear of consequence and retribution. Why? It is simple, but doing so lays the ground work for open constructive conversation, to discuss the real matters at hand. Without trust we are a closed book simply hiding under a veil, concealing the real important issues of the organization.

Automation
Automation is synonymous with DevOps, but to be absolutely clear, just because a process is automated does NOT mean you are practicing DevOps. In fact, if done for the wrong reasons, automation can be an anti-pattern that adds to technical debt. I’ll give a prime example. On most projects there is considerable focus on deployment automation. Before a package is even deployed to a development (or any) environment, there has to be confidence in the quality of the software provided by a test-driven methodology and comprehensive unit testing. Deployment automation without considering the precursor steps in the release pipeline will result in the deployment of software that is unqualified and potentially fragile. The anti-pattern in this example is that we are breaking the rule of “break early and fast.” In fact, the problem has been deferred (to the right), whereas it should never have been considered a candidate for deployment.

Automation is the means to an end. The end is about delivering measurable business value to the organization and should be rooted in the elements of the DevOps culture. I recommend fostering a culture where you “focus on bottlenecks and flow.” Essentially this means applying the theory of constraints and systems thinking. When devising an automation system, design the automation to support the end-to-end lifecycle that spans across functions. A single function automation (like the example above) is a local optimization and the constraint simply moves elsewhere with minimal improvement in the overall flow of the system.

Measurement
“If you can’t measure it, you can’t improve it.” – Peter Drucker

I am often asked what KPIs and metrics should be captured to measure “DevOps success” or asked to review a set of suggested KPIs. The key to good metrics is that they must indicate a business problem or a behavior that is desirable or undesirable. It could also be a leading indicator, meaning it may not have a direct relationship but rather a co-relation. On too many occasions, one dimensional KPIs are proposed with very little relevance to answering a business question. To give an example, the metric “build failure over a period of time,” could be used as an indicator of code quality, but it is limited. A better metric is the ratio of build failure / unit test code coverage. One would expect that as code coverage increases, build failure due to unit test failures will increase, at least initially. The results of the metrics will test the hypothesis, and if test coverage does increase with no effect on build failure, then one can question the quality of the unit test coverage. This is a prime example of a leading indicator. In general, best practices for KPIs are:

• KPIs or performance ratios should never be viewed in isolation and should be reviewed in the context of other KPIs.
• KPIs for DevOps should measure performance across departments or functions.
• Define the business question first before defining the KPI.

Sharing
As with all good practices, sharing closes feedback loop from all levels of the organizations. It is no coincidence that high-performing organizations have a strong element of continuous learning and improvement. Organization that foster a culture of continual experimentation and learning must first develop the cultural building blocks that empower individuals so they are confident in taking risks that are typically outside of their comfort zone without the fear of retribution.

More accurately, sharing is about establishing a culture of knowledge sharing: How knowledge is captured, disseminated and propagated. Is it shared collaboratively or is the intellectual property maintained by individuals or within teams? Knowledge sharing and the sociability of an organization has a direct relationship to productivity and labor costs (Jarvenpaa & Staples, 2000).

In conclusion
This short blog is simply a start to understanding the key principles of DevOps. The key point is that applying the principles of CAMS, systems thinking and Lean, as well as creating and establishing the cultural building blocks that encourage the correct behaviors, lay the foundation for a sustainable DevOps moment. Sustainability is key. Too many “dish of the day” methodologies come and go, failing to deliver promised value simply because they are mandated by leadership without understanding how they are embedded into the fabric of “how things are done here”—the culture.

¹Source: http://itrevolution.com/devops-culture-part-1/
²Source: http://devops.com/2014/12/05/10-top-tips-devops-cultural-change/