0% found this document useful (0 votes)
140 views

Devops Journey Skilbook: Devops Principles Are Essential Foundations For Success

This document discusses key DevOps principles that underpin successful DevOps implementations, including CALMS (Culture, Automation, Measurement, Sharing), the Three Ways, and safety culture principles. CALMS describes the core components of DevOps - having the right culture, automating processes, measuring outcomes, and sharing knowledge. The Three Ways focus on optimizing flow, shortening feedback loops, and enabling continuous learning. Safety culture principles emphasize failing early and fast to adapt quickly and building confidence through experimentation.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
140 views

Devops Journey Skilbook: Devops Principles Are Essential Foundations For Success

This document discusses key DevOps principles that underpin successful DevOps implementations, including CALMS (Culture, Automation, Measurement, Sharing), the Three Ways, and safety culture principles. CALMS describes the core components of DevOps - having the right culture, automating processes, measuring outcomes, and sharing knowledge. The Three Ways focus on optimizing flow, shortening feedback loops, and enabling continuous learning. Safety culture principles emphasize failing early and fast to adapt quickly and building confidence through experimentation.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

May 2020

DevOps Institute
DevOps Journey SKILbook

Principles:
DevOps Principles are
Essential Foundations for Success
Core Values and Practices
that Underpin DevOps Success

By Eveline Oehrlich - DevOps Institute


with Helen Beal - DevOps Institute
and Karen Skiles - DevOps Institute

Eveline Oehrlich Helen Beal


Executive Summary
Since DevOps’ inception in 2009 when Andrew Clay
Shafer and Patrick Debois began to talk about agile system
administration, DevOps has been evolved by practitioners
around the globe into a set of principles and practices that
can be practically applied by teams across organizations
anywhere, in any industry. This report looks at the key
principles that underpin DevOps and what they mean for
the day-to-day working practices of humans everywhere.
All DevOps principles seek to optimize the flow of value
outcomes from ideation to realization and improve the
performance of an organization by focussing on customer
experience and outcomes.
CALMS
An Elevator Acronym DevOps Principle

Reflecting on experience at their first DevOps Days event in Mountain View, California,
John Willis and Damon Edwards came up with what they felt were the core components
of the DevOps movement: Culture, Automation, Measurement and Sharing (CAMS)1.
Later, Jez Humble added Lean and the acronym became widely known as CALMS and an
easy, fast way to explain to newcomers to DevOps what the movement is about. Today,
DevOps enterprise wide adoption, according to the 2020 Upskilling: Enterprise DevOps
Skills Report, is at 22%, whereas project adoption is at 42%, and an additional 22.6% are
still planning to adopt DevOps (See Figure 1). The CALMS model describes each part with
the following details.

Figure 1:
Stages of DevOps 2019 vs. 2020

Which of the following best describes


your DevOps journey within your company today?

Source: 2020 Upskilling: Enterprise


DevOps Skills Report, DevOps Institute

1
Culture is substantial to either support or resist change.
Organizations that value clarity, visibility and transparency
with humans that behave accountably and openly have a
higher sense of trust within the team. This then causes less
friction and therefore it is possible to move faster. Research
models to refer to are the Westrum Typology of Organiza-
tional Culture and Google’s Project Aristotle2. The Westrum
Typology of culture suggests that there are three types of
culture: pathological, bureaucratic and generative and sets
out how behaviours change across the three types. For
example, messengers (there bearers of bad news) are ‘shot’
(figuratively) in a pathological culture, isolated in bureaucrat-
ic cultures and trained in the target, generative culture. This
might mean that people are practiced in sharing bad news,
for example, as team members would talk about impedi-
ments in a daily stand up.

Automation of tasks, processes and even decisions


increases velocity. The DevOps movement emerged during
the open source boom and as the internet increased global
access to software innovation. A huge number of auto-
mation tools became available, only accelerating with the
advent of cloud. Automating tasks accelerates flow since it
takes activities that are completed manually and repeated
often and makes them much shorter and consistent in
operation3. Additional automation is applied on available
management data to create actionable analytics for
improvements on processes within the software delivery
process or on user behavior.

