DevOps Magazine by Quint Wellington Redwood

DevOps Magazine
DevOps Agile Skills
Association
Empowering IT
Transformational
Change
Seven
Key Factors
to be successful
with DevOps
DevOps begins
with Leadership
DEVOPS:
INNOVATE
OR DIE
The Real
Value of
DevOps
Four DevOps
Journeys to Agility &
Continuity in Your
Organization
The IMPACT of
DevOps on ITIL
DEVOPS OPENS THE DOOR
TO A NEW FUTURE DevOps Magazine FOR 1 IT

contents
08
DevOps: Innovate or Die
Column by Dragana Mijatovic
04
Culture, Attitidue
& Behavior
The Real Value of DevOps
Software will save your business...
06
DevOps researchers see the development of a common
culture between Dev and Ops people as the vital
element of sustained success.
Seven Key Factors to be successful
with DevOps
Meeting the demand for fast and flexible IT
10
23
DevOps begins with Leadership
Qualities of a DevOps Team
Four DevOps Journeys to Agility &
Continuity in Your Organization
DevOps provides the platform for survival
The Impact of DevOps on
Your ITIL Implementation
ITIL is still relevant in today’s Agile world
DevOps Agile Skills Association-
Empowering IT Transformational Change
16
18
26
32
The step to
Lean IT
Through value-stream optimization (Lean IT) new possibilities
are cre ated for shortening processes. We have
called this journey Lean IT (‘handing over the keys to the
kingdom’) because it optimizes the Lean IT value stream.
06
About
Quint Wellington Redwood
36
The Real Value
Of DevOps
2

14
Success factor 6:
In DevOps everyone
is responsible for quality
27
DevOps opens the
door to a different
future for IT
ITIL is still relevant in
today’s Agile world
09
12 07
Success Factor 4:
Demonstrating Lean
Leadership behavior
Elements
Of DevOps
DevOps Magazine
3

DevOps:
Innovate
or Die
Innovate or die. You’ve probably heard some
version of this phrase your entire career. I’d like
to assure you that it's ok to stop and catch your
breath, but let me tell you this short anecdote
that illustrates on why you simply cannot sit still
in the long term. In 2008, when President Barack
Obama was about to take office he quipped that
he had to “ditch his Blackberry” for security reasons.
He fought a pitched battle with the Secret
Service and was able to keep his phone in the
end. Just two presidential terms later, the brand
loyal Obama is on his way out, and his current
phone is not a Blackberry. Other brands have
since blown past the once-dominant Canadian
phone manufacturer.
So what?
In 1997, 70% of CEO’s said of the Internet: “Sure,
I know it. It’s a nice development but I don’t really
see how this is going to affect our business.”
The lesson is clear: count on nothing, keep your
eyes open and stay nimble. It is certain that at
some point in the near future you will find the
need to quickly jump in a direction you weren’t
expecting. Doing this is a state of being and a philosophy.
This is DevOps. The reason of DevOps'
conception was the need to provide continuous
delivery of value while still maintaining stability.
Organizations that apply a DevOps mindset are
faster, more efficient and have far fewer issues
than companies that do not. That’s a fact.
By Dragana Mijatovic
Global Lead
High Performance Transformation
Quint Wellington Redwood
Who uses DevOps? A former DVD rental service
turned internet streaming giant called Netflix, a
former student bulletin board called Facebook, a
former bookstore called Amazon, and a search
engine turned “everything” called Google. All
these superior brands are still with us today
because they continually evolved using DevOps
among other forward thinking strategies. It is a
way to ensure one eye is always kept on the
evolving needs of customers, and that you do
not get too comfortable or set in your ways.
Quint Wellington Redwood can bring this mindset
to your organization as well. The training,
implementation and instillment of organizational
change for DevOps is what we do everyday.
Are you just investigating
DevOps for the first time?
Let us show you where to begin.
4

EXPERIENCE
LEAN IT IN ACTION
We believe that “Lean Thinking”
should be an integral part of every
Enterprise IT organization
and also every IT professional’s toolkit.
IT Enterprises are finding themselves in the midst of
digital/IT Transformations. They are seeking out
ways to advance key legacy applications, while at
the same time taking advantage of the new digital
and cloud based applications that are driving
change and disruption in the IT service management
space.
Lean IT offers a proven, reliable, well-founded solution
to help organizations address those challenges.
Lean principles focus on operational excellence,
strategy, reduction of waste, and the quest for continual
service improvement. It provides IT professionals
and teams working tools and an approach
to effectively improve the quality of their processes.
Lean IT brings real value to organizations.
The Lean IT Association
Certification Program
PROFESSIONAL
PRACTITIONER
FOUNDATION
Implement,
strategize,
mobilize
Know
and apply
Know
Lean IT
Leadership
Lean IT Kaizen
Lean IT Foundation
Lean IT
Coach
Start your Lean journey today!
www.quintgroup.com/us/training/lean-it
The Lean IT Certification Scheme Supports, Four
Distinct Certifications levels. That provides training
IT professionals that are just beginning their
Lean IT journey.
DevOps Magazine
5

The Real
Value of DevOps
Today, every business is an IT business. The
world is becoming more interconnected,
automated and intelligent. Infrastructures,
assets and devices across the globe are
rapidly being digitized, made available 24/7, and
transforming everyday products into smarter
products that allow people, systems and objects
to communicate and interact with each other in
entirely new ways. Software is a key driver of
differentiation and business innovation. It is a
gateway to new services and revenue streams,
seamless customer experiences and expansion
into new markets. Software includes those programs
both visible and invisible to the end user.
In broad terms, DevOps is an approach based
on lean and agile principles in which business
owners collaborate with the IT development,
operations and quality assurance functions to
deliver services in a continuous manner, thus
enabling the business to more quickly seize
market opportunities and reduce the time to
include customer feedback into products and
services. DevOps leverages the interdependence
of IT development and operations to create
higher quality products and services. It aims to
help an organization rapidly deliver this value
sought by the customers of IT.
Software will save your business
In general, most attention goes to applications, the
software used by end customers. Software on its
own does not actually do anything. The ability to
deliver the functionality provided by the software
as part of an integral service to the customer is
the key. The service includes the software and the
human interaction that helps ensure the software
remains relevant. Software retains its relevance
only if issues are solved quickly, if it is updated
and improved to match the evolving requirements
user, and if someone provides advice about how
to use or integrate the software or enhance its
value in the business process it supports.
DevOps provides the platform for
survival
DevOps refers to an organizational philosophy
and the professional movement that advocates
communication and a collaborative way of working
between IT development and operations
resulting in a faster flow of planned work while
simultaneously increasing the reliability, stability
and resilience of the production environment.
Every business wants to move faster without
compromising the reliability, stability and security
of their systems. And these two seemingly
opposing sources of agility and reliability are now
6

possible for every organization to achieve thanks
to the maturity of DevOps practices and tools.
The State of DevOps report states that high
performing organizations are more agile. They
deploy code 30 times more frequently, and
they deploy 200 times faster than their peers.
Furthermore, high performing organizations are
also more reliable: they have 60 times fewer
failures, and they are able to restore service 168
times faster than their peers (source: Puppet
Labs 2015). From the business perspective, we
also know that strong IT performance is a true
competitive advantage. Companies with high
performing IT make more money and facilitate
happier employees who consequently, as the
research shows, tend to do better work.
Meeting the demand for fast and
flexible IT
The way in which today’s IT services are delivered
can barely be maintained because current IT
processes were not designed to meet a demand
from the business for fast and flexible IT. Due to
the typical silo-driven organizational approach,
IT processes are unnecessarily complex, performance
measurements are not transparent,
people’s attitude and behavior is focused internally,
and tools are too strongly concentrated
on individual technologies. This is diametrically
opposed to the desire of the business which
wants new functionality to be delivered fast,
incidents to be resolved quickly, and to have
short communication lines and overall higher
quality. This means there is a mismatch between
traditionally designed IT organizations and the
business. It is time for a fundamental review
of the structure of IT organizations. Changing
nothing and hoping that things will improve in
the long run closely relates to Einstein’s definition
of insanity:
“Doing the same thing over
and over again and expecting
different results.”
Elements of DevOps
The elements of DevOps can be summarized
as anything that affects the 3 main dimensions
of an IT organization:
1. People
2. Processes
3. Technology
Organization
DevOps
One of the least discussed aspects of DevOps
is the organizational dimension. This revolves
around adapting the IT organization to bring ‘Dev’
and ‘Ops’ closer together. In practice, it turns out
that people primarily work on improving the communication
between ‘Dev’ and ‘Ops’ rather than
on implementing real organizational changes.
The management model and the skills of those
managers are crucial to the success of a DevOps
team. Various approaches, such as Lean offer a
wide array of tools (e.g. Visual Management) for
efficient management and tackling problems. It
is now common for operational inventory to be
‘visually’ managed within a Dev organization.
However, managing activities via Kanban boards
(visual displays of the operational flow) is often
uncomfortable for ‘Ops’ people. Experience has
shown that this discomfort disappears relatively
quickly once implemented.
DevOps Magazine
7

