Click here or press enter for the accessibility optimised version

The Agile Service

Management Guide
By Jayne Groll, DevOps Institute
with Foreword from Denis Esslinger
 Agile Service Management Guide

All Rights Reserved.

Copyright © 2021 by DevOps Institute
By Jayne Groll with Foreword from Denis Esslinger
Revised July 2021

This document may not be reproduced, transmitted, or stored in whole or in part by any means,
including graphic, electronic, or mechanical without the express written consent of the publisher.
Click here or press enter for the accessibility optimised version

FOREWORD
Denis Esslinger
ITSM and DevOps Evangelist
FOREWORD

pportunities, plans, and This guide grew out of Jayne’s recognition that
O circumstances, both internal and
external to organizations, are
end-to-end IT agility could only be achieved if
Agile thinking and practices were instilled into
changing at an ever-increasing pace. External every aspect of the management of products
unforeseen circumstances, like the COVID-19 and services before, during, and after
pandemic, can suddenly require significant deployment. Much of Agile’s focus has been on
alterations to business practices and the IT software development and deployment.
services that support them. Agility is no longer However, if the deployed software applications
something organizations want to strive for – it’s are not consistently delivered at needed levels
a necessity for business survival. of availability, capacity, security, and continuity,
little value will result from the deployed
I met Jayne about 20 years ago at an ITSM software.
conference where she was talking about the
importance of breaking down silos in IT. She Now, more than ever, organizations need to be
advocated that IT teams needed to use agile and quickly adapt their IT services to
organization-wide processes to successfully changing needs. Being agile is a never-ending
deliver value for customers. Since that time, challenge. This guide helps provide a practical
Denis Esslinger, ITSM and DevOps Evangelist
Jayne has continued to be a leader in advancing framework to engineer and continually improve
people-centered practices to improve value your IT service management practices to ensure
streams, including being a co-founder of services provide customer value as needs
DevOps Institute. continue to change ever more rapidly.
Click here or press enter for the accessibility optimised version

TABLE OF CONTENTS
Table of Contents

Introduction Chapter 1: Being Agile Chapter 2: What is Agile Chapter 3: Agile Service
Service Management? Management & Other
Frameworks / Practices

Chapter 4: Scrum Basics Chapter 5: What is Agile Chapter 6: An Agile Approach Chapter 7: Agile Service
Process Engineering to Process Engineering Management Roles

Chapter 8: Agile Service Chapter 9: Agile Service Chapter 10: Agile Process Chapter 11: Automation and
Management Artifacts Management Events Improvement Agile Service Management

Chapter 12: Getting Started APPENDIX: Agile Service Management Taxonomy About the Author
Click here or press enter for the accessibility optimised version

INTRODUCTION
INTRODUCTION The mandate remains the same but is more
urgent than ever: go faster but control costs and
to the design, implementation, and management
of ITSM processes. Certainly, concepts such as
risks. The ability to adapt to changing market “minimum viable”, “just enough” and “user
A lot has changed in just a few trends is essential for every business in order to stories” as well as the pillars of transparency/
short years. The rate of stay competitive and retain the current inspection/adaptation could be applied to
technological adoption has customer base. Any vertical market may be the process engineering.
accelerated at a pace unseen target for disruption by a known competitor, an
before. Automation is integrated unseen startup, or on the radar of aggressive Since that time, Agile Software Development is
into just about everything we do, organizations such as Amazon. Disrupt or be now being practiced by millions of more
both personally and professionally. disrupted. Transformation is no longer an option software engineers daily. Shippable increments
User expectation around technical as we enter the “next normal” following the are getting smaller and smaller. Cloud and
services is always on, always 2020 global pandemic. The directive from the hybrid environments are becoming normalized,
reliable, always delivering value, enterprise to IT is clear. Think like a start-up but giving way to cloud-native applications and
and always doing more. respect the bottom line. Be innovative and containerization. Monolithic applications are
internally disruptive. Speed, quality, and being broken down into microservice
reliability are your key metrics. Fail fast and
learn from it.

When I first authored the Agile Service

Management Guide in 2015, my primary
objective was to instill agile thinking into IT
Service Management (ITSM) process design.
Recognizing the similarities between software
development and process design cycles, I
wondered if the same incremental and iterative
approach put forth by Scrum could be adapted
to the design, implementation, and management
being broken down into microservice IT culture is shifting too. A few years ago, IT Is IT Service Management (ITSM)
architectures. Enterprise interest in emerging governance was considered the path to Still Relevant in the Next Normal?
practices such as continuous delivery/ business and IT alignment and was reflected in
deployment, automated testing, serverless, service management processes such as IT There have been some significant paradigm
Kubernetes, and reliability engineering is on the Change Management. Today, Change shifts with approaches such as Agile, DevOps,
rise. Delivering value is the prime directive and Management is under the microscope as being and Site Reliability Engineering. There will be
value stream management is replacing too restrictive as self-organizing hybrid product more. How does ITSM interact with these
traditional service management Open source teams are supplanting traditional development, approaches, if at all? Before we dive into the
applications are being utilized by developers operations, and security silos. Process, details of Agile Service Management, let’s
around the world and those same developers automation, and “human skills” are considered explore the ongoing relevancy of IT Service
may be responsible for writing, building, testing, equally important according to DevOps Management itself.
deploying, and securing their code. Institute’s annual Upskilling: Enterprise DevOps
Skills Survey and Report. Interoperability What is a Service?
between humans is as important as
interoperability between automation in order to While there are many definitions of a “service”,
increase flow. Lightweight interoperable here’s what I believe –
processes and tools are needed to support both
technical and human interoperability. A service enables the ability to do something
when and how it is needed or desired. It enables
IT organizations must adopt a service-oriented its customers to achieve their objectives more
approach to efficiently and effectively meet efficiently and/or more effectively than they
changing business needs. Rapidly changing could without the service.
business requirements require rapidly changing
organizational capabilities. A service exists purely to “serve” the objective of
its end customer (human or technical) and is
only perceived to create value if the service
delivers on its promise for timeliness and
delivers on its promise for timeliness and services need to be managed in order to deliver processes and the self-regulating systems of
quality. In today’s fickle and competitive “app” customer value, regardless of which approach, Agile, DevOps, and Site Reliability Engineering.
culture, a service that does not deliver value framework, or methodology is applied. IT In order to align with new requirements,
quickly and efficiently is replaced with one that Service Management, therefore, underpins just organizations should review their ITSM
does. about everything IT does in order to deliver governance model that was once a driving force
valuable services including: behind traditional ITSM.
A service may be comprised of multiple
products, applications, databases, Service Levels The question, therefore, is not whether ITSM is
infrastructure, platforms, and environments. Changes still relevant or even how to manage services in
Separately, most of these elements do not Releases an Agile, DevOps, and digital transformation
create value for the end customer. However, Configurations world. The real question is how much IT service
when federated into a “service”, value is Incidents management is just enough in order to create
perceived because the outcome is achieved on Problems/Root Cause consistent customer value and compete in a
time, cost, and quality. Requests fast-paced disruptive world. That’s Agile Service
Events/Monitoring Management.
What is IT Service Management? Capacity
Availability/Reliability
“IT Service Management is adopting a process Security
approach towards management, focusing on Continuity
customer needs and IT services for customers
rather than IT systems, and stressing continual One consideration affecting IT service
improvement.” Source: Wikipedia management is the evolution from project to
product management with its faster, more
IT Service Management focuses on ensuring IT frequent iterations and no finish line. This
services deliver value by understanding and paradigm shift has caused some friction
optimizing their end-to-end value streams. All between traditional command and control ITSM
services need to be managed in order to deliver processes and the self-regulating systems of
Click here or press enter for the accessibility optimised version

CHAPTER ONE:
Being Agile
Being Agile The MacMillan Dictionary defines “agile”
Being agile is a state of mind. It is more
perspective than prescription. In order for an
as: organization to “be agile,” it must also be:
If we can agree that ITSM is still
relevant, how then does it become
“agile”? ag·ile Customer-centric
Lean
Collaborative
/ˈajəl/ | adjective Communicative
Adaptive
Able to move quickly and easily; Measurable
able to think quickly, solve Consistent
problems, and have new ideas. Results-oriented
Reflective

Too often in IT, the term “Agile” is used to The Agile Manifesto
describe Agile software development, Scrum or
Scaled Agile practices. While these are all The underlying concepts of agile software
excellent frameworks, the application of Agile development were first laid out in the Agile
practices to software development does not in Manifesto in 2001.
and of itself increase an organization’s agility.
As many have learned, Agile software The Agile Manifesto was supported by twelve
development teams are often frustrated by principles as paraphrased below:
delays from downstream activities.
1. The highest priority is to satisfy the
Agility must span the entire value stream. It is customer
more important to “be agile” than to “do Agile”. 2. Welcome changing requirements even if
late in the development cycle
The Agile Manifesto
 late in the development cycle To the ITSM community, the Agile Manifesto
3. Deliver working software frequently may initially seem to discredit everything that
4. Business and IT must work together daily ITSM stood for including processes, tools,
5. Give motivated people what they need and plans, documentation and service level
trust them to get the job done agreements. Not true. The Agile Manifesto does
6. Face to face is the best way to not suggest that the items on the right have NO
communicate value. It’s a reminder that the items on the left
7. Working software is the most important have MORE value and therefore a caution not to
measurement of progress prize the artifacts on the right over the
8. Agile processes promote sustainable outcomes on the left. It’s a reminder that we
development should do “just enough” of the items on the right
9. Be simple – maximize the amount of work in order to deliver on the promises of the left.
NOT done
10. Self-organizing teams create the best
architectures, requirements and designs
11. Teams should regularly reflect on and
readjust their behavior to become more
effective
12. Continually grow the team’s technical
excellence and design skills

The spirit of the Agile manifesto has never been

more relevant and the underlying principles
should form the basis for managing the entire IT
value stream from ideation to value creation.
Click here or press enter for the accessibility optimised version

CHAPTER TWO:
What is Agile Service
Management?
What is Agile Agile Service Management adopts Agile
principles to IT service management processes
Management processes
Enable a faster flow of software delivery by

Service by implementing IT Service Management in

small, integrated increments. This approach
defining “just enough” IT Service Management
Engineer an integrated Agile Service

Management? ensures that IT Service Management processes