2
Lean removes waste and ultimately accelerates speed. The
lean movement originates in manufacturing in the 1950s
and focuses on the removal of waste. The goal is to improve
the steps within a series of many steps and to improve and
optimize the performance of tasks and processes along the
entire value chain. Lean practices such as Value Stream
Mapping, Kanban and the Improvement Kata are widely
used in DevOps implementations4. As the goals are not just
speed but also improved customer experience, feedback
loops across all stages are enabling agile adjustments to
features and functions. Additionally, log and management
data are used to respond to customer behaviour and deliver
competitive differentiation more quickly.

Measurements are necessary to show progress. Since


DevOps is so intent on improving organizational perfor-
mance relative to speed and quality of software being
developed and released, it is essential to measure before
and during the DevOps journey. The challenge is not the
measurement but rather what metrics are useful. A DevOps
journey needs to be supported by a set of key performance
indicators (KPIs) which need to be managed and owned by
the team. Leveraging data instead of opinions also builds
trust which is the foundational element of a DevOps culture5.

Sharing of knowledge and risks across teams to learn,


understand and adjust. While the culture of DevOps seeks
to support a setting where authority is distributed, teams and
individuals are empowered and can work autonomously. In
this setting, the key ingredient of sharing data and knowledge
is a must. The goal of sharing is simply to learn, understand
and adjust (or correct) what happened, which must be based
on factoids and data which is accessible and populated by all
team members. This allows for all team members to under-
stand and ask questions or initiate adjustments. A side effect
is that risk is shared, which avoids the blame game. Applying
analytics to gain insights into operations, which then can be
shared with the developers or others in the value chain, en-
able improvements on performance or customer experience.

3
The “Three Ways”
A Principle to Set as a Foundation for High Performance Teams

In 1984, Eliyahu Goldratt and Jeff Cox published The Goal - a novel about improvement
in manufacturing. It later inspired Gene Kim to write similar novels set in the DevOps
world, The Phoenix Project and The Unicorn Project. Clarke Ching also set one in the
agile world, Rolling Rocks Downhill. All of these works refer to ‘The Three Ways’ and the
principles that lead to improvement and highly performing organizations6.

The “First Way” determines flow. This focuses on acceler-


ating the flow of work from left (idea) to right (value real-
ization) to optimize the performance of the whole system
through the identification and removal of constraints. An ex-
ample of a constraint might be waiting for a testing team to
perform a testing phase. Making the pieces of work smaller,
bringing the testing into the team and automating it would
be a way of removing this constraint7.

The “Second Way” includes feedback. Here the focus is on


amplifying and shortening feedback loops so that decisions
and actions on what to create next or what to correct can
happen faster. Testing also provides a good example here: in
the scenario described for The First Way, testing results are
now produced much more quickly due to the smaller batch-
es of work and the automation.

The “Third Way” enables continuous experimentation and


learning. The focus here is on taking risks, learning from
failure and understanding that repetition and practice are
the prerequisites to mastery. Treating something as an
experiment means that we go into the work expecting the
activity to work as planned or not. This in turn sets us up to
not treat failure as a disaster, but as a learning opportunity.
Using the Improvement Kata instils experimentation and
learning as a habit8.

4
Safety Culture Functions as Parachute
for the High Performing Organization

In 2002, Dr. Sidney Dekker published The Field Guide to Understanding Human Error,
spawning a body of work around safety culture. The underpinning principle is that, in
high performing organizations, it’s safe to tell leadership bad news; an incident is seen as
an investment.

Fail Early to reduce time and cost to fix. DevOps cultures


take a different approach to failure than traditional cultures.
In traditional teams, failure is typically something to be
avoided at all costs which could have catastrophic effects
towards the business goals. Research shows it is cheaper
to fix a defect the earlier it is found in the software delivery
cycle (fail fast, fail early - also Shift Left9).

Fail Fast to adapt quickly for results. As with The Second


Way, having fast feedback loops to tell when something
has not worked as intended is essential. The techniques
of Minimum Viable Product (MVP) and limited blast radius
approaches are just a few example practices for failing early
and fast so we can adapt quickly.