Culture, Attitude and Behavior
DevOps researchers see the development of a common culture between Dev and Ops people as
the vital element of sustained success. This involves building understanding between developers
and ‘operations people’, and ensuring more collaboration between the two camps.
For the IT world, this is not an everyday approach. It is important to recognize – especially at the start
of the integration – that the behavior of developers and operations people is different. Harmonizing
these attitudes and behaviors is pivotal in making DevOps a success. Of course, creating mutual
understanding is a crucial element. By focusing on behaviors in addition to the overall culture, we
ensure that the members of a DevOps team become aware of their own role in the success of the
whole.
How managers provide guidance, in relation to the maturity of the team, and the extent of the integration
is also a decisive factor in the success of DevOps teams. DevOps promises a lot in terms of
more, faster and better releases. As a result, there is a strong trend towards focusing on making IT
performance measurable. It is important to know exactly how many hours are needed to build a use
case. Especially given that DevOps was developed to meet customer demand.
Another aspect of performance is the use of time: how is time used within the team? What is the
balance between innovation and maintenance? The outcome should be the implementation of actions
for improvement aimed at adressing this balance to facilitate innovation without compromising quality.
Processes
Thinking in terms of processes is part of IT. Many
DevOps thinkers regard development-to-production
processes as the solution to IT problems,
and refer frequently to Agile, Scrum and other
methods. Here, the integration of ITIL processes
and development processes appears to be one
of the goals.
The processes within an IT organization are
usually not clear to the staff. This is because
the process flow is comprised of a series of
departments which are all only involved in part of
the flow. Employees find it unclear as to what their
role is in the process as a whole. In a DevOps
team that works with Visual Management, it is
possible to optimize processes without involving
the departments concerned. This means that
complex manuals now make way for simple, clear
agreements. It turns out that within processes,
the key to success is the strict monitoring and
management of open units of work.
Technology & Tools
The natural reflex in the world of IT is to use
technology to resolve a problem. In itself, this
is a sound approach, especially if changes can
be deployed to production more often and more
reliably. By using integrated tooling to strictly
manage the movement of units of work through
a DTAP (Development, Testing, Acceptance
and Production) flow, release frequency can
be accelerated to a level that could never be
achieved manually.
Tooling is therefore an indispensable element
of DevOps. Within a DevOps team, a fully automated
DTAP flow is a prerequisite for guaranteeing
speed and quality. Does this mean
that a DevOps team cannot exist without this
tooling? No, the increasing automation of the
various steps through the DTAP flow is also a
growth scenario. There are also many benefits
to be gained through growth in one or more of
the previously covered elements. Each element
plays a role in a comprehensive approach based
on DevOps methodology and in realizing the
intended benefits.
8

Really putting customers first
In order to make DevOps a success, it must be
clear who the customer is and what services
customers want to have delivered. This requires
thorough analysis and clear definitions of both
‘customer’ and ‘service to be delivered’. Identifying
a customer or customer group makes it
much simpler to determine the value that should
be delivered. DevOps benefits in particular from
clear and simple definitions. At a minimum, the
following aspects must be perfectly clearly defined
for a DevOps team:
• Who is the customer?
• What service is to be delivered?
• What are the units of work the team will be
processing?
• What is the ‘definition of done’ for these
units of work?
After all, what is involved are the salary costs
of the team and the costs of the technology
stack. It becomes much simpler to determine
the value of a team given that personnel costs
represent hours of knowledge purchased.
By linking the hours to the business value of
the service provided, the costs of the team in
relation to the value delivered can be calculated
quickly.
DevOps opens the door to a
different future for IT
Taking everything into account, DevOps is a
highly desirable development with the potential
to change the world of IT dramatically. DevOps
has the potential to add more value to the
business processes of its customers. To capitalize
on this, IT managers must be prepared
to challenge their current organizational form,
even if it means their ‘empire’ becomes smaller.
Creating high-performing teams
The core strength of DevOps comes from the
psychological impact of the creation of a team that
has both the capability and the mandate to fully
serve its customers. There must be a shared goal
to be achieved by people with complementary
skills, who hold themselves mutually responsible
for achieving that goal. In this way, an opportunity
is created to establish a high-performing team that
adds significant value to the business process.
It is important to emphasize that a DevOps team is
something different to what we traditionally refer to
as a ‘team’, such as a database team. A database
team is not a team in the traditional sense of
the word due to the absence of complementary
skills. From the perspective of time saving, simplified
processes and agreements require far less
coordination because the vast majority of units of
work are dealt with within the team. This saves
an enormous amount of time compared to a
situation in which an incident is passed back and
forth between three departments, each of which
puts its own interests first.
Another advantage of DevOps is that people have
better insight into costs. Since all costs are related
to the team, it is much simpler to determine the
cost of ownership for the support of a customer
or customer group.
DevOps Magazine
9

Seven Key Factors
to be successful
with DevOps
Quint’s definition of DevOps:
DevOps is an organizational philosophy that stresses communication, collaboration and integration
between information technology (IT) software developers and IT operations professionals.
DevOps uses the interdependence of software development and IT operations to create higher
quality products and services. Its aim is to help organizations rapidly deliver the value sought by
IT customers.
DevOps promises a great deal in terms of
improvement when compared to traditional
IT organizations. However, the DevOps
philosophy needs to take root in exactly such
an environment. Typically, we see these issues
in traditional IT organizations:
• Inefficient processes, low productivity
• High and unclear costs, ballooning projects
• Weak connection with the customer
• Poor time to market and poor service quality
• Lack of scalable solutions
• Teams working in silos
The key problem is that moving to DevOps is
a leap of faith, but it is increasingly becoming
supported by success stories. And even though
the above issues are the source of complaints
both within IT and outside, IT is familiar with these
issues and only knows temporary fixes that do not
upset the status quo of the existing organization.
It therefore takes considerable pain or a very
strong ambition for existing IT leaders to actually
take steps on the road to a new style of IT; an
IT that can truly deliver on the expectations of
customers. The fact is that the pain, as described
in the issues above, is already quite significant
for many IT organizations, even though they
have essentially become immune to this pain.
We will describe seven key success factors for
overcoming the issues that exist in traditional IT
environments.
Success Factor 1: DevOps is
about creating flow
DevOps taken to its logical conclusion is an
exercise in creating flow. The Lean principle of
flow means to ensure that all work that adds
value is carried out without waiting time between
the process steps. Thus ensuring that customer
value is delivered in the shortest possible time.
DevOps teams must focus on the flow of work.
The challenge is that there are two directions of
flow. Sure, projects go from development into
production. But “done” does not just mean that
development reaches “code-complete.” DevOps
teams also need a direct feedback loop into
development. The DevOps team must create a
continuous feedback loop: in order to support
continuous delivery and integration, the team
must also put the processes in place to collect
and implement feedback, not just from IT staff
but particularly from the business user. This
means that the developers within the team will
also do their tours of duty as on call for support
issues for their particular service.
10