reflect Agile values from initial design through
Management microprocess architecture
Find the balance between an IT Service
continuous improvement. Management governance model and a self-
Agile Service Management (Agile regulating system
SM) ensures that IT service The goals of Agile Service Management are: Optimize the use of automation to execute
management processes reflect process tasks and to manage artifacts
Agile values and are designed with Ensuring IT Service Management processes
“just enough” control and structure help create value for customers It is important to note that Agile Service
to enable the delivery of services Ensuring holistically that all IT Service Management does not reinvent or replace the
that enable the ability to do Management processes are coordinated and guidance from other frameworks such as
something when and how they are interoperate smoothly ITIL®→ or Site Reliability Engineering. By itself,
needed or desired. Ensuring there is the least amount of process Agile Service Management is not an ITSM
control for the greatest amount of speed, framework that defines principles, processes,
quality, and compliance and procedures. Agile Service Management is
an enabler of faster, more adaptable IT Service
To achieve these goals, Agile Service Management regardless of framework. By
Management strives to: embracing the “just enough” spirit of the Agile
Manifesto, the incremental and iterative
Optimize processes across the organization’s approach of Scrum, key practices from ITIL®/
value streams ITSM, value stream management, Continuous
Make sure that agile values and systems Delivery, and Site Reliability Engineering, Agile
thinking are instilled in IT Service Service Management focuses on having the
Management processes least amount of process control for the greatest
least amount of process control for the greatest Overcoming constraints in process flows
amount of speed, quality, and compliance. Increasing the effectiveness and efficiency of Key Terms
ITSM processes
One of the key principles of Agile Service Improving the collaboration between Service Management Practice: an end-to-
Management is the decoupling of monolithic development, operations, security, and the end capability for managing a specific
processes into multiple microprocesses that business aspect of service delivery (e.g., changes,
can be designed and managed separately. Improving the velocity of the process incidents, service levels) that is built on a
Microprocesses can integrate with other improvement team microprocess architecture
microprocesses from the same or other IT Getting more “done”
Service Management practices. This flexible Process: interrelated work activities that
“plug and play” approach encourages systems Agile Service Management has cultural benefits take specific inputs and produce specific
thinking and allows activities from multiple IT too. By creating a common approach to outputs
service management practices to be built in practices from multiple frameworks, Agile
close alignment with each other. A good Service Management helps to instill systems Microprocess: a distinct activity that can
example of this would be developing a thinking that reduces handoffs, optimizes be defined, designed, implemented, and
microprocess for recording changes at the automation, and creates a common language management independently but is
same time as a microprocess for recording drawn from multiple sources. integrated and interoperable with other
incidents so that the two could be cross- microprocesses
referenced.
Microprocess Architecture: A collection
The key benefits of taking an Agile Service of integrated microprocesses that
Management approach include: collectively perform all of the activities
necessary for an end-to-end service
Increased value to customers management practice to be successful.
The ability to meet customer requirements
faster and more accurately
Overcoming constraints in process flows
The Two Aspects of Agile Service Agile Process Engineering system is essential.
Management
Agile Process Engineering (formerly Agile Agile Process Engineering also aligns with the
There are two aspects of Agile Service Process Design) is an iterative and incremental goals and objectives of a microservice
Management: Agile Process Engineering and approach to designing a process that replicates application architecture that structures an
Agile Process Improvement. many of the practices used in Agile software application as a collection of independent
engineering – short, iterative designs of “services “
Agile Process Engineering is the aspect of Agile potentially shippable Increments or
Service Management that applies an Agile microprocesses. By focusing on the “minimum Microservices should be managed by
approach to process engineering similar to an viable” or “just enough” level of process control, microprocesses. We will define and discuss
Agile approach to software development. Agile Process Engineering supports a “shift left” microprocesses and Service Management
mentality so as to engage ITSM practices much practices further in Chapter 4.
Agile Process Improvement is the aspect of earlier in the value stream. Smaller increments
Agile Service Management that aligns Agile of microprocesses support faster deployments, Agile Process Improvement
values with processes through continuous better compliance, and more knowledge
improvement. captured at the source. This approach also Agile Process Improvement ensures that ITSM
allows ITSM practices more time to be agility introduced through Agile Process
institutionalized and normalized by the people Engineering is continually reviewed and
who execute the practices, microprocesses, and adjusted as part of the ITSM’s commitment to
procedures. continual service improvement. The goal is to
identify and mitigate any constraints that may
Agile Process Engineering requires an IT service be affecting both the flow of the service
management architecture that supports management practice, microprocess, and
systems thinking that spans the entire value general flow of the value stream. Agile Process
stream. The architecture is engineered much Improvement is the watch guard over
like software where interoperability in a complex unintentional process bureaucracy.
system is essential.
During this repetitive stage, Practice Owners
conduct regular reviews with other teams and
stakeholders to ensure that ITSM processes are
still providing value and have not drifted from
“just enough” to “too much” or “not enough”.
Agreed improvements are captured in the
practice’s Practice Backlog and engineered as
part of Continual Service Improvement (CSI)
sprints.

Since Agile Process Engineering creates a

service management architecture built on
interoperable microprocesses, Agile Process
Improvement can manage and deploy
improvements to a single microprocess or an
entire service management practice, allowing IT
service management programs to adapt to
changing business requirements faster. We
explore Agile Process Improvement further in
Chapter 10.
Click here or press enter for the accessibility optimised version

CHAPTER THREE:
Agile Service
Management and
Other Frameworks /
Practices
Agile Service When I first authored the Agile Service
Management Guide, ITSM and ITIL® were often Agile Software Development
Management considered to be virtually synonymous. Since
then, frameworks and methods such as DevOps,

and Other Site Reliability Engineering (SRE), Lean IT,

Scaled Agile (SAFe) and a new release of ITIL®
Scrum
According to the 2017 Scrum Guide, Scrum is a

Frameworks / have emerged. Each of these have inspired new

ideas and new approaches to the problem of
framework within which people can address
complex adaptive problems, while productively

Practices delivering and managing services in a

technology-centric world. It is important to note
and creatively delivering products of the highest
possible value. Scrum is:
that while each of these frameworks have merit,
As mentioned before, Agile Service were authored by talented industry experts, and Lightweight
Management does not redefine the contain very useful advice, none are perfect and Simple to understand
inputs, outputs, or metrics of none are a complete end-to-end solution. Agile Difficult to master
processes such as IT Change or Service Management encourages the
Incident Management. There are exploration and adoption of guidance from Recognizing the similarities between software
some great frameworks in place multiple sources in order to create a proprietary engineering and process engineering, Agile
that already do this. Agile Service “just enough’ ITSM program that is customized Service Management loosely adopts the
Management does define a model to the organization’s requirements. principles and processes from the Scrum
for engineering any process in an Framework and applies them to IT Service
incremental and iterative way. The Let’s look at the most prominent process Management. We will explore this further in
principles and model can be frameworks and models trending today. Chapter 5.
applied to the adoption of one or
more IT or even enterprise service DevOps
management frameworks. DevOps is a cultural and professional movement
that stresses communication, collaboration, and
integration between software developers and IT
 Source: The Phoenix Project, Kim, et al, IT Revolution