Chaos Engineering allows experimentation to build confi-


dence. Chaos engineering started with the Chaos Monkey
from Netflix and now is a movement in itself. It is described
as the discipline of experimenting on a software system in
production in order to build confidence in the system’s ca-
pability to withstand turbulent and unexpected conditions.
It is closely related to resilience engineering and site reliabil-
ity engineering10.

5
The Andon Cord to stop and improve immediately. The
concept of the Andon cord came out of the lean work in
Japan and was a way of flagging a defect in a manufacturing
pipeline11. It’s frequently used as an analogy for good safety
culture practices in DevOps. Since anyone can pull the cord
to alert to a defect the first thing that happens is that thanks
is given for the opportunity to make an improvement.

Limited Blast Radiu to mitigate the impact. Limited blast


radius approaches seek to mitigate risk of change failure12.
An example is a canary test or deployment, named after the
small bird that was taken down mines and would be an early
indicator of a danger to the miners. In a canary test or de-
ployment, the change is made available to only a small set of
users initially until it is seen to be working as designed. Then
it is rolled out to the rest of the user population.

Continuous Everything Practices


which are Critical Towards DevOps Reality

DevOps seeks to accelerate flow and shorten and amplify feedback loops. This, along
with Agile’s incremental and small batch approaches, has led to ‘continuous’ being ap-
plied to many activities, processes and functions throughout the software delivery value
chain. The following describes the key continuous practices. (See Figure 2)

6
Figure 2:
DevOps Continuum

Source: DevOps Institute

Continuous testing enables detection of issues at every


step. Continuous Testing means to test early, test often, test
everywhere, and to automate the testing. It is a strategy of
evaluating quality at every step of the software delivery life-
cycle, not, as in traditional project driven environments, in a
testing phase separate from development and deployment.
The benefits are to find errors immediately before they pro-
liferate to the next step. Example vendors in this space are
IBM, Sauce Labs and Tricentis.

Continuous integration to spot bugs early. This is the prin-


ciple that team members commit code at least every time
they commit changes to version control. Once the code is
committed, several tests such as unit, integration and user
acceptance tests are run. This makes it easy to spot bugs
and immediately fix them. Example vendors in this space
are Bamboo, Codeship, Harness, Jenkins, Travis CI. 7
Continuous delivery to have builds available at any time.
Continuous delivery means that software is always ready to
be released but is not released until a team chooses to de-
liver the software into production. The purpose is to have
a quality and stable code base which is always ready to be
released. This enables for immediate feedback to changes or
features from users. Example vendors for continuous delivery
are Codeship, GitLab, XebiaLabs13.

Continuous deployment automates the immediate access


for customers. This is the last step in the release pipeline
where the emitted build in the previous step (which sits in
pre-production) is automatically made available to custom-
ers. The purpose is to automate this step so that code is
deployed to production, tested for correctness, and automat-
ically reverted when there is a problem or accepted when all
is correct. Example vendors in this space are Broadcom (CA),
CloudBees, Flexagon, IBM Urbancode, Micro Focus, Micro-
soft, VMware, XebiaLabs14.

Continuous Application Performance Management to un-


derstand the application health and usage. Continuous
Application Performance Management (CAPM) is the con-
tinuous identification of issues around performance and
availability of software applications. It strives to proactively
detect and diagnose application performance problems and
enables a situational awareness of application related issues.
Example vendors in this space are BMC, Cisco, Dynatrace,
New Relic, Splunk, IBM, Micro Focus14.

8
Continuous funding to support ongoing product development.
Continuous funding is supporting the concept of Agile and
thinking in terms of products instead of projects. Instead of
funding large pieces of work as projects, continuous funding
provides the ability to fund product teams and their needed
capacity at the time when funds are needed. Practices such as
MVP shifts teams away from big projects to getting things out
quickly in sprints. This supports delivering what the business
needs up front and continuously funds at incremental levels for
continuous improvements. Example vendors in this space are
Apptio, BMC, Cherwell, CloudHealth, ServiceNow.

What This Means