DevOps principles. With dedicated, regular and
consistent use of problem-solving, the team
can create a culture of continuous learning and
improvement. And only the IT organizations that
can continuously adapt and learn will survive in
today’s competitive market environment.
In one IT organization that adopted DevOps, one
of the DevOps teams was actually asked by the
customer to slow down because developments
were being released quicker than the business
team could assimilate them. This is in fact, a clear
sign that flow has been achieved; the ability to
deliver as and when the customer needs new
functionality. The ‘slow-down’ request meant
that the team could spend more time improving
their own way of working without affecting
the delivery of customer requests, thus further
enhancing their ability to deliver as and when
the customer requires (the essence of the Lean
principle of Pull).
Success Factor 2: DevOps requires
continuously uncovering problems
and tackling them
DevOps is neither a tool nor a technique. It is
an organizational and cultural change. Change
is feared throughout most organizations of any
type, so the adoption of new methodologies can
be quite challenging. Therefore, it is vital first to
define the business need that brought on the
discussion of the potential change as well as
the accompanying challenges. Nowadays, businesses
are expected to quickly deliver flawless
applications that focus on user experience, but
without the right tools, applications, and behavior,
this seemingly simple task can turn into a complicated
mess. Ultimately, faulty delivery translates
into missed business. The first step in creating a
DevOps culture is a relentless drive to uncover
and solve problems. This attitude supported by a
commonly understood and used problem-solving
methodology (e.g. DMAIC, Kepner-Tregoe, TRIZ)
is the foundation for the successful adoption of
Success Factor 3: DevOps requires
cross functional teams
As DevOps gains prominence, IT organizations
seek to take short cuts by recruiting ‘DevOps
Engineers’. The fact is that these people do not
exist and the only short cuts are learning from
IT organizations that have already taken steps.
DevOps is about growing talent internally by
creating cross-functional teams. Cross-functional
teams have multiple benefits:
1. All of the knowledge needed to support and
develop the service is in the team, reducing
dependencies on others and waiting time.
2. Team members can learn quickly from one
another
3. The flow of information is quick and the information
shared is meaningful to all
Open flow of information and open discussion
of information within the team regarding the
overall performance of the service and about
the future development of the service is vital to
the success of the team. Building multi-skilled
teams that are made up of individual talents
(e.g., developers, sysadmins, and testers) can
add great benefit, but without the right attitude
and mindset, the talent is virtually useless.
DevOps Magazine
11

When people know they can rely on everyone
else, the group as a whole also moves much
more quickly and efficiently, ultimately leading
to happier customers. The right attitude is
customer oriented (understanding what the
customer perceives as value) and taking overall
responsibility for the quality and timelines of the
services delivered. Of course, having a wide skill
set is beneficial to every aspect of the process,
as long as those individuals are willing to be
team players.
The first step in a DevOps approach involves
recognizing how development, IT operations,
and QA are mutually dependent on each other.
In its preparatory phase, DevOps relies on
cross-departmental collaboration and open
communication between the key players in the
delivery of the service in order to boost operational
efficiency, predictability, and maintainability.
The creation of a multi-disciplinary team including
all of the relevant actors is the next step.
The benefit of cross-functional teams is that
even though engineers are associated with a
specific function, it does not mean they cannot
work on other aspects. For example: quality
engineers writing software. Leverage of the
strength of each functional role is important, but
broadening the capabilities is both motivational
for the engineer and improves the robustness of
the team. It is, therefore, important to create an
environment where people are learning about
the other aspects of service delivery because
that helps in building better services.
Success Factor 4: Demonstrating
Lean Leadership behavior
This is where we come to the role of leadership.
One of the benefits advertised about DevOps
is the self-organizing character of the multi-disciplinary
teams. The automatic reaction is that
managers see straightaway a cost-saving: no
need for the team management layer! In fact,
in a DevOps environment (especially the larger
IT organizations), leadership is absolutely vital
for success. And within a self-organizing team,
there is always leadership present, maybe not
as a formal, hierarchical function, but certainly
there is strong technical and organizational leadership
within the team. This leadership is found
in behavior, rather than formal functions. This
does not mean that a DevOps team should not
have a formal team leader. The leadership role
evolves as the team matures. In either case, it
is vital that those playing the leadership role(s)
become competent in four areas:
• The ability to define the direction and goals of
the team regarding the service delivered and
the way in which it will be delivered
• Self-development, continuously seeking to
improve their ability to lead the team in the
required direction
• The ability to help others to develop, through
teaching, coaching and leading by example
• Continuous improvement, continuously seeking
out problems (both technical and organizational)
to be solved and ensuring that they get solved.
12

The toolset must support flow by covering the
entire development-to-operations lifecycle, from
infrastructure to business. It should empower the
resources to execute the work allocated to them
in an efficient manner. The first discipline and
associated tooling the DevOps team must master
is version control. Without a clear understanding
of the power of and need for version control, the
DevOps team is doomed to repeat the mistakes
made in the ‘old’ IT organization. In fact, disciplined
version control is everybody’s business
in a DevOps team, whether you are the team’s
architect, tester, developer of operations engineer.
Everyone must know which version of the software
is where in the process. Fortunately, there are
tools that support this function. However, even
the best tools are rendered useless by inadequate
processes and adherence to agreed ways of
working. Version control is a classic example of
the Lean principle of quality at the source.
Success factor 5: Build your
own DevOps toolbox
When it comes to continuous improvement,
one of the greatest challenges is the technical
excellence challenge. The ability to create
flow and to solve technical problems quickly
is completely dependent on the ability of the
team to build a set of tools that extensively
automates the software delivery pipeline from
the development environment to the production
environment. Fortunately, huge steps have been
taken in the past five years in the automation
of the steps in the software delivery process.
A DevOps tool is any tool that supports the
automation of the processes and enhances the
collaboration of team members and between
the teams. However, there is no single tool that
does it all, instead a ‘toolset’ approach needs
to be employed.
Success factor 6: In DevOps
everyone is responsible for quality
Every participant in the service delivery is responsible
for the improvement of the service the
team delivers to their customers. This means the
user experience engineer is responsible for the
quality of programming just as the developer is
responsible for the quality of tests.
Quality is not the responsibility of a single
person or an external team, it is the shared
responsibility of everyone involved in a service
delivery. This is a major shift in behavior and
mindset in many IT organizations. Interestingly,
this collective accountability for quality is one
of the key characteristics of a team: in teams,
the participants have a common goal (e.g. the
‘health’ of an IT service) and hold each other
mutually responsible for the achievement of that
goal. Quality is an integral part of the ‘health’
of an IT service.
DevOps Magazine
13

Success Factor 7: Get help on your journey towards DevOps
One of the most striking aspects of any DevOps meeting is the drive to share unconditionally.
DevOps gatherings exude a collaborative atmosphere in which everyone can learn something.
DevOps is recent and the capabilities and knowledge of how to do it are growing on a daily basis.
DevOps is about learning. If your desire to adopt DevOps principles is not accompanied with the
humble acceptance that we are all to a certain extent finding our way in a dimly lit space, then you
are probably setting yourself up for a huge disappointment.
Conferences such as DevOps Days and Enterprise DevOps Conferences provide excellent
learning opportunities on all aspects of DevOps, although the technical aspects tends to be quite
prominent. Seek out IT organizations that have experience with DevOps. Do realize that they may
only have taken the first steps on their journey, and may not yet be achieving huge benefits. These
organizations do however have lessons that they have learned regarding early phase pitfalls. In
this respect, overcoming traditional structures such as annual budgets, project portfolio boards
and centralized architecture boards.
The DevOps Integration Model
Use available guidance. The Quint DevOps Integration Model is an example of guidance in adopting
DevOps, based on both market developments and hands-on practical experience. It identifies
the steps that IT organizations need to take from a traditional siloed IT organization to a high
performance IT organization. It subdivides the development of the IT organization into five key
dimensions – Performance, Process, Automation, Organization and Behavior & Mindset. Each of
these dimensions has five aspects that need to develop as the IT organization moves towards its
DevOps goal. The most important advice is to move, take a step, do something. Doing nothing
is no longer an option.
14