integration between software developers and IT increase flow across multiple processes (First and DevOps can meet and align. Continuous
Operations professionals while automating the Way), shorten feedback loops on process Delivery relies heavily on automation to perform
process of software delivery and infrastructure performance and improvement (Second Way) many of the activities associated with Release
changes. Gene Kim, lead author The Phoenix and encourage a collaborative, experimental Management including building, testing, staging,
Project, IT Revolution Press and learning environment between various IT securing, and releasing software. However,
teams and frameworks (Third Way). intelligent automation needs intelligent
On its own, DevOps is not a framework, processes as shown in the Upskilling: Enterprise
standard, or methodology. It is a set of guiding Continuous Delivery/Deployment DevOps Skills Report. Agile Service
values and principles that crosses multiple Management can underpin Continuous Delivery/
domains, tools, and practices including Continuous delivery is a methodology that Continuous Deployment by defining lightweight
development, operations, security, and reliability. focuses on making sure software is always in a interoperable microprocesses while Continuous
releasable state throughout its lifecycle. Delivery automation can reduce IT service
Agile Service Management aligns with the Continuous Deployment automatically releases management toil. Best yet, since both are
principles of The Three Ways of DevOps as the software into production. engineered (or re-engineered) in increments, the
described in The Phoenix Project by Gene Kim, process, the automation, the metrics, and the
et al. An incremental approach to process Continuous Delivery is one of the main artifacts can be defined and implemented
engineering can remove constraints and crossroads where Agile Service Management simultaneously.
increase flow across multiple processes (First and DevOps can meet and align. Continuous
 waste and to identify, prioritize and measure constraints.
Lean Practices improvements.
Kanban
Value stream mapping and value stream
Value Stream Management management have emerged as key tools for Kanban is a method of work that pulls the flow
visualizing, understanding, and managing how of work through a process at a manageable
Value stream management is a management value is created for the customer. This is not pace. A Kanban board, therefore, makes work
approach that focuses on the end-to-end flow of merely renaming a flowchart or replacing a visible, reduces work in progress, helps teams
customers, their challenges, and ideas (as service lifecycle diagram. By managing a value collaborate, and supports the “definition of
input) to target business value (as output) stream, the entire organization focuses on the done”. Kanban boards are used by many Agile
through best practices and by the elimination of customer’s perception of value and how the software development teams to manage user
wasted time and resources. organization manages value creation on an stories, backlogs, and sprints. Since Agile
ongoing basis. The net result is that value Service Management adopts the concept of
Value stream management helps determine the stream management requires everyone involved user stories, backlogs, and sprints, a Kanban
value of software development and delivery to shift towards systems thinking and away can be a useful tool for managing practice
efforts and resources. It also helps to improve from silos. backlogs, strategic, process, and continuous
the flow of value to the organization, while improvement sprints. Most importantly, whether
managing and monitoring the software delivery Since value streams cross multiple processes, in use for software or process engineering, a
life cycle from end to end. Source: Forbes taking a microprocess approach as defined by Kanban can be particularly helpful in
Technology Council Agile Service Management allows processes to understanding and managing team velocity.
be built incrementally and in alignment with
A value stream is the sequence of activities each other. Sometimes the biggest constraint to
required to design, produce, and deliver a flow may be unintended bureaucracy or
specific product or service and streams typically complex end-to-end processes that were
span multiple processes. Value streams allow designed in isolation. Agile Service
teams to identify areas of non-value creation Management helps to overcome those
waste and to identify, prioritize and measure constraints.
 a more visible focus on service value and Site Reliability Engineering
IT Service Management outcomes. Where ITIL® V3 had 26 processes,
Frameworks ITIL® 4 defines 34 “practices” for managing Site Reliability Engineering (SRE) is a discipline
services in a complex multi-domain that incorporates aspects of software
environment. The migration from “process” to engineering and applies them to infrastructure
ITIL® 4 “practice” may seem semantic, but the goal was and operations problems. Inspired by Google’s
to instill a sense of capability instead of a sense book series of the same name, SRE has gained
For over three decades, ITIL® has been the most of rigid process. global interest due to its goal of creating ultra-
widely accepted and adopted framework for scalable and highly reliable software systems.
managing IT Services. ITIL® provides a Like SRE or Scrum, ITIL® 4 embeds a set of core The role of a Site Reliability Engineer has also
framework that organizations can adapt to principles into ITIL® 4, adapting from those emerged as a desirable and hirable job whose
deliver and maintain IT services to provide originally introduced in the ITIL® Practitioner: team is empowered to regulate its own
optimal value for all stakeholders including the workload, make tomorrow better than today and
customer. It provides guidance and structure to The introduction of ITIL® 4 may inspire use failure as an opportunity to improve.
practices such as change enablement, service organizations to reimagine their IT Service
configuration, deployment, release, incident, and Management models and re-engineer some of By its own admission, SRE is Google’s approach
problem management. their processes or practices to line up with Agile, to service management and is likely the most
DevOps, SRE, and Continuous Delivery innovative approach to ITSM since the early
With an incremental release of the library ecosystems. I would encourage those looking at days of ITIL®. The guidance provides insight on
starting in 2019, ITIL® 4 remains true to its ITIL® 4 to review the current state of their service management practices such as service
heritage as an IT governance model but with process adoption and analyze whether they are level, change, incident, capacity, availability and
closer alignment to modern practices such as at “just enough”, “too much” or “not enough” other traditional ITSM practices.
Agile and DevOps. based on individual requirements,
transformation efforts, and compliance. The principles of SRE are founded on a self-
ITIL® 4 embeds elements of V3’s Service regulating system that aligns closely with Agile
Lifecycle into a Service Value System (SVS) with software development and DevOps
a more visible focus on service value and
While Agile Service Management is built around Observability takes monitoring and event their products to accommodate ESM.
the pillars of Scrum, there is a close alignment management to a whole new level. No longer
to the Site Reliability Engineering principles of are we monitoring for reactive issues such as Since Agile Service Management is not aligned
eliminating toil, empowering teams, optimizing capacity, availability or throughput thresholds. to a particular ITSM framework, the same
automation and maintaining simplicity. The No longer are we satisfied with proactive approach can be applied to any process
creation of a microprocess architecture that system health monitoring. Observability is much engineering effort including Enterprise Service
allows SRE and Development teams to more than being reactive or proactive – it now Management.
autonomously adopt a small set of rules and creates an environment where operations and
“just enough” structure should appeal to Site development can infer the state of the internal ISO/IEC 20000:1 2018
Reliability Engineering teams. system based on external conditions. It does
not replace monitoring but adds a level of ISO/IEC 20000 is the auditable international
Observability insight and abstraction that may not have standard for IT Service Management that
amalgamated before. specifies the “requirements for an organization
The concept of observability is quickly gaining to establish, implement, maintain and
acceptance as the more modern way to Enterprise Service Management continually improve a service management
establish monitoring and event management system (SMS) including the planning, design,
practices. The success of IT service management transition, delivery and improvement of services
practices has inspired organizations to extend to meet the service requirements and deliver
Based on control theory, observability is a the concepts beyond IT as Enterprise Service value.”
measure of how well internal states of a system Management (ESM). ESM applies many of the
can be inferred from knowledge of its external same principles, practices and processes to
outputs. This approach is now being adopted by business services – particularly those that the
global IT organizations that are managing business supplies to its internal customers from
complex interoperable environments and need business units such as HR or Finance. Many of
more than reactive monitoring to understand the the well-established ITSM vendors such as
state of their systems. BMC, Cherwell and ServiceNow have extended
their products to accommodate ESM.
Click here or press enter for the accessibility optimised version

CHAPTER FOUR:
Scrum Basics
Scrum Basics The Scrum Guide defines Scrum as: The Scrum framework is built around
interactions and rules that govern roles,
artifacts, and events.
While there are several solid Scrum is founded on empirical process
frameworks and methods for Agile control where knowledge comes from 3 Roles (Product Owner, Scrum Master,
software development, I have experience, decisions are based on what Development Team)
chosen to loosely model Agile is known and three pillars (Transparency, 3 Artifacts (Product Backlog, Increment,
Service Management after the Inspection, and Adaptation) underpin the Sprint Backlog,)
Scrum Framework. Scrum is entire framework. 5 Events (Sprint Planning, The Sprint, Daily
lightweight, simple to understand, Scrum, Sprint Review, Sprint Retrospective)
embodies empirical thinking, and
reflects the core values of the
Agile Manifesto. While the context
may be different, the core Scrum
iterative and incremental guidance
can be adapted to process
engineering and improvement.
Agile Service Management retains the
interactions and rules but adapts the roles,
artifacts, and events to IT service management
process engineering

3 Roles (Practice Owner, Agile Service

Manager, Agile Service Management Team)
3 Artifacts (Practice Backlog, Increment,
Sprint Backlog)
6 Events ( Planning, Sprint, Sprint Planning,
Process Standups, Sprint Review, Sprint
Retrospective)

I would encourage those interested in Agile

Service Management to develop a deeper
understanding of Scrum in order to internalize
the similarities between the process of
developing software and the process of
developing ITSM processes. You can download
the full Scrum Guide for free at
https://www.scrumguides.org/.
Click here or press enter for the accessibility optimised version

CHAPTER FIVE:
Agile Process
Engineering
Agile Process Engineering Agile Processes way possible. An agile process is easy to
understand, easy to follow, and prizes its

Engineering Agility is a state of mind that centers around

speed, collaboration and adaptability. Agility
collaboration and outcomes more than its
artifacts.
requires a conscious effort to limit delay,
Agile Processing Engineering overcome impediments and avoid unnecessary The characteristics of an Agile process include:
promotes a more adaptive complexities. Agility is where it is more
approach by: important to “be agile” than “do Agile” Having an accountable owner (Practice
Owner)
Breaking a monolithic process into an Since early ITSM adoption defined processes Clarifying everyone’s roles and responsibilities
architecture of independent that were designed to provide evidence of IT Allowing for self-regulation, with
microprocesses Governance and controls, some IT service consequences
Taking a holistic approach to building, management processes such as IT Change Benchmarking itself against Agile values and
maturing, and integrating related Management grew layers of bureaucracy that principles
microprocesses were accompanied by inherent delays and in Being as simple, lean, efficient, and expedient
Designing each microprocess in smaller, many cases a “one-size-fits-all” approach. While Being scalable
more frequent iterations the intentions were honorable, the resulting Adapting to change
Encouraging shortened feedback and processes were overburdened and not fit for the Optimizing automation for repetitive tasks
feed-forward loops purpose intended. If unchecked, even agile Encourages accountability and autonomy
Shaping future increments based on processes can become unwieldy particularly in Can be executed by people, other processes,
current business conditions large, regulated organizations looking to scale. or automation
Giving process practitioners more time to
absorb new behaviors An agile process is one that delivers “just Agile processes must be engineered much like
Getting more “done” and delivering value enough” structure and control to enable the software where interoperability in a complex
more quickly organization to achieve its service outcomes in system is essential.
the most expeditious, effective, and efficient
way possible. An agile process is easy to
Practices vs Processes

Taking a page from ITIL® 4, what was previously

represented as an ITSM process might today be
considered a broader “practice”. A service
management practice is a complete end-to-end
capability for managing a specific aspect of
service delivery (e.g., changes, incidents, service
levels).

Under Agile Service Management, a service

management practice is built on a microprocess
architecture.

Examples of practices or practice areas would

include:

Service Level Management

Change Management microprocesses, and automation that manage a In Agile Service Management, a practice is built
Release Management specific aspect of services – whether it's on an architecture of microprocesses that can
Incident Management managing changes or incidents, or requests. be defined, designed, implemented, adapted,
Looking at service management as a matrix of and improved independently. A Practice Owner
This is more than semantics. A service integrated and inclusive practice areas ensures is accountable for the service management
management practice is successful not that agility is embedded into every aspect of the practice and is an accountable collaborator on
because of a flat and linear flowchart but from organization’s value stream. the structure and use of the microprocess
the combined power of the people, architecture.
microprocesses, and automation that manage a
Microprocesses sequential series of activities that take an input integrated microprocesses that collectively
and produce an output. In a microprocess perform all of the activities necessary for an
A microprocess is a distinct activity that can be architecture, each activity delivers its own value end-to-end service management practice to be
defined, designed, implemented, and managed and can stand on its own. Its input can come successful. Microprocess activities could be
independently. A microprocess is generally from different sources and its outputs may be linear or nonlinear so that some are done in
associated with a primary service management inputs to another microprocess or even another parallel or be recursive..
practice but may be integrated with other service management practice.
service management practices. A microprocess As DevOps, containerization, cloud
can be defined as having its own inputs, For example, the first microprocess for IT architectures, and service management
outputs, activities, triggers, and defined Change Management might be about “recording practices have evolved, Agile Service
outcomes. It may have its own artifacts or be all changes”. This is a distinct activity with its Management has similarly evolved and now
part of one or more shared artifacts such as own inputs, outputs, activities, triggers. The decouples monolithic service management
plans, tools, or maps. benefit of having more transparency into practices into a microprocess architecture. The
changes would not only affect IT Change microservice architecture enables ITSM to
Microprocesses are the foundation upon which Management but would be useful to practice adapt to changing business requirements or to
an incremental and iterative approach to Agile areas such as Incident Management, Service improve discrete aspects of a process without
Service Management can be based. Treating Level Management, among others. Approaching having to re-engineer the entire process (but
service management activities as this activity as a microprocess also encourages with interoperability and integration always in
microprocesses allows the organization to build dialogue about how much is “just enough” detail consideration.)
service management practices in small, about each change to provide value. This
frequent releases that can deliver immediate microprocess could provide metrics on change A microprocess architecture is built on an
value to the overall ITSM goal. success, team velocity, etc. interrelated collection of microprocesses that
are:
Why are microprocesses important to service Microprocess Architectures
management? Traditionally, service Highly maintainable and testable
management practices are defined with a A microprocess architecture is a collection of Loosely coupled
sequential series of activities that take an input integrated microprocesses that collectively Independently deployable
Independently deployable
Have their own feedback loops
Interoperable with multiple processes
Organized around business capabilities
Owned by a small team

Microprocess Architecture
Service Management Architecture

The service management architecture will be a

matrix of integrated practices (and their
respective microprocesses) that collectively
ensure that services deliver the expected value
when and how they are needed. The service
management architecture supports systems
thinking and therefore strives to adapt to all of
the people, processes, automation, and
information that span the entire value stream.

Ownership of the Service Management

Architecture is a collaborative effort by the
individual Practice Owners who will collectively
adopt and integrate microprocesses and other
practices into their ITSM “recipe”.

Service Management Architecture

Click here or press enter for the accessibility optimised version

CHAPTER SIX:
An Agile Approach to
Process Engineering
Waterfall vs While the waterfall model is associated with
software development, earlier ITSM frameworks
deploy an entire end-to-end process
The learning curve that users will experience

Agile Process were authored when waterfall development and

project management were common so the
when trying to normalize an entire process
and its procedures

Engineering process design projects were built in a similar

cadence. While the bodies of knowledge behind
The risk that the resulting process will no
longer fit the needs of its customers or
ITIL® and other ITSM frameworks did not deliver on promised outcomes when and how
The waterfall model is a sequential necessarily promote a waterfall or bureaucratic needed
approach to software development approach, typical ITSM process roadmaps were
where each phase of the positioned as multi-year where one or two Agile Process Engineering promotes a more
development flows the project monolithic processes were defined, designed, adaptive approach by:
further downward until the product and deployed sequentially.
is built, tested, deployed and ready Breaking a monolithic process into an
to maintain. There are several challenges when applying a architecture of independent microprocesses
waterfall model to designing a complete service Designing each microprocess in smaller, more
management practice or even a microprocess. frequent iterations with its dependencies and
These include: successors in mind
Encouraging shorter feedback and feed-
The rigidity of a sequential approach forward loops
User feedback that comes late in the process Shaping future increments based on current
The delays, rework, and additional costs business conditions
resulting from user feedback and testing Taking a holistic approach to building,
errors maturing, and integrating related
The need for integration with processes not microprocesses
yet in design Giving users time to absorb and
The extensive time required to build and institutionalize new behaviors
deploy an entire end-to-end process Getting more “done” and delivering value
 Getting more “done” and delivering value experimentation, and stakeholder engagement. It is much easier to add to a practice or
more quickly Service Level Objectives will also likely be a microprocess gradually for scale than it is to
driving force. revert to a lighter level later. A MVP approach
The net result will be a service management ensures that the core elements and goals of a
practice architecture that delivers “just enough” To start, it is best to create a Minimum Viable practice or microprocess are discussed,
structure and control while Process (MVP). understood, designed and introduced first. It
strips away the “wants” from the “needs” and
Tying success measures to business Minimum Viable Process provides a basis for ongoing dialogue and
outcomes feedback so that future development will
Engaging stakeholders and soliciting input A Minimum Viable Process is the least amount provide continued value to those who rely on the
and feedback needed in order for this process or practice or microprocess.
Enabling effective communication microprocess to meet its Definition of Done.
Integrating with other processes and Every practice and microprocess should One of the other key advantages of starting with
frameworks therefore first strive to find its Minimum Viable a Minimum Viable Process is the ability to
Introducing timely improvements Process. experiment with microprocesses and remediate
Having simple documentation quickly if necessary. Not only is this in line with
Applying product management techniques Like a Minimum Viable Product in software the Three Ways of DevOps, but it also allows
over project management plans development, a Minimum Viable Process has MVP microprocesses to be designed and
three characteristics: deployed much more quickly. Minimum Viable
How much is “just enough” process? The Process is the launchpad for identifying “just
answer will vary from organization to 1. It has enough value that people are willing enough” and can be used for new or re-
organization, service to service, and practice to to use it initially engineered processes.
practice. Business requirements, governance, 2. It demonstrates enough future benefit to
risk, and compliance will be important factors. retain early adopters
Identifying the balance between “just enough” 3. It provides a feedback loop to guide future
and “too much” process will take time, capabilities
experimentation, and stakeholder engagement.
 tool for collecting incident data and to follow are executing the microprocess will help with
To find the Minimum Viable its progress?” the next iteration.
Process, you may want to start “How will we know this microprocess is
with this question: successful? Each MVP microprocess contributes to the
“What are the expected outcomes?” overall success of the service management
“What is the least amount that we would “How will this microprocess support the program. By taking an experimental, MVP
need to do in order for this practice or Incident Management practice as a whole and approach, the Practice Owners, Agile Service
microprocess to meet our immediate other service management practices?” Managers, and Agile Service Management Team
goals or requirements?” “Are there any risks or requirements that we continuously learn and improve.
are not considering at this point?”
Now that we have an understanding of the
Pick an easy microprocess that is a distinct While the questions are important, the dialogue basics, let’s go into more detail about adapting
activity that everyone recognizes such as is more important, particularly if the right people the roles, artifacts, and events of Scrum to Agile
documenting incidents. are asked the right questions. A skilled Practice Process Engineering.
Owner will be able to keep the Agile Service
Sample questions: Management Team and stakeholder
discussions focused on “least” and “minimum”
“What is the least amount of information that to avoid the risk of “just in case” complexity
we need to capture an incident? layers that make a process more difficult and
“What are the minimum time requirements for cumbersome.
when the incident should be recorded?
“What is the fastest, most efficient way of The Agile Service Management Team should be
communicating the incident to key comfortable deploying an MVP microprocess
stakeholders or teams that need to be quickly but must also recognize that the first
engaged? MVP release is likely not perfect. Soliciting
“What is the easiest and most sustainable constructive input and feedback from those that
tool for collecting incident data and to follow are executing the microprocess will help with
Click here or press enter for the accessibility optimised version

CHAPTER SEVEN:
Agile Service
Management Roles
Agile Service Scrum Role
Agile Service
Management Role
Characteristics of an Agile Service
Management Team

Management Product Owner Agile Product Owner An Agile Service Management Agile Service

Roles Open full table

Scrum Master in browser:
Agile Service Manager
Management Team is:

Self-managing
https://devops.turtl.co/story/the-agile-service-
The essence of Scrum is a small management-guide/page/11/1
Agile Service
Cross-functional and cross-skilled
team of flexible and adaptive Scrum Team Multi-domain
Management Team
people. Small teams then become Without egos or titles
part of the fabric of interactive and In Agile Service Management, there are three Without sub-teams
collaborative networks of humans clearly defined roles. Accountable for the work produced as a
that define, design, deploy and whole regardless of individual skills or
improve agile practices across the Agile Practice Owner experience
value stream. Agile Service Manager
Agile Service Management Team (the “Team”) A self-managing team understands what it
The same holds true for Agile takes to get things done. For each increment of
Service Management. Small teams A “Team” may be accountable for a single work, they are provided a goal, a backlog of
of people can focus on a microprocess or a complete service tasks, a completion date, and a clear and shared
microprocess as part of a network management practice. The Agile Service Definition of Done. The Agile Service
of other teams that are working on Management Team may also participate in Agile Management Team agrees on an approach for
microprocesses from the same or Service Management events for a related completing the work and meeting the goal.
different practice. practice or microprocesses. Essentially, the Agile Service Management Team
is given the “what”; they collectively determine
the “how.”
Successful self-managing teams are: NOTE: The Agile Service Management Team It is important to be realistic when first
MUST include a customer or practitioner establishing the goals, the Increments, and
Stable representative. planning the Sprint Backlog for any specific
Trusting practice or microprocess. Unlike Scrum for
Empowered Each member of the Agile Service Management software engineering, members of an Agile
Motivated Team will work on items from the Practice Service Management Team most likely have
Accountable Backlog. None are observers. other roles and responsibilities. The cadence of
Focused work may ebb and flow according to
Business-centric The Team should have at least three members dependencies on other teams, tools, or
Collaborative and communicative but no more than nine to ensure sufficient skills stakeholders. As Agile Service Management
Diverse and Inclusive and the ability to self-organize. Members may practices mature, the velocity of each Agile
Empathetic be on multiple teams, although it is Service Management Team will naturally
Quality driven recommended that an individual not work on increase as more microprocesses are built,
more than two Agile Service Management deployed, and integrated into the microprocess
Different perspectives and cross-functional Teams at any given time. architectures.
skills are essential to an Agile Service
Management Team. Roles should include a: Velocity The Agile Practice Owner

Agile Practice Owner Velocity is a metric that estimates how much of The Agile Practice Owner is accountable for the
Agile Service Manager the Process Backlog an Agile Service end-to-end results of the service management
Customer and/or process practitioner Management Team can handle in a single practice. Their key responsibility is to create,
Process architect Sprint. manage, prioritize and own the Practice
Tool administrator or software engineer Backlog. The Practice Backlog is the single
Change Manager Velocity is often measured by work source of current or future requirements
Scribe or Documenter accomplished during past Sprints and serves as including activities, tools, plans, interfaces,
a predictor of future Team performance. documentation, training, and improvements.
The Agile Practice Owner has ultimate authority and relevance of the practice assign one or more roles to oversee day-to-day
over the items in the Practice Backlog and execution. An Agile Practice Owner may also be
ensures that the items are clear and visible. This Additional responsibilities include: accountable for one or more related practices.
role understands how to prioritize items in the
Practice Backlog and helps the Agile Service Prioritizing items in the Practice Backlog The Agile Service Manager
Management Team understand the goals and Helps the Team to understand the goals and
objectives of the next Increment. The Agile objectives of the next Increment In the early days of ITIL®, an individual who
Practice Owner is the only individual who can Clarifying a Definition of Done for each possessed the most knowledge about service
change the Team’s direction and/or add, remove Increment or backlog item management strategies and tactics was
or cancel items in a Sprint. Inspecting the progress and status after each designated as a Service Manager. The same
Sprint holds true for the Scrum Master in Agile
The primary responsibilities of the Agile Identifying opportunities to optimize Software Development. Given the adoption of
Practice Owner are: automation and reduce manual activities multiple frameworks, tools, and methodologies,
Auditing and reviewing the practice on a the Agile Service Manager is tasked with
Setting and communicating the practice’s regular basis expertise on Scrum, Agile Service Management,
vision and practice goal Avoiding unnecessary layers of bureaucracy other service management frameworks, and
Ensuring the practice supports the needs of and complexity related practices. This individual is the subject
stakeholders and the Working with other Practice Managers to own matter expert, coach, and protector of the Agile
creation of value and ensure that the Service Management Service Management Team.
Staying informed about changes in business Architecture is aligned and efficient
direction and needs Responsibilities of the Agile Service Manager
Aligning the practice with other practices, The Agile Practice Owner is not necessarily include:
frameworks, and methods responsible for performing any or all of the
Ensuring that Agile values and thinking are tasks associated with managing a practice. Facilitating Agile Service Management events
embedded into the practice Depending on the size and complexity of the Helping the Agile Practice Owner create and
Measuring and assessing the value, quality, organization, the Agile Practice Owner may maintain a “just enough” architecture of their
and relevance of the practice assign one or more roles to oversee day-to-day practice
 practice The Agile Service Manager serves the Agile DevOps teams, Site Reliability Engineers and
Helping the Team understand, adopt and Practice Owner by: automation architects to ensure cross-
adapt Scrum and Agile Service Management pollination of taxonomy, tools and activities.
principles and methods Helping ensure the practice is in alignment Collaboration across multiple domains helps to
Ensuring that the Agile Service Management with other practices and supports value create and maintain a unified Agile, DevOps and
Team focuses on outcomes over artifacts streams ITSM/SRE culture.
Protecting the Team by removing Sharing techniques for effective Practice
impediments whenever possible so that the Backlog management
Agile Service Management Team is Helping ensure the processes reflect Agile
successful values and principles
Instilling agile thinking, empirical principles, Facilitating stakeholder collaboration as
Scrum knowledge, and ITSM objectives into requested or needed
the Team’s culture and behaviors
Most importantly, the Agile Service Manager
The Agile Service Manager does not manage protects the Team and does everything possible
the Agile Service Management Team. The Team to ensure its success. This includes helping
is self-managing. The Agile Service Manager is those outside the Team understand how to (and
a servant-leader that helps the Agile Practice how not to) interact with the Team. The Agile
Owner create a “just enough” architecture of Service Manager educates the organization on
Agile Service Management practices and Agile values, Scrum practices, ITSM processes,
microprocesses by maintaining an accurate and and the Agile Service Management approach to
relevant Practice Backlog. The Agile Service process design and development so that
Manager coaches the Team, helps the members everyone knows what to expect.
write effective process-related user stories, and
encourages them to think small but act big. The Agile Service Manager bridges a
relationship with developers, Scrum Masters,
DevOps teams, Site Reliability Engineers and
Click here or press enter for the accessibility optimised version

CHAPTER EIGHT:
Agile Service
Management Artifacts
Agile Service Scrum Artifact
Agile Service
Management Artifact
management practice exists. It is solely owned
and managed by the Agile Practice Owner.

Management Product Backlog Practice Backlog The form and format of the Practice Backlog is

Artifacts Increment Increment

not prescribed – entries can be captured in
anything from a Kanban to a spreadsheet to a
service management tool. It should be visible to
Open full table in browser:
Sprint Backlog Sprint Backlog all stakeholders and readily available for
https://devops.turtl.co/story/the-agile-service-
management-guide/page/12/1 inspection.
Burndown Chart Burndown Chart
The Practice Backlog and User
The Practice Backlog Stories

The Practice Backlog is a prioritized list of An Agile Service Management user story is a
everything that needs to be designed or simple statement that describes what a user or
improved for a service management practice process practitioner wants from an aspect of
including current and future requirements. the service management practice. It is always
written from the user’s perspective and in their
The Practice Backlog is the single source of words. It is not meant to include all of the
truth for a service management practice where details about the aspect but is intended to
each item is expressed first as a user story. It encourage further dialogue, detail and
includes activities, tool updates, plans, collaboration. User stories are generally
interfaces, documentation, training and captured on index cards or sticky notes
improvements. The Practice Backlog continually (physical or digital) but may point to more
evolves, is regularly re-prioritized and is never comprehensive documents or diagrams. The
complete. It exists as long as the service user story is generally written in business terms
management practice exists. It is solely owned and may evolve over time with collaboration.
and may evolve over time with collaboration. microprocess or procedure will be consumed, be refined as business conditions change.
by whom and what the expected value outcome
is. User stories are very powerful tools that The Agile Practice Owner and the Agile Service
User stories generally follow the formula: provide a wealth of insight in a single sentence. Management Team will determine when and
The Agile Practice Owner is responsible for how the backlog items should be reviewed and
“As a (role), I want to (do something) so I maintaining the Practice Backlog of user stories refined. As items become higher priorities, the
can (achieve something) and facilitating their refinement. amount of detail needed will become greater
and therefore refinement more necessary.
Epics Details can come from a variety of sources, but
In 2003, Bill Wake recommended the INVEST the Agile Service Management Team is
model to describe the elements of a good user An Agile Service Management epic is a responsible for updating the work estimates as
story collection of related user stories that may need important inputs into Sprint Planning.
to be worked on across multiple sprints. Most
Independent microprocesses would likely be considered an Each user story or epic in the Practice Backlog
Negotiable “epic” to accommodate multiple requirements. should be refined with at least the following
Valuable details:
Estimable Practice Backlog Refinement
Small A unique reference number for identification
Testable The Practice Backlog should be refined regularly and querying
to add detail, estimates and prioritization to the The primary stakeholders or customers
An Agile Service Management user story can be user stories or epics that comprise Practice An assigned priority
written for any aspect of the practice or Backlog items. The Practice Goal is also The estimated number of hours to complete
microprocess including an activity, a procedure, maintained in the Practice Backlog as a long- its design
a complete microprocess or process artifact. A term target for the service management Its dependencies and successors
process user story is the quickest and easiest practice that the Agile Service Management Who the story has been assigned to?
way to understand how the process, Team can use to help planning. This may also The anticipated Sprint that will include this
microprocess or procedure will be consumed, be refined as business conditions change. story
 story and can inspect progress during the Daily Backlog.
An approximate date of completion Scrum.
An Increment is considered finished when it
It is important to retain the spirit of the Agile The Sprint Backlog expires at the end of the meets the agreed Definition of Done. It is
Manifesto when entering or refining items in the Sprint – hopefully with all items completed. demonstrated and discussed during the Sprint
Practice Backlog. Keep the process as simple Outstanding items do not automatically carry Review. The Agile Practice Owner then decides
as possible and be wary of prioritizing the over to the next Sprint. They are reprioritized whether and when the Increment should or can
Practice Backlog items over the value of work with other Practice Backlog items and be released. If the Increment is part of an epic,
that the items will facilitate. considered during the next Sprint Planning. then it will be reviewed in line with the progress
of that epic.
The Sprint Backlog Increments
What’s the Difference Between an
The Sprint Backlog is a subset of the Practice An Increment is the potentially releasable Iteration and an Increment?
Backlog and forecasts what increment of the completed work that is the outcome of a Sprint.
service management practice or microprocess It is one element of a service management An increment is a potentially releasable piece of
will be tackled during the next Sprint. It is practice or microprocess. It may be an entire a service management practice or microprocess
created during Sprint Planning and documents microprocess or a discreet aspect of an epic or whereas an iteration is the repetition of building
all of the backlog items that will be necessary in service management practice. Increments are increments and microprocesses in an Agile
order to meet the Sprint Goal. It should be highly considered potentially releasable if they can Service Management way. Defining a process or
visible and available for inspection. deliver value. The increment could be an microprocess in increments allows it to be
enhancement, correction or an element of one designed gradually so that it is transparent,
The Sprint Backlog provides a central artifact or more microprocesses. The Increment is built adaptive and inspected (the pillars of Scrum).
around which the Agile Service Management upon user stories. Iterations are usually repeated as “sprints”. Each
Team can self-manage in order to meet the iteration of Agile Service Management (e.g., the
Sprint Goal. It should have enough detail so that The Increment and its outcome is defined sprints) enriches the practice either by adding
the Team understands the Definition of Done during Sprint Planning from items in the Sprint more value/ease of use or by removing manual
and can inspect progress during the Daily Backlog. work or toil.
work or toil.

The “Definition of Done”

The Agile Service Management Team and

process stakeholders must share an
understanding of the “definition of done” for
each Practice Backlog item, Increment or
microprocess. A service management practice
is never “done”.

The Definition of Done is critical to Sprint

Planning in that it defines when the increment is
complete. It guides how many user stories can
be added to the Sprint Backlog and reasonably
accomplished during a Sprint. As the Agile
Service Management Team’s velocity increases,
their ability to get more “done” in each Sprint will
also increase.
questions have been answered: outcomes been defined? (What)
When is an Increment Done? Are procedures easy to understand and do?
Have the benefits and value been defined and (How)
The Definition of Done will vary from Increment communicated? (Why) Have tools and automation been updated?
to Increment depending on the scope of work in Have roles and responsibilities been clarified? (Toil reduction)
the Sprint Backlog. Microprocesses should only (Who) Have policies been reviewed and updated if
be considered “done” when the following Have the inputs, outputs, triggers and necessary? (Consequences)
questions have been answered: outcomes been defined? (What) Have related Agile Service Management
 Have related Agile Service Management
Teams been informed? (Interoperability)
Have stakeholders been given a chance to
test? (Feedback)
Is it ready to stand on its own and deliver
value? (Go/NoGo)

In simple terms, the Definition of Done is when

the Team does not need to think about this
increment or microprocess anymore and the
completed increment should be potentially
shippable for release.

Other than the Practice Backlog (which is

owned by the Agile Practice Owner), all Agile
Service Management artifacts are owned by the
Team. The Agile Service Manager protects the
Agile Service Management Team, removes
impediments and provides expertise on service
management and Scrum but is not accountable
for managing the artifacts.
Click here or press enter for the accessibility optimised version

CHAPTER NINE:
Agile Service
Management Events
Agile Service Scrum Event
Agile Service
Management Event
Timeboxes

Management Practice/Microprocess
A Timebox is the maximum duration for each
event. The timebox range depends on the length

Events
Planning of the Sprint (usually less than one month).

Sprint Planning Sprint Planning

Event Timebox

The Sprint The Sprint

Planning Event Not timeboxed

Daily Scrum Process Standups Sprint Planning Event 2 to 4 hours

Open full table in browser:
Sprint Review Sprint Review
https://devops.turtl.co/story/the-agile-service- The Sprint 2 to 4 weeks
management-guide/page/13/1

Sprint Retrospective Sprint Retrospective Process Standups 15 minutes

Open full table in browser:

Sprint Review 2 to 4 hours
https://devops.turtl.co/story/the-agile-service-
management-guide/page/13/1
Sprint Retrospective 1.5 to 3 hours

Practice/Microprocess Planning

Deming’s Plan-Do-Check-Act model starts with

“Plan” for good reason – planning ensures that
the value and critical elements of a service
management practice or microprocess are
considered, discussed, resourced, and agreed
considered, discussed, resourced, and agreed
upon. Planning events fall into two primary
categories: Practice Planning and Microprocess
Planning. Regardless, planning events are not
optional in Agile Service Management and are
essential to ensuring that “minimum viable or
“just enough” are always in the spirit of the plan.
One of the most important outcomes of any
planning event is the metrics that will be used to
measure the progress or value of a practice or
microprocess.

Practice Planning

Service management practices (e.g., IT Change

Management) must be planned in order to
understand and create the underlying
microprocess architecture. This is particularly
important in order to understand and map the
order in which each microprocess will be
designed and the relationships between the
microprocesses both within and outside the
same service management practice. Practice or
microprocess planning should stay focused on or more Strategic Sprints. Attendees at must include business stakeholders and IT
high-level strategic aspects and would likely Practice/Microprocess Planning events would management since areas such as service levels,
span multiple events. The result should be one likely be more managerial than practitioner and resource allocation, business value, timelines,
or more Strategic Sprints. Attendees at must include business stakeholders and IT and financing would likely be discussed.
and financing would likely be discussed. should be concise, easy to understand, and (Value)
include a preliminary map of the microprocess Roles and responsibilities
Some of the areas to address during Practice/ architecture for that service management Timelines
Microprocess Planning include: practice. Relationship and dependencies with other
microprocesses and service management
The business value and benefit of the practice Microprocess Planning practices
Goals, objectives, inputs, and outputs of the Constraints
processes or microprocesses The primary goal of Microprocess Planning Policies and consequences
The microprocess architecture would be to answer this question: Major risks
Prioritization of microprocess design Communication
Expected integration and dependencies with “What is the least amount of effort available for Metrics
other practices and microprocesses this microprocess to deliver value to our
Stakeholders organization and our service management One of the risks of a microservice architecture
Automation opportunities (existing and practices?” is that each microprocess becomes more
potential) complex or cumbersome than necessary.
Regulatory, governance, or policy Microprocess planning is likely faster and less Remember, the goal is to define a “just enough”
requirements complex than practice planning since the focus state for any service management practice built
Major risks is on a single well-defined activity. upon an architecture of agile microprocesses
The “minimum viable” or “just enough” level to Microprocesses are small, easier to understand, that contribute to the overall speed and quality
meet goals visualize and therefore may be easier to identify of the practice and services. If each
Definition of Done a “minimum viable” plan for that activity. microprocess is not easy to execute, the entire
Metrics service management practice will become
Some other areas to be planned for a single unwieldy and bureaucratic.
The output of an early Practice Planning event microprocess would include:
should be a Practice Definition Document for Microprocess planning should not be done in
the specific service management practice. It What are we trying to achieve and why? isolation with the Agile Service Management
should be concise, easy to understand, and (Value) Team. Good planning requires the Agile Service
Team. Good planning requires the Agile Service Planning events are not timeboxed but should Define any dependencies or integrations with
Management Team to actively solicit input, take on the same Agile Service Management other microprocesses or practices
ideas, and feedback from those that will execute spirit of “just enough”. Clarify the Definition of Done for each backlog
the microprocess under a variety of item and the Sprint itself
circumstances. Whereas Practice Planning Sprint Planning Create a Sprint Backlog
usually engages management, microprocess
planning should include IT and business Sprint Planning is timeboxed for 2 to 4 hours Inputs to Sprint Planning include the Practice
practitioners. They are the best resources for which demonstrates the importance of proper Backlog, the past velocity of the Agile Service
identifying “minimum viable” or “just enough”, Sprint Planning. The Agile Service Manager Management Team, the availability of team
particularly when they are invited to be part of facilitates the event and the Agile Practice members and the dependencies on other
the solution. The same stakeholders should be Owner describes the next Increment or processes and tools. Only the Team can
invited to Sprint Reviews for microprocess microprocess to be completed. The entire Agile determine how much it can accomplish during
development. Service Management Team collaborates on the next Sprint.
planning the details of the next Sprint.
Planning events are not timeboxed but should Sprint Planning is also where the Team begins
The primary purpose of Sprint Planning is to: to self-manage by determining how they will
accomplish the Sprint Goal. They plan their
Establish the Sprint Goal approach and prioritize the items going into the
Define what increment of the Practice Sprint Backlog. By the end of Sprint Planning,
Backlog will be completed during the Sprint the Team should be able to articulate what they
Determine how the increment will be done are going to accomplish and how they are going
Ensure that the Agile Service Management to do it.
Team has all of the necessary skills and
resources for this Sprint The Sprint
Consider any automation opportunities or
requirements A Sprint is a fixed period of less than 4 weeks
Define any dependencies or integrations with during which the work needed to meet the
during which the work needed to meet the Sprint. microprocess are considered, Agile Service
Sprint Goal is performed. Other events including Management defines three basic types of
Sprint Planning, Process Standups, Sprint Agile Service Management embraces the Scrum Sprints.
Review and Sprint Retrospective all happen principle of being iterative and incremental.
within the Sprint. Every Sprint is considered an iteration that Sprint Type 1: Strategic Sprint
progresses the service management practice
The Team builds an increment from the Sprint forward in an incremental way. When one A Strategic Sprint is a timebox committed to
Backlog items that were agreed to during Sprint iteration is completed, another is planned and working on the critical high-level items in the
Planning. The Sprint is guided by the Sprint Goal repeated until all increments of the practice or Practice Backlog. These are usually the output
and the Definition of Done. microprocess are done. of Practice Planning. These items do not usually
appear on flowcharts, architectures, value
During the Sprint, the Agile Service Manager Sprint Types stream maps or other artifacts. Yet they are
keeps the Team focused, coaches the members essential for the service management practice
and stakeholders on Scrum and service Springs can be used for many different aspects and its microprocesses to be effective, efficient
management practices and protects the Team of engineering processes including: and sustainable.
from outside distractions. The Agile Service
Manager also removes impediments whenever Designing microprocesses and components Items accomplished during Strategic Sprints
possible. The Agile Practice Owner ensures that Identify requirements can include:
no one else attempts to change the Team’s Communication and Training
priorities or tasks during the Sprint. Benchmark current performance Creating a concise Practice Definition
Documentation Document to establish measurable goals and
No changes can be made to the Increment Tools and Automation objectives for the service management
during the Sprint that would endanger the Sprint Assess performance and continually improve practice
Goal. Progress is inspected during the Process Implementation Planning and allocating resources (human,
Standups. The Agile Practice Manager can technical and financial)
clarify any questions about the scope of the To ensure that all aspects of the practice or Inventorying and assessing existing tools
Sprint. microprocess are considered, Agile Service Creating new or updating existing policies
 Creating new or updating existing policies or an improvement or correction to a practice or level the service management practice or
Conceiving the microprocess architecture or microprocess based on Practice Backlog user microprocess to a “just enough” level. Sprint
defining relationships and dependencies stories. Planning for a CSI Sprint is particularly
Identifying and mapping stakeholders and important in order to discuss, resource and
practitioners The Increment to be completed during an prioritize improvements.
Drafting communication plans Increment Sprint should be identifiable, logical
and be considered potentially shippable
Strategic Sprints follow the rules of any other depending on its nature. It should not be a
type of Sprint. They are guided by a Sprint Goal, random collection of Practice Backlog items
agreed Definition(s) of Done and produce an that are not interrelated. There should be a clear
Increment that is demonstrated during a Sprint Definition of Done and Sprint Goal for an
Review. Increment Sprint.

Strategic Sprint iterations are not necessarily Sprint Type 3: Continual Service
sequential. Strategic Sprints can be planned Improvement (CSI) Sprint CSI Sprints should be regularly planned
when they make sense to do so but always after throughout the lifecycle of the practice or
the first Practice Planning event. Planning A CSI Sprint commits a cycle of work to microprocess to maintain or increase agility and
integrated Strategic Sprints for related practices implementing prioritized improvements from to ensure that services are being managed
or microprocesses may help to ensure the Practice Backlog for a service management according to speed and quality expectations of
alignment and integration. practice or a microprocess. the end consumer.

Sprint Type 2: Increment Sprint A CSI Sprint is usually undertaken as part of One caution: Change fatigue can occur when
Agile Process Improvement. It is an opportunity too many changes are made to a practice or
An Increment Sprint is planned in order to to adapt the input and feedback from prior microprocess in rapid succession. The risk is
complete an Increment that could be a whole sprints, stakeholders, practitioners and particularly strong after a new microprocess or
microprocess, a piece of a microprocess or epic customers. A CSI Sprint is a good opportunity to practice is introduced or re-engineered. It is
or an improvement or correction to a practice or level the service management practice or extremely important to allow time for people to
extremely important to allow time for people to “Standup” demonstrates that the event is opportunity to meet the Sprint Goal and get
adapt to a new way of working with ample time intended to be short and not necessarily seated. more done. Fifteen minutes during an active
for feedback and ideas. While there will likely be Sprint is usually time well spent.
no shortage of comments or suggestions about Because the Team is not necessarily working on
a newly implemented process, it is important to the Agile Service Management sprint full-time, The Sprint Review
collect and analyze all input and feedback to the timing of Process Standups may not be daily
recognize patterns and anti-patterns. but should at least be held weekly. The Sprint Review is timeboxed for 2-4 hours
and is attended by the Team and stakeholders
Defining different types of Sprints is offered During the Process Standup, each Team or customers. It is an important opportunity for
solely for the purpose of ensuring that all member in turn shares: transparency, inspection and adaptation (the
aspects of the service management are pillars of Scrum). It is facilitated by the Agile
addressed. There is no limit to the number or What they have accomplished since the last Service Manager.
frequency of each type of Sprint or the order in standup
which they are done. There may also be other What they are going to do before the next During the Sprint Review, the Team
Sprint cycles that do not fall into a particular standup demonstrates the aspects of the practice or
type and are just iterations to progress the What obstacles are in his/her way microprocess that were engineered during the
service management practice forward. last Sprint. The Team shares the challenges
While observers and stakeholders may attend, they faced, successful resolutions and
Process Standups Team members are the only ones allowed to outstanding issues. The Agile Practice Owner
speak. Questions are not allowed during the explains the current state of the practice or
The Process Standup is timeboxed for 15 timebox. The Agile Service Manager facilitates microprocess and the Practice Backlog. The
minutes during an active Agile Service the event. Agile Practice Owner also describes any
Management sprint. It is not a status meeting feedback received from practitioners about any
but a frequent opportunity to inspect progress The importance of a Process Standup should previously released Increments. A decision on
towards the Sprint Goal and identify not be undervalued – the faster deviations and whether the current Increment will be released
impediments as quickly as possible. The term impediments are identified, the greater the is made.
“Standup” demonstrates that the event is opportunity to meet the Sprint Goal and get
The Sprint Review allows the Team and Should An Increment or Review is whether or not to release the
stakeholders to discuss the next steps for the Microprocess be Released? Increment. While releasing aspects of service
microprocess or practice as input to the next management processes incrementally gives the
Sprint Planning. One of the key decisions made during the Sprint organization time to adopt and adapt to new
Review is whether or not to release the behaviors, there are several considerations that
behaviors, there are several considerations that feedback to influence future Increments Tools
should be discussed including whether Helping the practice adapt to changing Logistics
requirements as it is slowly being matured The Definition of Done
The increment stands alone on its own merit or Identifying and aligning dependencies on Internal and external communications
enhances or improves another increment: other processes Input and feedback from stakeholders
Encouraging an integrated approach to Velocity
The organization is ready and receptive service management
It won’t confuse practitioners Keeping tools relevant and updated The Sprint Retrospective is timeboxed for 1.5 to
It does not add extra toil while waiting for Finding the right level of “just enough” ITSM 3 hours and is facilitated by the Agile Service
automation Manager. While the temptation may be to go
It delivers business value Sprint Retrospective from the Sprint Review directly into the next
There is no risk to its dependencies and Sprint Planning, it is important for the Team to
related practices or microprocesses The Sprint Retrospective is an internal take the time to review and discuss their past
Metrics have been adjusted if needed opportunity for the Team to reflect on and performance. Incremental improvements will
The Increment will not affect the accuracy or inspect the progress and organization of the absolutely increase the Team’s maturity and
validity of data or reporting last Sprint. In some ways, it resembles the form velocity.
It does not contribute to “change fatigue” and format of a blameless post-mortem review
in that it addresses: Sprint retrospectives have to be inclusive and
Some of the benefits of releasing an Increment blameless. Everyone’s input and feedback is
include: What did we do right? important so long as it is constructive and well-
What could we have done better? intentioned.
Changing organizational behaviors one What have we learned?
increment at a time (maybe making ITSM What will we do differently next time?
easier) In the spirit of continual improvement, the
Capturing more data or information Team also discusses
Shortening feedback loops and using Team composition and skill sets
feedback to influence future Increments Tools
Click here or press enter for the accessibility optimised version

CHAPTER TEN:
Agile Process
Improvement
Agile Service Since Agile Service Management is loosely
based on Scrum and its basis in empirical
surveyors of how the practice or microprocess
is delivering value in the form of quality IT

Improvement thinking, Agile Process Improvement aligns with

Scrum’s three pillars of Transparency,
services.

Inspection, and Adaptation. Agile Process Improvement can be applied to

Not surprisingly, engineering agility any service management practice or
into a service management Agile Process Improvement’s goal is to ensure microprocess regardless of the frameworks or
practice the first time around is that service management practices and methods used.
easier than maintaining a “just microprocesses are not:
enough” structure in the long term. Agile Process Improvement Reviews
If left unchecked, microprocesses Bureaucratic
can become complex and Unclear Agile Practice Owners should plan regular
bureaucratic over time. There is Constrained surveillance reviews of their service
also a risk that people will revert to Time-consuming management practices and microprocesses.
old ways and potentially there will Irrelevant The Agile Service Manager would facilitate the
be “not enough” or too many Circumvented review and provide guidance on Agile, ITSM, and
variations on the microprocess Nice on paper, but… Agile Service Management best practices.
architecture to meet the
organization’s goals. The leap from Remember, Agile Service Management The review is an important opportunity to
“just enough” to “too much” practices and processes are purely theoretical connect again with stakeholders, practitioners,
process can seem to happen until someone actually performs the tasks. It is and the Agile Service Management Team. In
almost overnight. The drift can therefore extremely important to plan a review some cases, a formal audit demonstrating
result in confusion, more toil, cycle while keeping an open line of control or for ISO/IEC certification purposes
delays, and lower quality services. communication with practitioners. Those that may be necessary but Agile Process
are actually doing the work and are measured Improvement no longer addresses the topic of
for their personal success are the best formal ITSM audits.
surveyors of how the practice or microprocess
The Goals of Agile Process work known as toil. the Agile Practice Owner understand how to
Improvement keep or improve the value of the process in the
Be sure to include a cross-section of business management of IT services. The Agile Service
Identify and eliminate waste and bottlenecks and IT managers, practitioners, and suppliers Manager would facilitate the reviews and assist
Detect practice or microprocess drift who regularly engage with the practice or the Agile Practice Owner in collecting and
Benchmark against Agile values and microprocess. evaluating the output in line with Agile values
principles and principles and ITSM guidance.
Scale up or back to “just enough” structure Sample questions include:
and control The improvement suggestions collected as part
Ensure alignment with other microprocesses Is this practice or microprocess simple to of the Agile Process Improvement review should
and practices understand and apply? If so, how? If not, why? take the form of User Stories and be added to
Confirm ongoing relevance and value creation Is it timely? the Practice Backlog for prioritization and
Ensure ease of use How does it help (or hinder) your job potential inclusion in upcoming CSI Sprints.
Solicit input and feedback from practitioners performance?
and stakeholders How does it enable the management and One of the key advantages of Agile Service
Improve effectiveness, efficiency, and agility quality of services? Management is that the microprocess
Is it relevant to the current business architecture makes conducting reviews easier
Agile thinking encourages us to value customer environment? and more accessible than in traditional end to
interactions over processes and tools. Agile How does it work with other practices or end ITSM processes.
Process Improvement embraces that spirit by microprocesses?
ensuring that the voice of the customer is Are there any manual tasks that you think we Thinking of microprocess reviews as more of a
instilled into improvement efforts. Focus can or should automate? check-in than an audit helps the Agile Practice
groups, surveys, and face-to-face discussions How can we improve the flow, value or ease Owner develop a reasonable and achievable
are the best way to draw out suggestions, of use of this practice or microprocess? review cycle, particularly when there are a
challenges, and insight. It is also a great way to greater number of microprocesses in use.
clearly identify waste and the manual, repetitive Conducting a 360-degree surveillance will help
work known as toil. the Agile Practice Owner understand how to
There are certain events or situations that would and lessons learned both within the Team and ensures that each of these are reviewed against
be appropriate for an Agile Process to stakeholders. all three criteria to maintain a “just enough”
Improvement review: level.
Clear roles and responsibilities and tools that
About a month or two after a microprocess match new or existing rules are essential.
release
Quarterly for microprocesses, annually for Other ways to sustain Agile Process
service management practices improvements include:
When a related microprocess is released
When automation is being considered or Continue allocating resources to continual
introduced for one or more tasks improvement
When a formal audit is required Hire, promote and develop employees and
Whenever it is beneficial to do so managers who support the vision
Provide ongoing training to existing
Sustaining Improvements employees
Conduct regular reviews and audits
It is important to take a holistic approach when Innovate – take calculated risks
making improvements sustainable. Start by Claim and promote the wins
baselining “as is” performance so that
performance changes can be monitored. Agile Process Improvement is an essential
element of continuous service improvement and
Feedback should be solicited when new scaling for ITSM. A service management
microprocesses are released or changes to practice could be effective (gets the job done),
existing microprocesses are made. Actively efficient (least amount of effort) but not
listen to and act on complaints and necessarily agile (flexible, adaptable, plays well
suggestions. Communicate successes, failures with others). Agile Process Improvement
and lessons learned both within the Team and ensures that each of these are reviewed against
Click here or press enter for the accessibility optimised version

CHAPTER ELEVEN:
Automation and Agile
Service Management
Automation and Agile Service Management invites automation
into the Agile Service Management Team to
microprocesses. The Agile Service Manager
should assess tools and automation across the

Agile Service help instill an engineering mentality when

defining and designing practices and
entire organization to identify ways to optimize
and integrate existing tools. Avoiding replication

Management microprocesses. Automation expedites the

identification of “just enough” structure and
of effort and engaging others in dialogue about
similar goals and mutual enablement also
control, particularly when the automation supports cultural transformation.
Automation reduces toil by produces the results without the human effort.
consistently performing repetitive Automation not only facilitates Agile Service Most of the ITSM tools have also recognized the
tasks that allows humans to do Management’s alignment with other practices need to be more agile and have introduced
more productive, innovative and such as Continuous Delivery, DevOps and Site integrations, enhancements or new features
satisfying work such as weighing Reliability Engineering, the use of consistent and that make the work of IT easier and faster. The
evidence, solving problems, automated controls may also help demonstrate rise of artificial intelligence and machine
making decisions and using their governance, risk management and compliance. learning are helping these efforts.
skills, judgment and experiences.
Automation also supports: Some automation opportunities to consider:

More frequent releases ITSM suites (some of which have Agile

Fewer errors modules)
Higher quality IT services Automated builds, testing, staging and
Improved security and risk mitigation deployment
Faster recovery from incidents Monitoring, observability and event
Increased business and customer management
satisfaction Dashboards
Metrics and analytics
Intelligent automation requires intelligent Cloud native applications and cloud
microprocesses. The Agile Service Manager infrastructure
 infrastructure
Flowcharts and drawing
Kanban tools
Value Stream Management tools
Product Management to track user stories
and the Product/Practice Backlog

Rely on the knowledge and experience of those

that do a job when assessing tool selection. Be
careful to avoid discussions that turn into a
“favorite tech” talk. This can lead to
implementing multiple tools that do the same
thing because of personal preferences. While
people will typically be more productive with
tools they know, the automation landscape is
constantly changing so it is unrealistic to expect
that the tools in use today will be the same tools
in use for years to come.

Despite all of the above, it is important to note

that technology alone will not instill agility into
an organization particularly as it relates to
service management. As the Agile Manifesto
reminds us, we should not prize the artifacts
(tools) over the outcomes (higher quality
services).
Click here or press enter for the accessibility optimised version

CHAPTER TWELVE:
Getting Started
Getting Started Value Stream Management obvious answer is “it depends”. Version 2 of
ITIL® described 11 processes that grew to 26 in
The starting point of any Agile, DevOps, or version 3 and 34 in ITIL® 4. The Site Reliability
Agility does not happen overnight. service management initiative should be the Engineering books describe XXX of key
Regardless of which Agile, DevOps, mapping, negotiation, and agreement of the practices. Does an enterprise have to implement
SRE, or ITSM frameworks that an organization’s value streams. This increases all? Of course not. Most enterprise IT service
organization adopts, moving from everyone’s awareness of how value is delivered management programs focus on 10-15 core
a traditional ITSM approach to an to customers in the form of services. Not only practices that have the highest impact on the
Agile Service Management does Value Stream Management increase flow quality of service. Please avoid process for
approach is a journey that takes by helping to eliminate waste, delays, or process’ sake.
practice and perseverance. bottlenecks, it is an excellent engagement tool
Humans require time to absorb for overcoming some of the cultural constraints In my opinion, essential service management
change, normalize and excel at that have plagued development, operations, practices include
new ways of working. It is security, ITSM, and the business. Aligning Value
therefore essential that the Scrum Stream Management with service management Service Level Management
values of Commitment, Focus, is a solid recipe for success and can instill a IT Change Management
Respect, Openness, and Courage common mindset, common processes, Release Management
are embraced and demonstrated in common vocabulary, and a common Configuration Management
Agile Service Management understanding of what value means to the end Incident Management
environments. customer. Problem/Root Cause Management
Event Management/Monitoring
How Many Service Management Request Management
Practices and Microprocesses Are Capacity and Performance Management
Needed? Knowledge Management
Information Security Management
This is a tricky question – and of course, the Business Continuity Management
obvious answer is “it depends”. Version 2 of
Start simple and stay simple. Pick one service Most importantly, remember –
and one service management practice. Identify regardless of what service
an Agile Practice Owner, Agile Service Manager, management framework you adopt
the Agile Service Management Team, or customize, it is always more
stakeholders, and practitioners. Capture user important to “be agile” than “do
stories into a Practice Backlog. Plan your Agile.”
Sprints. Experiment and learn. Measure
constantly. Engage with your customer
community and encourage feedback.
Continually look for ways to reduce toil through
engineering. Create a cycle of review and
refinement. Avoid bureaucracy and change
fatigue.

Don’t rush. Start with a Minimum Viable

Process and move forward from there.
Introduce the new or improved practice in small,
frequent increments. Give the organization time
to absorb, adopt and adapt to new behaviors.
Mature the processes holistically and
organically. Small, short-term wins will deliver
greater wins in the long term.
Click here or press enter for the accessibility optimised version

APPENDIX:
Agile Service
Management
Taxonomy
Agile Service Management Taxonomy

TERM DEFINITION

A
A project management method for complex projects that divides tasks into small “sprints” of work with frequent
Agile
reassessment and adaptation of plans.

A formal proclamation of four key values and 12 principles to guide an iterative and people-centric approach to software
Agile Manifesto
development.

The aspect of Agile Service Management (Agile SM) that applies the same Agile approach to process design as
Agile Process Engineering
developers do to software development.

Agile Process Improvement The aspect of Agile SM that aligns Agile values with ITSM processes through continuous improvement.

Open full table in browser:

Agile Service Management (Agile SM) ensures that IT service management processes reflect agile values and are
https://devops.turtl.co/story/the-agile-service-management-guide/page/17/1
Agile Service Management
designed with “just enough” control and structure to enable the delivery of services that enable the ability to do
(Agile SM)
TERM DEFINITION

Agile Service Management A team of at least 3 people (including a customer or practitioner) that is accountable for a single microprocess or a
Team complete service management practice.

An Agile Service Management subject matter expert who is the coach and protector of the Agile Service Management
Agile Service Manager
Team.

C
Continuous Delivery A software development practice where software is always in a releasable state.

D
Definition of Done A shared understanding of what it means for work to be complete.
Open full table in browser:
https://devops.turtl.co/story/the-agile-service-management-guide/page/17/2
A cultural and professional movement that stresses communication, collaboration and integration between software
Devops
TERM DEFINITION

I
Increment Potentially shippable completed work that is the outcome of a Sprint.

Set of best practice publications for IT service management. Published in five core books representing the five
ITIL® stages of the IT service lifecycle: Service Strategy, Service Design, Service Transition, Service Operation and
Continual Service Improvement.

INVEST A mnemonic was created by Bill Wake as a reminder of the characteristics of a quality user story

K
Kanban A method for visualizing and communicating workflow in order to reduce or eliminate work in progress.

L Open full table in browser:

https://devops.turtl.co/story/the-agile-service-management-guide/page/17/3

The goal of lean thinking is to create more value for customers with fewer resources and less waste. Waste is
TERM DEFINITION

M
A distinct activity that can be defined, designed, implemented and managed independently and is generally associated
Microprocess with a primary service management practice. A microprocess may be integrated with other service management
practices.

A collection of integrated microprocesses that collectively perform all of the activities necessary for an end-to-end
Microprocess Architecture
service management practice to be successful.

The most minimal version of a product that can be released and still provide enough value that people are willing to
Minimum Viable Product
use it.

P
A four-stage cycle for process management and improvement attributed to W. Edwards Deming. Sometimes called the
Plan-Do-Check-Act
Deming Cycle or PDCA.

A prioritized list of everything that needs to be designed or improved for a process including current and future
Practice Backlog
requirements. Open full table in browser:
https://devops.turtl.co/story/the-agile-service-management-guide/page/17/4

Practice Owner Role accountable for the overall quality of a service management practice and owner of the Practice Backlog.
TERM DEFINITION

Practice/Microprocess A high-level event to define the goals, objectives, inputs, outcomes, activities, stakeholders, tools and other aspects of
Planning Meeting a process. This meeting is not timeboxed.

Process Interrelated work activities that take specific inputs and produce specific outputs that are of value to a customer.

Process Customer A recipient of a process’ output.

Process Standups A daily timeboxed event of 15 minutes or less for the Team to re-plan the next day of work during a Sprint.

An ongoing process of adding detail, estimates and order to backlog items. Sometimes referred to as Product Backlog
Product Backlog Refinement
grooming.

Product Owner An individual who manages the Product Backlog and ensures the value of the work that the Team performs.

R Open full table in browser:

https://devops.turtl.co/story/the-agile-service-management-guide/page/17/5

A non-timeboxed event that establishes the goals, risks, features, functionality, delivery date and cost of a release. It
TERM DEFINITION

S
A simple framework for effective team collaboration on complex projects. Scrum provides a small set of rules that
Scrum create “just enough” structure for teams to be able to focus their innovation on solving what might otherwise be an
insurmountable challenge.

Scrum Components Scrum’s roles, events, artifacts and the rules that bind them together.

Scrum Guide The definition of Scrum concepts and practices, written by Ken Schwaber and Jeff Sutherland.

ScrumMaster An individual who ensures that the Team adheres to Scrum practices, values and rules.

Scrum Team A self-organizing team consisting of a Product Owner, Development Team and ScrumMaster.

A set of fundamental values and qualities underpinning the Scrum framework:; commitment, focus, openness, respect
Scrum Values Open full table in browser:
and courage.
https://devops.turtl.co/story/the-agile-service-management-guide/page/17/6

The management principle that teams autonomously organize their work. Self-organization happens within boundaries
TERM DEFINITION

Service Management A complete end to end capability for managing a specific aspect of service delivery (e.g., changes, incidents, service
Practice levels).

Sprint A period of 2-4 weeks during which an increment of product work is completed.

Sprint Backlog Defines the work that must be completed during the Sprint.

Sprint Goal The purpose and objective of a Sprint, often expressed as a business problem that is going to be solved.

A 4-8 hour timeboxed event that defines the Sprint Goal, the increment of the Product Backlog that will be done during
Sprint Planning Meeting
the Sprint and how it will be done.

A 1.5-3 hour timeboxed event during which the Team reviews the last Sprint and identifies and prioritizes improvements
Sprint Retrospective
for the next Sprint.

A timeboxed event of 4 hours or lessfull

Open where
tablethe
in Team and stakeholders inspect the work resulting from the Sprint and
browser:
Sprint Review
update the Product Backlog.
https://devops.turtl.co/story/the-agile-service-management-guide/page/17/7

A 2-4 week timeboxed Sprint during which strategic elements that were defined during the Process Planning Meeting
TERM DEFINITION

T
Timebox The maximum duration of an event.

U
A statement written from the user’s business perspective that describes how the user will achieve a goal from a feature
User Story
of the product. User stories are captured in the Product Backlog.

V Open full table in browser:

https://devops.turtl.co/story/the-agile-service-management-guide/page/17/8
Velocity How much Product Backlog effort a team can handle in a single Sprint.
TERM DEFINITION

W
Waste Any activity which does not add value to a process.
Open full table in browser:
https://devops.turtl.co/story/the-agile-service-management-guide/page/17/9
Waterfall A linear and sequential approach to software development.
Click here or press enter for the accessibility optimised version

About the Author

Jayne Groll, CEO of DevOps Institute
About the Author
Jayne Groll is co-founder and CEO of the DevOps Institute whose mission is to advance the Humans of DevOps.
Jayne was also one of the founding partners in ITSM Academy, spending over 15 years educating and speaking on
IT Service Management, ITIL®, ISO 20000, and process design.

Jayne has had an extensive IT Operations career starting with implementing and managing Service Desks to
leading IT organizations across multiple verticals. She achieved her ITIL® V2 Service Manager certification (with
distinction) in 2005 and later her ITIL® V3 Expert. She is also a certified ScrumMaster.

Jayne is a recognized thought leader, author, and speaker in the ITSM, DevOps, and SRE communities.

Jayne Groll
About DevOps Institute
DevOps Institute is a professional member association. Our mission is to advance the human elements of
DevOps. We create a safe and interactive ecosystem where members can network, gain knowledge, grow
their careers, lead and initiate, and celebrate professional achievements. We inspire thought leadership and
knowledge by connecting and enabling the global member community to drive human transformation in the
digital age. www.devopsinstutite.com

Membership at DevOps Institute

Professional memberships include unlimited access to the Assessment of DevOps Capabilities (ADOC) for
your team or organization, discounts on exams, the latest DevOps insights and research, and access to
career-advancing resources. You’ll also get valuable benefits to keep you informed, like custom views of our
annual Upskilling DevOps Skills report. Plus, get access to exclusive member offers and discounts when you
join. Learn more.
Click here or press enter for the accessibility optimised version

Thank you for reading

The Agile Service

Management Guide
Copyright © 2021 by DevOps Institute. All rights reserved.

Cookies [ 1 ] [ 2 ] Terms [ 1 ] [ 2 ] Privacy [ 1 ] [ 2 ] POWERED BY