DevOps Is A Way An Organization Discovers Its Greatness

The concept of learning organizations is traced back to Peter Senge’s work, The Fifth 
Discipline. In their audiobook, Beyond the Phoenix Project, Gene Kim and John Willis
concluded that high performing organisations that harness the DevOps principles and
practices discussed above can be described as dynamic learning organizations. A learn-
ing organization has a culture where people continually expand their capacity to create
the results they truly desire, where new and expansive patterns of thinking are nurtured,
where collective aspiration is set free and where people are continually learning to see
the whole together. To shift towards a learning organization, there are two critical suc-
cess factors.

Learning requires flexibility and adaptability of your DevOps


humans. In today’s digital transformation and disruption where
rapid change is essential to sustain competitive advantage, or-
ganizations must be flexible and adaptive. That is only possible
if the members of the organization are flexible and adaptive.
Flexibility and adaptability, which includes adapting easily to
change, remaining flexible and open to change, was the third
highest rated DevOps human must-have skills (70%) in our
2020 research.

9
Learning requires a growth mindset in your DevOps humans.
All people have the capacity to learn, but the structures in
which they must function are often not conducive to reflection
and engagement. People may lack the tools and guiding ideas
to make sense of the situations they face. Organizations that
are continually expanding their capacity to create their future
require a fundamental shift towards a growth mindset15.

References
1 https://futroninc.com/2015/06/keep-c-a-l-m-s-and-be-agile/
2 https://cloud.google.com/solutions/devops/devops-culture-westrum-organizational-culture
3 https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations-ebook/dp/
B01M9ASFQ3
4 https://www.amazon.com/Lean-Field-Guide-Roadmap-Transformation/dp/1498730388/ref=sr_1_1?key
words=mike+orzen&qid=1585829735&sr=8-1
5 https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations-ebook/dp/B07B
9F83WM/
6 https://itrevolution.com/the-three-ways-principles-underpinning-devops/
7 https://www.leanproduction.com/theory-of-constraints.html
8 https://www.lean.org/Workshops/WorkshopDescription.cfm?WorkshopId=68
9 https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_
Software_Development_Life_Cycle_SDLC/figures?lo=1
10 https://landing.google.com/sre/
11 https://en.wikipedia.org/wiki/Andon_(manufacturing)
12 https://www.ibm.com/garage/method/practices/manage/practice_limited_blast_radius/
13 https://xebialabs.com/the-ultimate-devops-tool-chest/the-ultimate-list-of-deployment/
14 http://researchinaction.de/wp-content/uploads/2020/01/RIA-VSM-ARO-2020-WWW.pdf
15 https://en.wikipedia.org/wiki/Carol_Dweck
About the Authors

Eveline Oehrlich is the Chief Research Director at DevOps Institute. She conducts re-
search on topics focusing on DevOps as well as Business and IT Automation. She held
the position of VP and Research Director at Forrester Research, where she led and con-
ducted research around a variety of topics including DevOps, Digital Operational Ex-
cellence, IT and Enterprise Service Management, Cognitive Intelligence and Application
Performance Management for 13 years. She has advised leaders and teams across small
and large enterprises in the world on challenges and possible changes to people, process
and technology. She is the author of many research papers and thought leadership pieces
and a well-known presenter and speaker within the IT industry. Eveline has more than 25
years of experience in IT.

Helen Beal is Chief Ambassador at DevOps Institute and a DevOps coach, writer and
learning facilitator.

About DevOps Institute

DevOps Institute is dedicated to advancing the human elements of DevOps success. As a


global member-based association, DevOps Institute is the go-to learning hub connecting
IT practitioners, education partners, consultants, talent acquisition and business execu-
tives to help pave the way to support digital transformation and the New IT.

We help advance careers and support emerging practices within the DevOps community
based on a human centered SKIL Framework, consisting of Skills, Knowledge, Ideas, and
Learning. All our work, including accreditations, research, events, and continuous learning
programs – is focused on providing the “human know-how” to modernize IT and make
DevOps succeed.

Address and Other Details

Please contact
[email protected]
for questions about this report.

You might also like