Organization
Performance
Behavior &
attitude
Process
Tooling
service definition
customer definition
completeness of team
dependency on other
teams
management practices
key Performance
Indicators
technical debt
reduction
level of performance
(incidents, SRs, St Ch.)
level of performance
(creative work)
time usage (earning/
burning)
team-forming
psyhological safety
problem-solving
leadership fit
motivation
knowledge of units of
work
awareness of
processes
documentation of
processes
monitoring of progress
customer orientation
automated test
development tooling
automated deployment
to production
service management
tooling
use of other tools
DevOps Integration
low partial intial advanced full
level O level A level B level C level D level E
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
Keep moving
An effective, efficient DevOps practice requires a great degree of collaboration, open communication
and cooperation, including willingness to share risks and rewards. Many organizations have been
successful at implementing DevOps at a small scale – team level – but often discover that implementing
DevOps at enterprise scale is quite challenging. Transitioning to DevOps is, first, a cultural shift, and
then a technical, process and organizational shift. DevOps takes time and effort, requires strong
leadership and advocacy, and must be measured in a way that is compatible with the organization’s
goals. DevOps will take time. There is no point in time defined as: “we’re DevOps now”. DevOps is
about getting better every day, to keep making better products, deliver better services and to have
happier customers. And, in the course of doing so, to make everyone’s job better, easier and more fun.
DevOps Magazine
15

DevOps begins
with Leadership
DevOps can ensure that IT services are
delivered much more efficiently with the
proviso that it is properly implemented.
However, there are some stubborn problems
like a lack of good leadership and an ‘old world’
attitude among teams. Facebook, Amazon and
Spotify are shining examples of the application of
DevOps. They are all able to introduce high quality
pieces of software quickly and very frequently.
But they are the exception. There are only a small
number of IT departments that are currently using
DevOps properly. Most DevOps teams are still
encountering problems that are preventing them
from benefiting from the opportunities this method
offers. And this has a lot to do with a lack of good
team leadership.
Many IT managers cling to an entirely personal
view of the way DevOps should work. Most IT
managers don’t yet understand what DevOps
means. Many managers of departments that work
with DevOps are convinced that developers don’t
want to have anything to do with IT operations.
And of course there will also be developers
who don’t want to have anything to do with the
production, because then they cannot be held
responsible for anything. However, a manager
must convey the message that the entire team is
responsible for the service delivered to the customer.
You need to show customers that you are an
integrated whole and thus make it clear that you
are there for them. Developers in a DevOps team
must ensure that what is in production continues
to work, and they need to take responsibility for
this. The average developer really does want to
know how the system works in practice and how
it is used, but by placing everything in silos, the
management of IT departments has ensured that
developers are isolated. They are too compartmentalized.
Moreover, it is instilled in them that
they are not part of production.
Automation is taking over
The behavior of team members is far from ideal.
DevOps is focused on automating large portions of their
work. People are not very keen on having automation
take over their work. Understandably so, because they
want to keep their job. And yet, it is better to automate
the less valuable aspects of their work because what’s
left is a better job. These days, the realization of a
test environment can take a week. This can easily
be automated and then the test environment would
be ready in about two hours. However, management
pays too little attention to allowing teams to work
more efficiently.
Therefore, It is vitally important that IT managers pay
a lot of attention to the composition and culture of a
DevOps team. Once a team has been set up, it usually
doesn’t work well straightaway.
There are many different roles in the team:
developers, database administration, operations
management, architect, application
administration. What applies here is: one is
none. Take the database expert, for instance.
A team should realize that more people need to
acquire database skills. Within DevOps teams,
more overlaps of knowledge and skills need
to be created. Team members should support
one another in order to be able to do a lot
together. A team is responsible for the health
of the service. If the service has an illness, the
common goal is to cure it.
Molding a team
A DevOps team is not perfect from the outset. In
the beginning, such teams always go through a
very difficult time because almost everyone still
16

has to learn to collaborate and how to trust
one another. That doesn’t happen overnight.
Many team leaders are not properly prepared
for the job of integration management.
They are given 8 or 9 people to mold into a
high-performance team. Team leaders need
to be trained to achieve this. In addition, the
team leader must point out to the members
that they have a shared responsibility and
he/she needs to support them in this. It is
important to achieve the right balance. For
example, it is not advisable to put all your
server or database administrators together in
one team. Keep them as far apart as possible.
People will then behave much better in terms
of adhering to the architectural guidelines. If
you put them together, they feel safe in their
old way of working and they really won’t talk
to each other about improving the quality of
the service... If a single database administrator
is the only database expert in the team, he
won’t pull any stunts.
Qualities of a DevOps Team
• Dare to make mistakes. People are afraid to
make mistakes. Only one in five people sees
making a mistake as an opportunity to learn. This
prevailing attitude stifles innovation.
• Dare to take responsibility for a project’s success
or failure. Only 45 percent of IT people feel
responsible for the success or failure of a project.
• Always measure the level of customer satisfaction
with the result. Over fifty percent of IT
departments do not measure customer or user
satisfaction after delivering a service or application.
If you consistently measure satisfaction, IT staff
feel more closely tied to the business goal of the
project. This in turn leads to better collaboration,
especially where turning mistakes into improvements
is concerned.
• Use monitoring in combination with analytics.
Using monitoring combined with analytics is important
in guiding improvements. This approach
delivers a lot of data which can be used to decide
what actions should be taken. For instance, analytics
provide insight into business performance. IT
staff need to know these things in order to better
develop the related services and applications.
That awareness is, however, not widespread. Only
14 percent of IT staff see its importance.
• Ensure that data is reliable. Most IT staff quite
simply do not trust the available data, although
they need it to make decisions. Make sure you
have good analytics tools for making reliable
measurements.
• Find the leak first. More than half of the errors
in applications are found by users first. Ensure
that from now on the IT department finds errors
in applications before the users do.
• Build a good dashboard. A good dashboard
needs to provide a real-time overview. It has to
show the release times quickly, as well as all the
necessary information such as in what environment
the releases are installed and produced.
Everyone should have access to such a dashboard
and they can’t be bought off the shelf. You
have to build this dashboard yourself complete
with various tools, for example for application
release automation and application performance
management. Forty percent of IT staff have
no access to dashboards. Dashboards that are
updated in real time are extremely rare and only
10 percent of IT staff have access to them.
DevOps Magazine
17

Four DevOps
Journeys to Agility
& Continuity in Your
Organization
Right from the outset, the digital age has brought with it a great many new buzz words and
concepts that have an impact on IT. Agile, Scrum, Lean IT and DevOps, to name just four. We
are seeing that followers of the various schools of thought are often in conflict. When we more
closely examine the background of each concept and the objectives they are aimed at realizing,
three common goals can be identified: optimizing the agility of the organization by anticipating
change, reducing the time to market of new features, products and business models, and delivering
the highest possible customer value while focusing on quality at the source. Let’s first examine the
objectives of the various concepts.
Lean, which came into its own in the automotive
industry (the Toyota Way), aims to optimize the
value stream by removing as many unnecessary
actions and steps as possible. To this end, Lean
offers an extensive toolkit in which the focus is
on leadership, knowledge of the work floor and
continuous improvement.
Agile and Scrum emerged from the world of
software development. Here, the Lean mindset
is translated into responding to changed insights
regarding feasibility and customer value which
are identified by the customer and developers
during the development process and use of
new software. Process improvement and waste
reduction are the next step.
BIGGEST DIFFICULTIES IN
IMPLEMENTING DEVOPS
VALUE OF DEVOPS NOT
UNDERSTOOD OUTSIDE MY GROUP
NO COMMON MANAGEMENT
STRUCTURE BETWEEN DEV AND OPS
DON'T HAVE TOOLS IN PLACE
DON'T HAVE TIME TO
IMPLEMENT DEVOPS
DON'T HAVE SUPPORT
TO BE SUCCESSFUL
IT'S TOO EXPENSIVE
48%
43%
33%
31%
19%
5%
DevOps adds user value during the lifecycle to the above. By allowing operations to be performed
by the same team that develops the functionality, a direct feedback loop is created which enables
the team and the customer to identify priorities from the long-term perspective and to develop
software in such a way as to minimize the operations burden throughout the lifecycle of a service.
These differences in origin do not have to be a restriction; the concepts are complementary and can
be used together effectively. It is, however, useful to understand the background of each concept,
and how more customer value can be delivered when they are combined based on each one’s
own specific strength.
18

Application operations versus application development, application domain
and infrastructure domain: from the customer perspective there is a growing
need for flexible and reliable IT. It is up to you to meet the challenge of
fulfilling this need. In this regard, DevOps is a cohesive approach to four
areas: Operations, Development, Applications and Infrastructure. At first
glance, DevOps is simply the combination of Development & Operations.
However, behind this façade there lies a whole new world of thinking which
entails making optimal use of new technological opportunities, focusing on
team responsibility and integrating processes within the team. DevOps is an
organizational earthquake which can contribute significantly to the added
value delivered to customers and experienced by staff.
The 4 journeys to DevOps
In practice, what people think of DevOps is shown to be highly dependent on
the experience they have with it within their own organization. In this paper,
we use four DevOps journeys to bring together these different experiences
as pieces of a larger puzzle. Each journey describes the development of
DevOps from a particular perspective. Each of the four journeys can be
regarded as the archetype of a journey an organization can make. These
journeys serve as a frame of reference for discussions about the meaning
of organizational changes. In practice, you have probably noticed that within
the various parts of your organization people are trying to find a solution to
the increasing need for agile and reliable IT. Each part does so from its own
perspective. However, this is like trying to convey what an elephant looks like
by only describing its trunk or its tail or foot. Each part of the organization is
right, to a certain extent. The trick is to make combinations of descriptions
which provide a clear picture of an elephant. By understanding the different
perspectives, you can combine them powerfully because the underlying
goal is a common one.
Applications
2
1
4
Lean IT
Infrastructure
3
Operations
Development
DevOps Magazine
19

1
From waterfall
to DevOps
Traditionally, new systems are developed in
projects, in a waterfall process. The project
ultimately delivers the system (after months, or
sometimes years) to the operations organization,
which formally accepts the system. In practice,
however, these new systems are ‘thrown over
the wall’ and remaining points and quality issues
have to be resolved in the operations phase.
However, a trend in recent years is to develop
(or further develop) systems in short cycles using
Agile methods like Scrum. Scrum can be very
successful but in reality it turns out that actual
deployment to production is a very high hurdle:
the ‘wall’ referred to earlier is higher and more
solid than had been thought. Operations’ ground
rules are difficult to capture in the “Definition of
Done” and hard to pass on in advance to the
Scrum teams in the form of requirements or
non-functional requirements.
This DevOps journey starts when the Scrum team
takes responsibility for resolving incidents and,
as result, acquires insight into the functionality
and becomes jointly responsible for making
the functionality available in the production environment.
Taking responsibility for matters ‘on
the other side of the wall’ leads to a different
awareness of quality. The technical debt and
the number of incidents, questions from users
and operational issues will hurt; they impede –
and will continue to impede – the Scrum team
in delivering value quickly. Low quality leads
to a congested backlog. This can also be the
starting point for assigning multiple operations
tasks within the Scrum team; for example, the
team will monitor and optimize (automate) the
performance of systems. In addition, it becomes
important to the team that the technical debt is
contained and reduced. The development team
not only becomes responsible for the delivery
of working software but also for the delivery
of the entire service so that a user group can
also use this functionality optimally in its own
busi ness process.
This change is the most common
DevOps journey: the journey from
development to operations.
Applications
ASL
1
Agile/
Scrum
Lean IT
Infrastructure
ITIL
Operations
Development
ITIL
20

2
From application
management to DevOps
This journey starts from application management.
In this domain, staff members are mainly
organized in silos according to their expertise.
This means that service delivery managers,
functional application managers, technical application
managers and database managers
make up separate departments or teams. Processes
are focused on channeling the work
through the different teams. To facilitate this,
ITIL process managers and ITIL coordinators
are added to the organization as a function. To
begin with, based on shared features (including
customer features) applications are clus tered
in product lines, information domains, value
streams, etc. Key in this is to produce cohesive
work packages for identifiable customer
groups. Subsequently, the required operations
competencies are combined in multidisciplinary
operations teams. This second stage starts when
the operations teams not only focus on operating
and provisioning the contracted service, but also
feel increasingly responsible for realizing new
functionality in existing services in operation
and subsequently also actively take on the role
of owner in respect of service innovation. In
turn, within these permanent, mature operations
teams, this leads to increased awareness and
the acquisition of the competencies needed for
the teams themselves to realize innovations. As a
consequence, the management reflex to realize
every innovation in projects with ad-hoc project
teams can be overridden. The focus thus shifts
from resource allocation, which is tradition ally
one of the time-consuming processes within an
organization, to task prioritization.
Development tasks such as
designing, building and testing
can be performed within one’s
own team.
ASL
Agile/
Scrum
Applications
2
Lean IT
Infrastructure
ITIL
ITIL
Operations
Development
DevOps Magazine
21

3
From infrastructure
management to DevOps
The third DevOps journey described in this paper is relatively unknown within the domain of DevOps,
but it is essential to facilitating the journeys set out above. The starting point of this journey is the
infrastructure management domain (from running infra via changing infra to providing self-service
infra). Infrastructure as code and platform as code are terms you will hear in this regard. Making
virtual infrastructure provisioning available to the DevOps teams allows them to respond flexibly
to their changing needs for suitable infrastructure.
The flipside is that this flexibility can only be realized
if the underlying platforms and infrastructure have
been standardized and the lifecycle management
of hardware, OS, databases and middleware
has been implemented explicitly. This flexibility
and maintaining the platforms and infrastructure
provided, lie at the heart of infrastructure-based
service provision. Enforced processes (change
and release management, automated promotion
of software through the DTAP street based on test
and acceptance criteria) mean that the DevOps
teams demonstrably keep to the rules within the
organization. We often see that on paper ITIL
processes look great but in reality they are applied
insufficiently. In a DevOps world, it is also desirable
that the DevOps teams make sure they - and
other teams - keep to the processes. Moreover,
this is much easier because all the people in the
process are in one room and thus the processes
are very short and efficient instead of being long
and burdensome. What is more, processes are
increasingly described in the form of behavior
rules and agreements rather than in process
documents.
This also applies to the processes in the other
journeys. In this way, a giant step is made towards
realizing infrastructure management that is in
line with the need for IT services to be agile and
available. This step towards facilitating change
has become possible in recent years thanks to
a wide array of tools and methods (that are often
open source) which are aimed at automating parts
of the development process and the deployment
process. As a result of the virtualization of infrastructure
– infrastructure as code – the standards
from the development domain (version control,
full scripting of the promotion of software as well
as modifications to infrastructure and platforms)
are applied to compatible standards. Does this
mean that Dev has triumphed over Ops? No! That
is certainly not the case. Although the commitment
to innovation within the infrastructure domain
has been strengthened, success is equally due
to lifecycle thinking in the operations domain in
terms of availability, continuity and stability. It is
this cross-pollination that has brought Dev and
Ops closer together. Quality at the source enables
the divide between Dev and Ops to be bridged.
ASL
Agile/
Scrum
Applications
4
Lean IT
Infrastructure
3
ITIL
Operations
Development
ITIL
22

4
The step
to Lean IT
That brings us to the fourth DevOps journey. A
next step is taken in this journey. The DevOps
teams seek to respond to the application domain’s
need to reduce time to market. Infrastructure
facilitates these teams optimally with
appropriately modified platform and infrastructure
services. As the quality is demonstrably under
control, the added value of the division between
run and change becomes steadily lower and new
possibilities are created for further expanding the
change domain. After all, the continuity of service
delivery is safeguarded. Through value-stream
optimization (Lean IT) new possibilities are created
for shortening processes. We have called
this journey Lean IT (‘handing over the keys to
the kingdom’) because it optimizes the Lean IT
value stream. What we see is that from a Lean
perspective, the focus is on creating added value,
and non-value activities and necessary non-value
activities are reduced. By automating large parts
of the operations processes and activities, greater
transparency is created re garding the status of
operations and updates. In fact, the effect of the
operations standards increases because these
standards are routinely applied and outage is
measured and minimized (continuous improvement).
A step is thus made away from operational management
in the form of reactive monitoring of
components towards proactive management of
the entire service in the chain. Of course, this had
always been the intention and, in principle, had
always been possible. However, when we look
at how things turn out in practice, it is often not
the case. Through far-reaching standardization
and shortening of operations processes, collecting
monitoring data (big data) and providing the
DevOps teams that are responsible for the health
of the service with access to this data, proactive
management becomes the key to continuously
increasing the tempo of updates and not drowning
in incidents and firefighting. Mature operations
teams manage and update the services on a
daily basis.
In this situation, operations (or infrastructure
operations) can hand the DevOps team the key
without jeopardizing the availability of the service.
What is more, if this key is not handed over, the
delivery of customer value will be jeopardized.
Today, customers require services which are in
line with their current needs and not necessarily
the contracted services of several years ago.
Change becomes the norm but these services
have to remain available.
This fourth journey thus shows how the application
domain and the infrastructure domain
work together to increase the agility of IT as a
whole, while never compromising the basic need
to safeguard continuity. The DevOps journeys
above provide a frame of reference for various
stakeholders to consult one another about the
goals an organization seeks to achieve, and
how the different parts of the organization can
contribute to achieving them. A common view
and language are vital to this end. In addition, it
is useful if people recognize and learn from one
another’s contributions. Developers should learn
that continuity requirements and operations tasks
have value and can – and must – be optimized in
order to safeguard agility in the long term as well.
DevOps Magazine
23

At the same time, people in
infrastructure learn to use the
development standards when
developing and maintaining
cloud-compliant infrastructures.
The common goal of delivering
more value, faster, requires new
steps and working methods from
every perspective. It is essential
here to break down ‘walls’ and
facilitate flow within the various
IT domains and between the
business and IT.
ASL
Agile/
Scrum
Applications
4
Lean IT
Infrastructure
ITIL
Operations
Development
ITIL
24

Maximizing Business Value
with IT by transforming People,
Processes & Technology
SOURCING ADVISORY
Effectively sourcing
Business & IT services
BUSINESS & IT ROADMAP
Improving the alignment
of Business & IT
LEAN IT, AGILE & DEVOPS
Accelerating customer value
& high-performing IT
IT GOVERNANCE & LEADERSHIP
Ensuring a well-governed
IT organization
SOURCING MANAGEMENT SERVICES
Ensuring contracted performance,savings
and efficiencies
IT SERVICE MANAGEMENT
Enhancing predictable &
compliant IT services
OUR WAY OF WORKING
We apply a balanced approach in our assignments to deliver fact-based and
sustainable results
People: Management of Change through coaching on the job and expert training
Process: Operational Excellence by pragmatically using Best Practice Frameworks
Technology: Innovation thanks to extensive knowledge of Architecture & Tooling
Quint Wellington Redwood (Quint) is an independent consulting firm. Our portfolio
is focused on providing consultancy and training aimed at optimizing IT-intensive
processes. We are in no way affiliated with IT providers. Our independence is your
guarantee that we serve only your best interests.
The Netherlands | USA | Spain | Italy | India | Malaysia | Japan
www.quintgroup.com
DevOps Magazine
25

The Impact of DevOps on
Your ITIL Implementation
T
he question of whether ITIL® and DevOps
are related is not new. People have many
conflicting views on the subject: some argue
that ITIL and DevOps have different mindsets,
some say that they are compatible. Our view is
that the two concepts are compatible and can
support the mindset needed to improve IT services
delivery. This white paper focuses on the impact
of DevOps on IT organizations that currently work
with ITIL best practices. How does DevOps impact
service design, transition and operation phases,
and IT processes in general? But first we need to
define what DevOps and ITIL actually are.
DevOps
Is it a culture? Is it a job title? Is it a way of organizing?
Or just a way of thinking? Well, there are
several opinions, but before we address the “what”,
let’s address the “why”. The rise of cloud-based
web applications is putting IT under pressure. The
IT user community is demanding quick releases
in response to issues or requests and this often
results in more defects in operations due to poor
development quality. IT cannot afford to lose out;
it must respond rapidly and, at the same time,
innovate and reduce operational costs. This is also
true for daily change. The common challenge of
many IT organizations is: how can IT cope with
the changing demand for IT services? Change is
the new Run while staying in control of delivering
IT services to production.
DevOps attempts to solve this problem by developing
a symbiosis between development
and operations. DevOps focuses on creating a
fast and stable workflow through development
and IT operations. This means features can be
deployed into production quickly, and problems
can be detected and corrected as they occur.
DevOps is considered to be a new approach to
the traditional application lifecycle management
process or Systems Development Life Cycle
Central to the DevOps philosophy is a recurring flow
of small releases facilitated by automated configuration,
test, and a closer collaboration between developers
and operations people.
Continuous
integration
Dev
Automated
tests
Collaborative
Development
Small releases
Continuous monitoring
and feedback
Automated
Ops
configuration
(SDLC) methodologies such as Waterfall and
the V-Model. To increase the involvement of the
business, more iterative and incremental (Agile)
software development methods are introduced
such as rapid prototyping and Scrum. Most
development methods lack the involvement of
operations and maintenance specialists and
infrastructure specialists. DevOps is an SDLC
method in which Lean and Agile principles are
combined with the involvement of all IT specialists.
Implementing DevOps is considered to be a
26

journey for which the experience of the organization
is the starting point. You can read more
about DevOps and implementation journeys in
our white paper ‘Four DevOps Journeys to Agility
& Continuity in Your Organization’.
ITIL is still relevant in today’s
Agile world
ITIL is a set of practices for IT service management
(ITSM) that focuses on aligning IT services
with the ever-changing needs of the business.
ITIL describes processes, procedures, tasks,
and checklists that can be applied by an organization
for delivering value in the form of IT
services. It is interesting to note that ITIL also
serves as a benchmark for product vendors
selling IT management tools; in fact, they often
market their IT service management tools as
“supporting” ITIL processes. The question that
now arises is: is ITIL still relevant in today’s Agile
world that DevOps has taken by storm? Before
we dismiss ITIL, we should remember that ITIL
is a best practice. Moreover, one of the success
factors of ITIL is that it is non-prescriptive. ITIL is
not explicitly opposed to Agile and DevOps. The
Service Design volume supports iterative and
incremental design, and mentions Agile and XP.
ITIL advocates continuous feedback between
the phases of the ITIL Service Lifecycle.
Continual Service Improvement
Service Operation
Service Design
Service Strategy
ITIL
Service Transition
Nonetheless, the implementation of ITIL in organizations
is, in many cases, suboptimal. This
can be due to a lack of capabilities or tools but
in many cases it is caused by a short term focus
(processes don’t matter, we want results) and
paying too much attention to continuity, stability
and security (which prevents flexibility). Moreover,
ITIL does not deliver best practices for developing
systems. So, is ITIL relevant?
Let’s see what some industry experts have to
say in this regard:
“I absolutely believe that ITIL and DevOps are
compatible”. Karen Ferris – Director and IT
Service Management Expert
“If you think DevOps and ITIL aren’t compatible
then you don’t understand either”. James
Turnbull – Author, CTO at Kickstarter and
Advisor at Docker
“DevOps does not diminish the value of ITIL – it
validates and matures it”.
Jayne Groll – President of ITSM Academy
and Board Member of the DevOps Institute
(DOI)
“The goal of DevOps is not just to increase
the rate of change, but to successfully deploy
features into production without causing chaos
and disrupting other services, while quickly
detecting and correcting incidents when they
occur. This brings in the ITIL disciplines...” Gene
Kim (DevOps Cookbook)
“Although some may view DevOps as backlash
to ITIL or ITSM, DevOps and ITIL are compatible.
ITIL and ITSM remain the best codifications
of the processes that underpin IT Operations,
and actually describe many of the capabilities
needed in order for IT Operations to support a
DevOps-style work stream”. Gene Kim, Kevin
Behr and George Spafford (The Phoenix
Project: A Novel about IT, DevOps, and
Helping Your Business Win)
DevOps Magazine
27

The impact of DevOps on ITIL
implementations
Adopting DevOps changes the way we design,
transition and operate IT services. It is a new
journey similar to the initial implementation of
processes like Incident Management. Gene
Kim’s “The First Way: Systems Thinking”
emphasizes the performance of the entire
system, as opposed to the performance of
a specific silo of work or a particular department.
Was this ignored in the ITIL Service
Design Package (SDP)? Not at all – the SDP is
very exhaustive in terms of considering future
changes, managing scheduled downtimes
and adopting varying levels of monitoring and
event thresholds. So, in that sense, ITIL does
advocate “Systems Thinking” from the start.
However, in design, we must contend with
microservices, a concept that has become
popular with DevOps. Typically, most architecture
is layered in terms of presentation
components, business logic, database
access and integration logic. This new way
of organizing the architecture results in organizing
the development team into functional
units such as User Interface team, Database
team, etc. Microservices facilitates a software
architecture in which complex applications
are composed of small, independent processes
communicating with each other using
language-agnostic application programming
interfaces (APIs).
Microservices enables teams to work independently
and accelerate development and deployment.
The efficiency of the service design process
increases when the architecture is properly defined.
All the best practices of ITIL (like the service
catalogue, capacity management and security
management) are still very useful when defining
this architecture.
When talking about Service Transition, we have
to include continuous integration and continuous
delivery. Gene Kim’s “The Second Way: Amplify
Feedback Loops” is about right to left feedback
loops i.e. from operations to development. The
release pipeline has higher visibility at all control
stages. Rather than having large chunks of infrequent
changes, we must permit – and even encourage
– frequent small changes, thus reducing
the risks associated with large infrequent changes.
Integration must be considered upfront, from the
very beginning.
change
Business process
change
Business process
change
IT services
IT services
time
time
Classic model:
big gaps and big steps
Agile initial effect:
small gap, but lagging
28

App 1 App 2
App 1
A microservice approach
segregates functionality into
small autonomous services.
A traditional application (Web app or large
service) usually has most of its functionality
within a single process (usually internally
layered, though).
And scales out by deploying
independently and replicating these services across
servers/VMs/containers
Traditional
First: completely work out an idea
Then: extremely accurate estimation
time
Production ready
Continuous Delivery
Maybe this was already sufficient!
First: think of an idea - outline
Then: work out the idea, try out and adjust
Always production ready
time
Business process
IT services
DevOps:
small gap, no lag
time
The traditional incremental approach calls for a fully formed idea
from the outset, whereas DevOps uses the best practices of Agile
to deliver services. This allows you to move from a vague idea to
concrete realization. In Service Transition we see the power of
new technology implementations (the automation of testing and
automatic deployment of infrastructure) to increase change velocity
while preventing errors.
What about changes to the Service Asset and Configuration
Management (SACM) process? DevOps advocates delivering continuously
into varied environments. All configurations are specified
in version-controlled blueprints that are automatically applied and
monitored for any deviation at all times. Pre-boot execution environments
deploy solutions into target machines driven by deployment
engines. This is different to the traditional way of working, but it is in
line with the goals of SACM to document all the relevant information
on software and hardware assets including change history. You
could say that SACM is much easier to implement thanks to the
new tooling that is also responsible for the success of DevOps.
DevOps Magazine
29

When it comes to testing, the ITIL Service Validation
and Testing process advocates the testing of
service requirements (functional and non-functional).
Test-driven development was used in Agile
environments even before DevOps was born.
DevOps calls for continuous integration wherein
any change tracked in a source code control
system triggers test cases and the developer is
immediately notified of the results. Basically, new
functionality won’t be added until the quality is
good. Here we see that the new technologies
and methods that feed DevOps will also enhance
the implementation of ITIL in organizations. When
it comes to Service Operation processes such
as incident management, the cross-functional
team made up of development and operations
staff takes end-to-end responsibility for delivering
services at acceptable levels. This implies that
as they pick items from the product backlog, the
development team will pick change requests,
service requests, incidents and problems based
on priorities set by the product owner and formalized
in a Service Level Agreement. The golive
activity would be another service request
that is accomplished by the push of a button
– which means canned deployments into various
environments must be planned and designed
upfront. The subsequent monitoring and setting
of appropriate thresholds at the component and
service level is performed while keeping in mind
the service level agreements with the business.
The concept of Service Management adds value
in managing the interaction between the various
DevOps teams. For example: the change of one
system delivered by one DevOps team should
not hamper the systems of other teams. This will
require Change Management.
With respect to Continual Service Improvement
(CSI), the sixth step – How do you keep the
momentum going? – is about continuous improvement
in the form of Plan-Do-Check-Act,
which matches the DevOps activity of feedback
cycles that ensure the delivery of high quality in
an incremental fashion. In this respect, DevOps
teams rely heavily on Lean IT principles for embedding
continuous improvement into their way
of working.
Customer orientation is key
In the end, we believe DevOps and ITIL are
a means to achieving the goal of supporting
the business with the right IT that works
smoothly.
The business requires:
• Sound advice on new possibilities and
the alignment of changing business needs
with the existing IT (this is still the field of IT
consultants and architects).
• Agreed changes to be delivered as soon
as possible. In this regard, the added value
of DevOps is important. ITIL change and
release management can serve as quality
control in this requirement.
• IT to keep running without interruption.
Here, ITIL offers a lot of added value, but
even more reliable services can be realized
in combination with DevOps.
• The delivery of the IT services requested.
ITIL also provides added value in this respect.
It is simple to define what the customer wants,
but it is harder to realize flawless delivery. For
this reason we see that the implementation
of ITIL, DevOps and all other methods are
change journeys in which every step also has
to deliver value. Experiencing such a journey
together makes it more enjoyable and faster.
30

Conclusion
When combined, DevOps and ITIL result in integrated business, development and operations
teams that take end-to-end responsibility for achieving business goals. DevOps turbo-charges
ITIL: as the new kid on the block, with best practices for the delivery of new services while
maintaining existing ones, DevOps can support the agility and reliability of IT services and provide
the business with optimal value. DevOps accelerates the pace of ITIL and brings high visibility
to all stakeholders to quickly address issues and move forward. This enables the faster delivery
of high-quality IT services, and in so doing erases some of the criticism that ITIL has received.
ITIL can support DevOps teams with best practices to specify and deliver reliable services and
enhance collaboration between the various teams, specifically when not all teams are working
DevOps. ITIL needs to stand tall in the face of the DevOps storm. We advise ITIL process managers
to fasten their seatbelts for a bumpy ride and we recommend DevOps gurus to use the ITIL best
practices which have already served the industry well for more than 20 years!
DevOps Magazine
31

DevOps Training
DevOps Agile Skills
Association - Empowering IT
Transformational Change
Quint is founding member of the DevOps
Agile Skills Association (DASA, an open
global community for DevOps and Agile
Skills development. It is organized as a community-driven
organization open for participating
member organizations to help define role-based
competencies and learning curricula.
32

To Realize its Broader Purpose, DASA aims to:
Promote a knowledge and skills framework for
DevOps, based on a defined set of principles.
Generate interest and awareness for the need
for knowledge and skill development.
Map member training content to the role
based competence baseline.
Develop and evangelize a vendor neutral
DevOps qualification program for professionals.
Advance quality of training and open source
certification for DevOps knowledge and skills.
DevOps Magazine
33

DASA Qualification Program
The qualification scheme has been designed to address the skills requirements from as Associate,
Practitioner and Expert Level. The objective is to provide the right training paths based on the
needs of both individuals and organizations.
5
Master
Dasa devops fundamentals course -
audience
• Anyone working in the Development and
Operation area. Core audience: Management,
Operations, Developers, QA, Testing, Service
Management
• Individuals involved in IT development, IT operations
or IT service management
4
Expert
3
Proficient
Devops
Specialization:
Enable and Scale
Devops
Specialization:
Specify and Verify
Devops: Practitioner
Devops
Specialization:
Create and Deliver
• Individuals who require a detailed understanding
of DevOps principles
2
Competent
Devops: Fundamentals
• IT professionals working within, or about to
enter, an Agile Service Design Environment
1
Novice
About the DevOps Fundamentals Training & Certification
DevOps is the future of IT today! This 3-day course provides an introduction to DevOps – the cultural
and professional movement that stresses communication, collaboration, integration and, of course,
automation in order to improve the flow of work between software developers and IT operations
professionals. To maximize the IT value flow to customers, DevOps creates an improved ability to
design, develop, deploy and operate software and services faster for the benefit of the business.
Higher customer satisfaction, better quality, faster delivery and lower costs are all benefits of DevOps.
Learning Objectives
Professionals will increase their value within the
organization and on the IT market with this certificate.
After successfully completing the course,
they will have an understanding of DevOps and
be able to:
• Explain the drivers responsible for the emergence
of DevOps;
• Define and discuss the key concepts and
principles of DevOps;
• List and explain the business benefits of
DevOps and continuous delivery;
• Describe the Service Delivery process;
• Explain the concepts of test automation, infrastructure
automation, and build and deployment
automation;
• Describe how DevOps relates to Lean and
Agile methodologies;
• Summarize case studies of IT organizations
that are making the transformation to Adaptive
IT and DevOps models;
• List the most common and popular DevOps
tools;
• Discuss the critical success factors for DevOps
implementation.
34

This course helps professionals understand:
• Why organizations need to adopt DevOps
practices from both the business and IT perspectives;
• DevOps values and principles;
• How DevOps interfaces with other frameworks
such as Agile, Lean and ITSM;
• The characteristics of a DevOps culture;
• DevOps organizational considerations including
DevOps roles, teams and organizational
structures;
• Key DevOps practices;
• Common DevOps automation practices and
tools categories;
• How to adopt a DevOps culture.
Course Approach
This course is designed to provide you
with the background knowledge you need
to build your DevOps vocabulary and to
understand the principles and practices
of DevOps. More importantly, this course
is designed to inspire you to serve as a
change champion who leads and mentors
others by sharing and using what you’ve
learned – and continue to learn – about
DevOps.
Certificate
DevOps Fundamentals /DevOps Agile
Skills Association
About the Exam
The examination takes 60 minutes with
non-native speakers of English being
permitted an additional 15 minutes. It is
a closed-book, web-based exam and
consists of 40 multiple-choice questions.
The passing grade is 65%. Participants
are permitted to use scratch paper. A
proctor will be present or the exam will
be proctored via a webcam.
Delivery method:
Classroom, Virtual or in-company
DevOps Magazine
35

About Quint
Wellington Redwood
“ ”
It is not the strongest of the species that survives, not the most
intelligent that survives. It is the one that is the most adaptable to change.
– Charles Darwin (1809-1882)
Quint Wellington Redwood (Quint) focuses on two major changes taking place in the world: digital
transformation and the increasing need for sustainability. Technology is one of the driving forces
of change. Many organizations have difficulty in keeping pace with today’s rapid successive developments
and applying them successfully. They wonder if they are adaptive enough to change
and whether they will still be relevant in the near future. We see that organizations have to make
fundamental choices about business models, management and technology.
We believe that organizations cannot continue to survive without using technology effectively, nor
without taking into account their customers, employees and environment. Therefore, in our vision,
it is not only technology that is a deciding factor for change. Knowledge, leadership and culture
are prerequisites to recognize and to apply the relevant technologies to create value.
Quint supports organizations in their digital transformation. Together with our clients, we build
roadmaps that facilitate change, anticipate opportunities and respond to threats. We bring
technology – and especially its application – to life.
Challenge
We challenge ourselves and
our clients to realize concrete
improvements and
results. This means we are
not afraid to voice opinions,
to question our own ideas
and those of others. We do
not provide advice from the
sidelines, but are actively
engaged.
Connect
Quint brings the worlds of business
and technology together.
We share knowledge and
arrange partnerships to accelerate
change and innovation.
We develop teams and people
using new ways of collaboration
and leadership, so that all can
realize their full potential and
grow within the organization.
Being lean and agile is at the
core of everything we do.
Change
Quint regards people, process
and technology as factors that
strengthen each other. Together
they form the basis of sustainable
change. We use analysis, design
and implementation to connect
and improve these factors.
Through training and coaching our
clients, we empower their ability to
change, so that they can continue
their transformation without Quint’s
help.
36

A UNIVERSAL QUALIFICATION
PROGRAM FOR DEVOPS AND AGILE
DASA - Empowering IT Transformational Change
DASA AIMS TO PROVIDE
DevOps Agile Skills Association (DASA) is an open global community for DevOps and Agile Skills development.
It is organized as a community-driven organization open for participating member organizations to
help define role-based competencies and learning curricula.
To Realize its Broader Purpose, DASA aims to:
Promote a knowledge and skills framework for
DevOps, based on a defined set of principles.
Generate interest and awareness for the need for
knowledge and skill development.
Map member training content to the role based competence
baseline.
Develop and evangelize a vendor
neutral DevOps qualification
program for professionals.
Advance quality of training and
open source certification for
DevOps knowledge and skills.
5
Master
DASA QUALIFICATION PROGRAM
Our qualification scheme has been designed to address the skills
requirements from as Associate, Practitioner and Expert Level. The
objective is to provide the right training paths based on the needs of
both individuals and organizations.
Start your DevOps transformation today!
www.quintgroup.com/us/training/devops
4
Expert
3
Proficient
2
Competent
1
Novice
Devops
Specialization:
Enable and Scale
Devops
Specialization:
Specify and Verify
Devops: Practitioner
Devops: Fundamentals
Devops
Specialization:
Create and Deliver
DevOps Magazine
37

What we do
Quint’s portfolio of services includes consulting, training and solutions,
integrated across the domains of Business and IT Management.
“Quint Academy helps organizations
and professionals to change and to
improve IT performance”
Quint Academy is one of the world’s largest IT training
organizations. Worldwide, over 30,000 professionals
choose Quint Academy every year. Since 1992, we have
been successfully responding to the IT training needs of
these professionals.
Quint Academy instructors are recognized as thought
leaders and as such contribute to ‘best practices’-based
curricula. A unique feature of Quint Academy is that our
instructors and educationalists are actively involved in
Quint’s consultancy business. This enables us to provide
a challenging mix of theory and practice. The practical
applicability of the knowledge and know-how acquired is
thus guaranteed.
www.quintgroup.com
38

Discover our Portfolio
DEVOPS TRAINING
(DASA) DevOps Fundamentals |
DevOps Premium eLearning |
DevOps & Agile
SOURCING TRAINING
Sourcing Governance | IAOP®
| Best Value Procurement |
Cloud Sourcing
LEAN IT TRAINING
Lean IT Foundation | Lean IT Kaizen
Lead | Lean IT Leadership
AGILE TRAINING
Agile Awareness | AgilePM®
Foundation & Practitioner |
Professional Scrum Master |
DevOps & Agile
IT GOVERNANCE TRAINING
COBIT® 5 | Sourcing Governance
| IAOP® | ISO/IEC 20000 |
M_o_R®
ARCHITECTURE TRAINING
ISO/IEC 20000 | Big Data |
M_o_R® | COBIT® 5 | ASL® |
BiSL® | Cloud Computing
IT SERVICE MANAGEMENT
TRAINING
ITIL® | Change Management | ASL®
| BiSL®
PROJECT MANAGEMENT
TRAINING
PRINCE2® | Project Management
Professional (PMP®) | P3O® |
AgilePM® | Change Management |
MSP®
DevOps Magazine
39

DevOps
Video’s
Through the QR code you will find a list of previously hosted webinars
from our experts at Quint Wellington Redwood. Simply scan the code
with your mobile to watch the webinar you're interested in.
Webinar Series #1:
The Impact of DevOps
on Operations
Webinar Series #2:
Service Management in
a DevOps Environment
Webinar Series #3:
DevOps is More than
Buying a Tool
Webinar Series #4:
The Business Case
for DevOps
40