Professional Scrum Team, The (The Professional... (Z-Library)

The Professional
Scrum Team
9780134862156_web.indb 1 06/10/20 8:04 PM

The Professional Scrum Series by
Visit informit.com/scrumorg for a complete list of available publications.
T he Professional Scrum Series from Pearson Addison-Wesley and

Scrum.org consists of a series of books that focus on helping
individuals and organizations apply Scrum and agile leadership to
improve the outcomes of customers and organizations. Approaching
the challenge from different perspectives, each book provides
deep insights into overcoming the obstacles that both teams and
organizations face as they seek to reap the benefits of agility.
All Scrum.org proceeds from the series go to Year Up, an organization

whose mission is to close the Opportunity Divide by providing urban
young adults with the skills, experience, and support to empower them
to reach their potential through professional careers and education.
Make sure to connect with us!

informit.com/socialconnect
ScrumOrg_Series_page_7x9_125.indd 1 8/12/2019 8:31:13 AM
9780134862156_web.indb 2 06/10/20 8:04 PM

The Professional
Scrum Team
Growing and Empowering
Cross-Functionality and Resiliency
in a Complex World
Peter Götz
with contributions by
Uwe M. Schirmer and
Kurt Bittner
Boston • Columbus • New York • San Francisco • Amsterdam • Cape Town

Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City
São Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo
19 8:31:13 AM
9780134862156_web.indb 3 06/10/20 8:04 PM

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as
trademarks. Where those designations appear in this book, and the publisher was aware of a trademark
claim, the designations have been printed with initial capital letters or in all capitals.
The authors and publisher have taken care in the preparation of this book, but make no expressed or
implied warranty of any kind and assume no responsibility for errors or omissions. No liability is
assumed for incidental or consequential damages in connection with or arising out of the use of the
information or programs contained herein.
For information about buying this title in bulk quantities, or for special sales opportunities (which may
include electronic versions; custom cover designs; and content particular to your business, training goals,
marketing focus, or branding interests), please contact our corporate sales department at corpsales@
pearsoned.com or (800) 382-3419.
For government sales inquiries, please contact governmentsales@pearsoned.com.
For questions about sales outside the U.S., please contact intlcs@pearson.com.
Visit us on the Web: informit.com/aw
Library of Congress Control Number: 2020944449
Cover design and illustration by Sabrina Love
Page 59: Architecture pretzel, Stefan Toth, Vorgehensmuster für Softwarearchitektur,
3rd Edition, 978-3-446-46004-1, 2019, p. 17.
Page 176: "Culture is an . . . in these groups." Tylor, Edward. Primitive Culture, Vol. 1 (1871).
Copyright © 2021 Peter Götz, Uwe M. Schirmer, and Scrum.org
All rights reserved. This publication is protected by copyright, and permission must be obtained from
the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any
form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information
regarding permissions, request forms and the appropriate contacts within the Pearson Education Global
Rights & Permissions Department, please visit www.pearson.com/permissions/.
ISBN-13: 978-0-13-486215-6
ISBN-10: 0-13-486215-5
ScoutAutomatedPrintCode
9780134862156_web.indb 4 06/10/20 8:04 PM

Contents
Foreword xi
Introduction xv
Acknowledgments xxi

About the Authors xxv
Chapter 1 Being an Effective Scrum Team 1

Collaboration Between Product Owner and Development Team 3
Don’t Separate Business and IT 4
Taking Responsibility for a Valuable Product 5
Collaborative Product Backlog Management 6
Sprint Scope Isn’t Fixed 7
The Product Owner Is Present 8
Creating Transparency as a Scrum Team 10
Hypothesis-Driven Product Backlog 11
Product Backlog Drives Conversation 12
Seeing the Big Picture 14
Product Backlog Items Need to Create Value 15
Sprint Backlog Is More than a Task Board 16
Who Should Update the Sprint Backlog? 17
The Sprint Backlog Should Not Be Hidden 18
Sprint Backlog as Status Report 19
9780134862156_web.indb 5 06/10/20 8:04 PM

Contents
Work Burndown Is Rarely Perfect 20

Preventing Sprint Backlog from Growing Stale 21
Done Is Releasable 23
Measuring and Verifying Value in a Product 23
Summary 25
Chapter 2 Common Problems 27

Missing Basics 29
Early Stumbles with Scrum 29
Missing Common Values 31
Missing Product Vision 34
Missing Cross-functionality on the Scrum Team 35
Missing Self-organization 36
Common Misunderstandings about Scrum 38
Sealing the Sprint 38
Committing Scope 39
Too Many Meetings? 41
No Stakeholder in Sprint Review 43
Scrum Is Not a Religion 45
Avoidable Errors 46
Scrum Master in Name Only 46
Too Many Product Backlog Items 48
Licking the Cookie 50
Unavailable Product Owner 51
A Daily Scrum Twice a Week? 53
Summary 54
Chapter 3 Scrum Is Not Enough 55

Strategy: Take Care of the Big Picture 56
Who Is Solving Strategic Problems in Scrum? 57
What Is Emerging Structure? 58
Why #NoDocumentation Is a Bad Idea 61
Tactics: Work from Idea to Result 62
The Different Levels of Abstraction of a Product Backlog 63
How to Estimate Meaningfully 65
Do We Need Scrum When We Have Kanban? 67
vi
9780134862156_web.indb 6 06/10/20 8:04 PM

Contents
How to Measure Success 70

How to Improve Cross-functionality 71
Collaboration Is an Improvement Driver 71
Does Everyone Need to Do Everything? 73
Using a Test-First Approach 76
Coping with Constant Change 77
Why Refactoring Is Not Optional 78
Fix Small Problems Before They Become Big Problems 80
Work with Principles, Not Rules 81
Summary 83
Chapter 4 Releasable Is Less Than Released 85

What Is DevOps? 86
It’s a Role . . . It’s a Tool . . . It’s DevOps 86
How Does DevOps Relate to Tools? 88
Is DevOps Enough? 89
How to Combine Scrum and DevOps 91
Is DevOps Replacing Scrum? 91
Does Scrum Allow Continuous Deployment? 92
Scrum Principles and DevOps Culture Complement Each Other 95
How to Improve Flow Using DevOps 97
Summary 99
Chapter 5 Resolving Conflict 101

Conflict That Can Be Solved by People Involved 102
Not All Disagreements Result in Conflict 102
Who Has the Last Say? 104
Conflict Should Be Solved by the People Involved 106
Conflict That Needs Outside Intervention 107
Healthy Conflict That Escalates 108
Some Conflict Needs to Be Uncovered 111
Be Loyal to the Scrum Team or to Your Department? 113
Toxic Conflict That Needs Stronger Intervention 114
Putting Pressure on the Scrum Team 115
Alter a Team to Protect It 117
Summary 119
vii
9780134862156_web.indb 7 06/10/20 8:04 PM

Contents
Chapter 6 Measure Success 121

Working Toward Goals 122
We Need to Deliver Faster 122
Are We Delivering Value? 124
What Is Value? 126
The Experiment Loop 129
Improving Team Results 132
Velocity Is Not Performance 132
How to (Not) Incentivize Performance 134
You Can’t Improve What You Can’t Measure 137
Monitor Improvement, Not Measures 139
Summary 141
Chapter 7 Scrum and Management 143

The Role of Management in Scrum 144
Transparency Is Not Surveillance 144
Responsibility Is Not Control 146
How to Enable Self-organization 148
Leading Is Not Directing 149
Self-organization Is Not Absence of Management 150
Self-organizing Is Not Easy 151
Summary 152
Chapter 8 The Agile Organization 153

Organizational Structures Can Either Help or Hinder Scrum 154
New Work, Old Environment 154
Functional Organizations Can Block Team Growth 156
Functional Organizations Provide Career Paths But at a Cost 157
Complex Organizations Need Radical Simplicity 159
Scrum Can Help Enable Radical Simplicity 159
Radical Simplicity Requires Radical Transparency 161
Replace Reporting Chains and Governance Processes
with Transparency 162
Break Down Silos and Align around Customer Value 163
Summary 164
viii
9780134862156_web.indb 8 06/10/20 8:04 PM

Contents
Chapter 9 Continuous Improvement Never Stops 167

How to Keep Improvement Continuous 168
F.A.I.L.: First Attempt in Learning 168
We Have Improved Everything We Can Already 170
Does a Scrum Master Become Obsolete? 172
Retrospectives as the Driver for Improvement 173
Reinforcing the Positive 174
Focus on a Single Improvement 174
Shift the Organization’s Culture over Time to Improve Focus 176
Will Scrum Ever Be Complete? 176
When Are We Done Implementing Scrum? 177
How to Use Scrum Once the Product Is Live 179
Scrum Doesn’t Need Outside Expertise 181
Summary 182
Bibliography 183

Index 185

ix
9780134862156_web.indb 9 06/10/20 8:04 PM

This page intentionally left blank
Foreword
We live in complex times. Technology has helped us bring the world together,
enabling us to knit together complex supply chains and collaborate with col-
leagues across the globe. At the same time, this same technology seems, at
times, to outpace our ability to harness it for good. To meet the challenges
and seize the opportunities of this modern world, our view of work must
shift from it being a standard set of managed tasks, performed by specialists
and coordinated by management to deliver value, to an organization charac-
terized by empowered teams whose members collaborate openly to fluidly
adapt to new challenges.
At the heart of this new organization are teams of creators focused on deliv-
ering value to customers. At the heart of Scrum is also a team—the Scrum
Team. Being part of an effective, high-performing team is one of the most
rewarding and powerful benefits of Scrum. A great team will succeed in the
face of great challenges and will often deliver what others thought impossible.
But the Scrum Guide provides very little guidance for how Scrum Team mem-
bers work together to deliver value. For many teams, Scrum exposes chal-
lenges in working together to which the team is unaccustomed. Overcoming
these challenges can be frustrating to teams new to Scrum because it exposes
xi
9780134862156_web.indb 11 06/10/20 8:04 PM

Foreword
the teams’ shortcomings but does not help them fix them. These teams can
sometimes feel that “Scrum won’t work for us.” They struggle with questions
such as “How do you build a great team?” and “What does it mean to be a
member of a Scrum Team?”
This book answers those questions. It describes the new rules of the game
for being part of a high-performing team. Peter, Uwe, and Kurt explain what
a Scrum Team is and how Scrum Teams deliver value. They describe,
through an extended case study, the challenges and opportunities of working
in this new way. The book paints a comprehensive picture of the future of
teamwork, never glossing over the difficulties of working with others. The
underlying principles are based on the fundamentals of Scrum and the ideas
of professionalism.
Fundamental to this journey are the following:
• Empirical process: An approach that is rooted in learning by doing and

•
adaptation based on that experience. This book describes what that means
to a team, and how team members work together to learn and grow by
delivering in small increments, measuring the results, and inspecting and
adapting as they proceed.
• Self-organization and empowered teams: What sets apart creative,
•
empowered teams from their merely average peers is their ability to
determine, for themselves, how they work, how they organize, and how
they make decisions. But just telling a group of people they should self-
organize does not suddenly make it so; self-organization is a complex team
skill that takes time to learn and master. This book provides practical
guidance on how to help teams grow their effectiveness.
• Continuous improvement: Scrum helps teams to continuously improve their
•
product, but it also helps them to continuously improve themselves, their
way of working, and their skills. This book describes where and when
retrospection and improvement happen.
xii
9780134862156_web.indb 12 06/10/20 8:04 PM

Foreword
In this context, professionalism means building on this foundation in the

following four dimensions:
• Discipline, in learning from delivering valuable product increments about

•
how the team approaches its work and in improving the value the team
delivers to customers. This book describes approaches that a Scrum Team
can apply from day one. It also highlights the difference between how
discipline was realized in the industrial age and how it is realized in today’s
complex world.
• Behaviors, in the way that team members work together and with the rest
•
of the organization. The Scrum values were introduced to the Scrum Guide
in 2017 in response to the need for a supporting culture for Scrum to be
successful. They describe five simple ideas that, when practiced, encourage
an agile culture: courage, focus, commitment, respect, and openness. These
values help teams and their organizations understand how they should
work. But values are often ephemeral and indistinct; this book explains
how those values become real for the Scrum Team.
• Value, or the change in outcomes and experiences that Scrum Teams deliver
•
to customers and stakeholders. The job of a professional Scrum Team is to
do the right thing for all these parties by providing a solution that best
meets its customers’ needs within the constraints it must operate. In this
book, we see the challenges of exposing our understanding of the value and
how the Scrum Team supports its stakeholders.
• Community, in the way that Scrum Team members work with each other
•
and with others in their organization and profession to learn new skills and
share experiences. Helping to scale the agility of the community is not
entirely altruistic because the helper often learns valuable things that he or
she can bring back to help the team. In the final chapters of the book,
Peter, Uwe, and Kurt discuss what it means to an organization and how to
scale the ideas across teams.
Professional Scrum is hard, not because the ideas are hard, but because it
requires persistence, focus, and dedication to not let the day-to-day realities
get in the way. In this book, Peter, Uwe, and Kurt have provided a collection
of materials to help the Scrum Team deliver value and feel happy doing it.
xiii
9780134862156_web.indb 13 06/10/20 8:04 PM

Foreword
The world we live in is full of complex problems. Solving complex issues

requires teams—and teams of teams—to work together in an effective way.
Increasingly, the skills described in this book are going to be table stakes for
any organization, institution, or society.
Good Luck on the Journey.
—Dave West
CEO and Product Owner, Scrum.org
xiv
9780134862156_web.indb 14 06/10/20 8:04 PM

I ntroduction
There are many good books about Scrum. Most of them focus on one specific
aspect, such as the Scrum Framework or the specifics of a Scrum role. Others
explain a specific tool or practice, such as User Stories, that make working in
Scrum easier.
Many of these books are excellent, but we have found that none of them
really prepares people for how their day-to-day work will change when they
are a member of a Scrum Team. Our intent in writing this book is to convey
that day-to-day experience and to provide you with the insights you will need
to become a better Scrum Team member.
Pu r pos e of Thi s B ook

This is a book for people working on a Scrum Team. The Scrum Guide is
right: “Scrum is simple to understand, but difficult to master.”1 The hard
part for people on a Scrum Team is working together on a daily basis.
Mastering the intense collaboration that successful Scrum demands is a
1. https://scrumguides.org/scrum-guide.html#definition
xv
9780134862156_web.indb 15 06/10/20 8:04 PM

Introduction
holistic challenge, not one specific to one aspect of the framework or of a

supporting tool.
Our goal in writing this book is to help people working in Scrum Teams to
use the framework to improve their way of working and delivering valuable
products. We describe common problems that Scrum Teams face and actual
solutions that we have seen, and we discuss typical solutions that may help
you with similar challenges.
We recommend that you look at these case studies as examples from which
you can learn. We do not share them as solutions to copy, and you will proba-
bly have to adapt their lessons for your specific context. We share them to
stimulate introspection and discussion with your team members. They will
provide you with discussions of alternatives and their benefits and drawbacks,
and they will leave it to you to decide what to do.
We don’t intend for this book to be an introduction to Scrum; if you don’t

already know about Scrum, you should read the Scrum Guide or attend a
class about Scrum; you might even want to get some hands-on experience
working with Scrum. If you have a solid basic understanding of Scrum and
want to help your team improve its ability to work together using Scrum, keep
reading.
Who S hou ld R e a d This B ook

This book is for everyone who works on a Scrum Team. You will be able to
connect to the challenges described and can use the ideas presented here to
find your own way of working in a Scrum Team. People new to the frame-
work will benefit from not going through the same hard lessons that others
have already mastered successfully. Experienced Scrum practitioners will
receive additional perspective on common challenges and how to cope with
them.
This book might also be interesting for people working with Scrum Teams
but who are not part of one. If you fit in this category, learning about the
xvi
9780134862156_web.indb 16 06/10/20 8:04 PM

Introduction
elements of successful team collaboration and how to meet team challenges

should be helpful. You will learn about the kind of environment Scrum needs
in order to be applied successfully.
Whether you are an experienced practitioner of Scrum or still quite new to

the framework, you should know the elements and rules of Scrum as
described in the Scrum Guide. This book assumes that you are familiar with
the values and principles of Agile and Scrum.
H ow Thi s B ook I s O rga nize d
This book tells a story about a Scrum Team and how the team members work
together to overcome common challenges to delivering valuable working prod-
uct Increments. It talks about their learnings while using Scrum and how they
are able to optimize their way of working together. It uses a combination of
case study narrative and related discussion to first introduce a particular chal-
lenge that Scrum Teams encounter and then explore alternative approaches to
overcoming that challenge.
You should read this book from front to back in order to follow the story. The
chapters follow this outline:
Chapter 1, “Being an Effective Scrum Team,” introduces the Scrum Team and
describes how it works. This chapter highlights the collaboration between
Development Team and Product Owner. The Product and Sprint Backlogs
and the product Increment are the tools that create the transparency needed
in a fast-changing environment. This chapter demonstrates how these tools
help the Scrum Team members plan and organize their work.
Chapter 2, “Common Problems,” addresses some of the common reasons

why novice Scrum Teams that have gained some experience with Scrum some-
times think Scrum doesn’t work. Most of the reasons for this conclusion have
to do with a mechanical way of implementing Scrum. Teams are going
through the motions but don’t know enough about the reasons for specific
rules of Scrum or tools that they use.
xvii
9780134862156_web.indb 17 06/10/20 8:04 PM

Introduction
Chapter 3, “Scrum Is Not Enough,” talks about strategy and Product Backlog
refinement. It also talks about cross-functionality and constant change. The
Scrum Guide describes the framework with which a team can solve complex
adaptive problems. Scrum Teams have to find and define their own way of
working and tools they want to use to be successful.
Chapter 4, “Releasable Is Less Than Released,” describes the ideas of

DevOps and how they relate to Scrum and help to further improve the efforts
of a Scrum Team. The most important outcome of a Scrum Team is the
product. The Scrum Guide calls it “releasable product Increment.” While this
is the minimum requirement, more and more teams are able to continuously
release into production.
Chapter 5, “Resolving Conflict,” explores the inevitable fact that when people
work closely together, conflict will arise. Some level of conflict is normal and
healthy; however, it can escalate and become a problem for the team and the
organization. This chapter describes sources of conflict and how to solve
them.
Chapter 6, “Measure Success,” discusses metrics that can be used by a Scrum

Team as well as how metrics can be misused and lose their value as a result.
Organizations want to know how well their parts are doing. Measuring per-
formance and success is an important component of this kind of insight.
Chapter 7, “Scrum and Management,” focuses on the role of management

and its importance for a Scrum Team. It describes common challenges that
traditional management faces in an agile environment. You will see how to
overcome them.
Chapter 8, “The Agile Organization,” describes the type of organization a

Scrum Team needs to operate in. It discusses common conflict areas between
traditional organizations and Scrum Teams, such as hierarchies and thinking
in projects, not products. You will see what needs to happen in order for our
Scrum Team to work together successfully.
xviii
9780134862156_web.indb 18 06/10/20 8:04 PM

Introduction
Chapter 9, “Continuous Improvement Never Stops,” stresses the fact that

improvement in Scrum is called “continuous” for a reason. Becoming a Scrum
Team is never done, and a transition toward Scrum never ends.
Please don’t use the story told here as a blueprint of how Scrum should be—
it isn’t one. Our team explores Scrum and makes the same or similar deci-
sions as we have seen in real teams. These decisions are sometimes wrong and
have to be corrected later. Scrum has to be explored and experienced. There is
no defined single way to implement it.
We wish you much fun exploring this book and, hopefully, Scrum.
Keep calm and Scrum on.

—Anonymous
Register your copy of The Professional Scrum Team on the InformIT site
for convenient access to updates and/or corrections as they become avail-
able. To start the registration process, go to informit.com/register and
log in or create an account. Enter the product ISBN (9780134862156)
and click Submit. Look on the Registered Products tab for an Access
Bonus Content link next to this product, and follow that link to access
any available bonus materials. If you would like to be notified of exclu-
sive offers on new editions and updates, please check the box to receive
email from us.
xix
9780134862156_web.indb 19 06/10/20 8:04 PM

Acknowledgments
It takes a village to raise a child.

—African proverb
I believe this proverb is true for children. In the past few years I have learned
that it is true for books as well. It really takes a lot of people to make a book
happen. There are a few who I would like to point out especially, as they were
crucial in the making of this book.
First of all, I would like to thank Uwe Schirmer for his collaboration on the
book. We have worked together from the very first idea for this book to its
end. Uwe and I wrote the first draft of this book together (which you should
be glad you never had to read) and during this process we learned a lot about
how not to write a book. It is a pity that Uwe’s busy schedule didn’t allow
him to work on the second draft of our book with as much dedication as we
both would have liked. I appreciate the time and support he gave me and am
very thankful for it.
xxi
9780134862156_web.indb 21 06/10/20 8:04 PM

Acknowledgments
Next, I thank Kurt Bittner for his guidance and contributions to the book.
Kurt helped Uwe and me to get started with the first draft and then supported
me actively during the writing of draft two. I have learned a lot about writing
and the English language from you. I am amazed how fast you were able to
work through the text and provide feedback that was constructive, helpful,
and to the point. Thank you for taking an even more active part in the last
stages of writing and for your contributions to the chapters about manage-
ment and organizations.
I also want to thank Scrum.org for all their support, especially Ken Schwaber,
David West, Sabrina Love, and Eric Naiburg. Dave, thank you for sharing the
idea for this book series with me, and thank you especially for writing the
Foreword to the book. Ken, thank you very much for panning the first draft.
Without it, Uwe and I wouldn’t have been able to improve on our results and
we wouldn’t have learned about the benefits of early feedback as effectively.
Thank you for your co-creation of Scrum and for being an inspiration.
Sabrina, thank you very much for your designs. Not only for this book, but
also for each time we Scrum.org trainers have a good idea for a visual but
have no clue how to make it work. I especially love your idea for the cover
image. Eric, your help around what this book could be about and who would
like to read it is really appreciated.
Without our expert reviewers this book would not be what it is today. They
offered tons of great advice and were spot-on and direct with their feedback.
Thank you very much Helen Sedlmeier, Oliver Hankeln, Jürgen Mohr, Mikkel
Toudal Kristiansen, Thomas Barber, Svenja Trampisch, Thomas Schissler,
Marc Kaufmann, and Kim Nena Duggen. I was always amazed how much
valuable input you added to something that I thought was already “done.”
My colleague Stefan Toth generously allowed us to use his visual for the
architecture pretzel. Thank you very much for this metaphor, which I only
dare to use right before lunch as it always makes me hungry.
Special thanks go to Pearson and everybody there who helped make the book
possible and polished it. I guess they make up the majority of the “village”
that it takes to produce a book, and I can only imagine how many have
xxii
9780134862156_web.indb 22 06/10/20 8:04 PM

Acknowledgments
supported those who collaborated directly with Uwe, Kurt, and me.
Therefore, I want to thank our original editor Chris Guzikowski and our cur-
rent editor Haze Humbert, who have given advice and support and were our
direct contacts at Pearson.
Finally, I want to especially thank my wife and three children for the patience
they had with me during the writing of this book. It turned out that “it
shouldn’t be very much work” was a lie . . . who would have guessed?
xxiii
9780134862156_web.indb 23 06/10/20 8:04 PM

A bout the Authors
Peter Götz is a consultant, trainer, and coach. He began his career as a Java
software developer in 2001 and moved into consulting in 2006. He is also a
Professional Scrum Trainer for Scrum.org and has been assisting teams as a
Scrum Coach since 2008. As one of the stewards for the Professional Scrum
Developer training, he maintains and develops the course material and learn-
ing path. He is passionate about software architecture and DevOps and likes
to discuss ways to improve the work Scrum Teams do by using modern archi-
tectural styles and engineering practices to improve flow. Peter lives near
Munich with his wife and their three children, and he only has hobbies that
start with b: brewing beer, baking bread, and beekeeping. He tried sailing
once but could enjoy it only when he realized he was sitting in a boat. Find
him on Twitter as @petersgoetz or visit his website, https://pgoetz.de/.
Uwe M. Schirmer is a certified Scrum expert, software architect, project man-

ager, and requirements engineer. He has been involved with computers since the
1980s. After two professional educations, he studied computer science at the
University of Applied Science in Fulda, Germany. Since 1996, he has worked as
a trainer, and since 2000, he has worked as a consultant for different customers
and projects. Today, he works as an Agile Coach and Software Architect at
xxv
9780134862156_web.indb 25 06/10/20 8:04 PM

About the Authors
Accenture | SolutionsIQ, where he helps to modernize organizations without

losing sight of the product, quality, and architecture of their applications and
infrastructure. His main interests are agile software development, emergent
design and architecture, documentation of software architectures, DevOps,
developing teams, and the evolution of organizational cultures. He lives with
his wife, three children, and four chickens near Frankfurt, Germany.
Kurt Bittner has more than 35 years of experience helping teams to deliver
software in short feedback-driven cycles, as a developer, as a product man-
ager, and Product Owner; as an industry analyst; and as an organizational
change agent. He is the co-author of numerous books on software engineer-
ing, in addition to many blogs and articles. He is currently the series editor
for the Scrum.org book series published by Pearson.
xxvi
9780134862156_web.indb 26 06/10/20 8:04 PM

B eing an E ffective
S crum Te am 1
In this chapter, you meet the case study team, a Scrum Team working on
management software for medical offices. The team is in the middle of its
twelfth Sprint and already has some experience working with Scrum.
The Product Owner and Development Team collaborate as self-organized

entities inside the Scrum Team, using the Product and Sprint Backlogs to plan
and organize their work. Collaboration creates the transparency needed for
continuously improving their way of working and their work results. The
purpose of this chapter is to show you a team that is working well together
so that you know what effective teamwork looks like in Scrum. It provides
you with a baseline for how Scrum is supposed to work before we explore the
challenges and describe situations that may feel more familiar to you.
“Our Sprint Backlog looks good,” one of the developers says. “We have implemented
all of the features from our Sprint Backlog and are currently finishing the last tests.”
It is the day before the Sprint Review, where the Scrum Team (consisting of the
Product Owner, the Development Team, and a Scrum Master) will share the
9780134862156_web.indb 1 06/10/20 8:04 PM

Chapter 1 Being an Effective Scrum Team
results of its current Sprint with the stakeholders. This team works for a company
that sells management software for medical offices. The Development Team is
discussing its current work and planning the last steps toward the Sprint Goal.
The Product Owner has joined them, as she is very curious about the state of
affairs. She also wants to check whether the Development Team needs anything
from her. After the Development Team finishes its Daily Scrum, she asks the team
members if they can stay for another few minutes and discuss some questions with
her. Two team members want to look after the remaining tests in order to prepare
for the Sprint Review, but the rest of the team stays for a quick exchange.
“Our Sprint Goal was to implement a first version of the new registration process
for new patients and integrate it into our application. Will we be able to show this
tomorrow?” the Product Owner asks.
“Yes, the integration has already been done in our test environment, and it looks
good,” one of the developers answers. “We also made sure that the new process is
enabled by configuration so that we can test it with our advanced users first. As soon
as you want to roll out the feature to every user, we can remove the configuration
and switching logic. We already prepared an item in the Product Backlog for this.”
“But we didn’t talk about this extra work in our refinement meeting earlier this
week, did we?” the Product Owner asks.
“No, we didn’t realize that it was necessary until after that meeting. We can
discuss it next time, but it should be quick, since this is a mostly technical change,”
another developer adds.
The Product Owner nods and seems satisfied. Then another question comes to her
mind. “Last week, we discussed a change in the process with one of our users. Do you
remember? Will it be included in the product Increment we will show tomorrow?”
“Yes, we were able to implement this change. It is good that we discussed that
change early on, so no rework is necessary,” one of the frontend developers says.
“Thanks for checking the early preview last week.”
“No problem. I am always happy to see the first results and share them with our
users for early feedback,” the Product Owner says. “Thanks for your time. I look
forward to seeing you in the Sprint Review tomorrow.”
This interaction between the Development Team and Product Owner demon-
strates how a Scrum Team is supposed to work: They work in Sprints toward
their common goal. Their short-term driver is the Sprint Goal that they create
together at the Sprint Planning of every Sprint. The team members collabo-
9780134862156_web.indb 2 06/10/20 8:04 PM

Collaboration Between Product Owner and Development Team
rate among themselves but also work closely with their stakeholders. They all
take on their responsibility and try to improve the overall situation, regardless
of their job title.
The rest of the chapter takes a closer look at this collaboration.
Coll a bor ation B et w e e n Product Ow ne r and

D e v e lopm e nt Te am
Scrum Teams are self-organizing and cross-functional.
—Scrum Guide
(https://scrumguides.org/scrum-guide.html#team)
This quote describes the essence of being a Scrum Team.
Self-organization is the natural way that nearly everything works, but many
people have lost touch with this way of working. Nature comprises individual
self-organizing entities that form larger self-organizing entities. Scaling a
complex environment, such as a school of fish, a forest, or our worldwide
flora and fauna, is only possible by self-organizing.
Consider self-organization on a smaller scale. A self-organizing team can react to

changes in its environment, such as changes in the goals they want to achieve, the
work they are trying to do, or how they work together. Our customers often ask us
how a Scrum Team should act in a given situation. How should the Development
Team act in a Sprint Review? Should the Scrum Master interfere in a specific situa-
tion, and if so, how? Is the Product Owner part of the Daily Scrum, and if so,
how? We usually answer that the team self-organizes around “that”—where that
can be almost anything from what tools to use to how to describe a backlog item.
The reason we recommend self-organizing is that the people doing the work are
the most competent and capable to make decisions that affect the work.
Self-organization will happen only when there is no predefined solution to a

problem. Consider the preceding example: Is the Product Owner part of the
Daily Scrum? What would be the benefit? What might be an issue? If you
could choose, what would you do, and why? By answering these questions, a
team can find its own solution—it self-organizes.
9780134862156_web.indb 3 06/10/20 8:04 PM

The second, but equally important, attribute of a Scrum Team after self-
organization is cross-functionality. A cross-functional team has all the
competencies and skills to deliver a valuable working product Increment. The
team members collaborate to use their different areas of expertise to the best
effect. In highly specialized working environments, deep skills and knowledge
in one area are important; however, one person alone typically cannot create
meaningful and valuable results for customers. Our customers, business
domain, and technology become ever more complicated—even complex—and
we have to understand them as well as we can in order to make the best deci-
sions possible. Therefore, integrating work done by different experts and
making it valuable to customers is key to being successful. This integration
and tight collaboration is enabled by a cross-functional team.
The litmus test of whether a Scrum Team is truly cross-functional is its ability
to deliver a valuable working product Increment every Sprint. If the team can-
not do that, it might need to find people with the missing skills or increase
the skills and knowledge in the existing team members.
Together, those two attributes are the killer feature of a Scrum Team. Self-
organization without cross-functionality could lead to local optimization
without the big picture in mind. Cross-functionality without self-organization
could lead to a powerful team that is unable to react to influences from the
outside world. To be honest, though, the latter is hard to imagine, as a truly
cross-functional team usually needs a certain amount of self-organization in
order to become cross-functional.
D on’t S e pa r ate B usine ss a nd IT

In many of the companies we work with, we see a game of business versus IT.
Business wants to fulfill the needs of its customers. It has some ideas on what
those needs are and how to satisfy them. Since business wants to provide
maximum value to its customers, it would like IT to deliver faster.
IT needs to provide functional and stable infrastructure and systems. Its goal
is to ensure long-term consistency and reliability. Therefore, IT needs to make
9780134862156_web.indb 4 06/10/20 8:04 PM

sure that changes to the system can be made without side effects that threaten
this long-term goal.
Everybody sees their part of the overall picture, but they do not see others’
parts. The result is silo thinking and an us-versus-them mentality.
This scenario ties back to the importance of cross-functionality and being a

true team. Organizations that cannot create this team mindset are likely to
face negative consequences. Putting our own family or tribe first has been
beneficial in the past. It was a way to create a common culture and strong
social bonds among the individuals, bonds we did not feel for the “outsiders.”
Yet even in a multinational company with several thousand employees, we
have to work toward common goals, and we have to collaborate. This is pos-
sible only if we identify with the people we work with and for. In Scrum,
these are our Scrum Team members, our internal and external stakeholders,
and our customers. An us-versus-them mentality leads to boundaries and bar-
riers and prevents collaboration and empathy.
Another important aspect is feedback. The theories that business has about
its customers’ needs and how to satisfy them may or may not be true. Above
all, a business needs quick feedback regarding its hypotheses. The precondi-
tion for this is collaboration and a common understanding.
Compare a company operating under a business versus IT model with the

Scrum Team introduced at the beginning of the chapter—a team in which
the members are aligned in their common goal and work together to achieve
the goal. It’s not about which “tribe” we belong to, IT or business, but
about the common goal we try to achieve.
Taking R e s pon sibilit y for a Va lua ble Product

The Development Team in the previous scene is preparing for the upcoming
Sprint Review. It does not work on “requirements” that have to be fulfilled
but instead reaches for a larger goal that improves the lives and work of the
customers.
9780134862156_web.indb 5 06/10/20 8:04 PM

This includes filling the gap of open questions and discussing them with the
Product Owner. The Development Team could have just implemented the reg-
istration process for new patients and called it a day. Instead, it took responsi-
bility for the big picture. The team thought about how to roll out the new
process to its customers and consequently added configurability to the system.
Too many teams we have worked with would have focused only on the accep-
tance criteria and therefore would have been very surprised by a question from
the Product Owner on how to roll out the new functionality with the least risk.
Coll a bor ativ e Product Bac k log M a n ag e m e nt

The Development Team in this example even took the liberty of adding a clean-
up item to the Product Backlog. Isn’t this the Product Owner’s job? No, it isn’t.
The Product Owner is accountable for optimizing the value created with the
Product Backlog. This doesn’t mean she is the only person allowed to propose
value-optimizing ideas. Scrum Teams and their stakeholders benefit from collabo-
rating on the content, using different insights, and refining those insights.
Of course, some Product Owners prefer to have full control over their Product
Backlog and are willing (and able) to be the only Product Backlog manager. As
long as it doesn’t create a bottleneck that impedes feedback and collaboration,
this is fine. Other Product Owners we have worked with have opened the Product
Backlog for everyone and created rules around adding Product Backlog items.
One example is that everybody involved or interested in the product can add
items to the Product Backlog. Those items have to be explained to and
reviewed by the Product Owner soon after their creation. Otherwise, the
Product Owner removes the item after a set amount of wait time. From that
time on, the Product Owner refines and orders the Product Backlog item as
necessary in order to optimize value.
These examples are but two ways of handling the Product Backlog and the cre-
ation of new items. Every Product Owner has to find his or her own way of
using the Product Backlog to foster the right conversations at the right time.
9780134862156_web.indb 6 06/10/20 8:04 PM

S print S cope I s n’t Fix e d

Often, Scrum Teams claim that everything that will be worked on has to be
selected and planned during Sprint Planning. Every change to this scope is
seen as a violation of the sacred Sprint Plan. Scrum is a framework for
solving complex adaptive problems. In a complex environment, more is
unknown than is known. This means that you have to face those unknowns at
any time and react to them. Sprint Planning tries to create a sufficient under-
standing of the problem and how to solve it. With this understanding, a
Scrum Team is able to align on and work toward the Sprint Goal.
Clarifying and deciding open questions in the Sprint has value. It reduces the up-
front work that might be wasted if you find out that things have to be changed
late in the process. Options have value until the so-called last responsible moment.
This is a point in time when the act of not deciding hurts more than making a
decision that turns out to be wrong and that has to be changed later.
The Development Team did the right thing when, after receiving early user
feedback during the Sprint, it implemented a process differently than had been
agreed on during Sprint Planning. The team didn’t change the plan because it
could, but because it was able to increase value with this change. Not changing
the course would probably have hurt the entire Scrum Team in the end.
L a s t Re s p o n s ib l e M o m e n t
Concurrent software development means starting development when
only partial requirements are known and developing in short iterations
that provide the feedback that causes the system to emerge. Concurrent
development makes it possible to delay commitment until the last
responsible moment, that is, the moment at which failing to make a deci-
sion eliminates an important alternative. If commitments are delayed
beyond the last responsible moment, then decisions are made by default,
which is generally not a good approach to making decisions.
—Mary and Tom Poppendieck, Lean Software Development:
An Agile Toolkit
Decisions reduce options. Every decision you make means a “yes” to one alterna-
tive, but a “no” to all the others. Decisions made too early may eliminate valuable
9780134862156_web.indb 7 06/10/20 8:04 PM

options at a point in time when you have the least knowledge about the issues at
hand. Often, you don’t have enough information and knowledge about them to en-
able you to make the best decision.
The important point of deciding at the last responsible moment is that you make
the decision before important options become unavailable. Not deciding can lead
to worse results than making a wrong decision that has to be corrected.
A decision at the last responsible moment creates a learning window that you can
use to learn more about the decision and its alternative options (see Figure 1.1).
You should actively use the time to fill gaps in your understanding and create the
foundation of a better decision.
We agree on
a last responsible Last Responsible
moment Moment
time
We find out
about a decision Learning Window
to be made
Figure 1.1 Learning window
The last responsible moment is not a concrete point in time, it is a metaphor.

Therefore it is often not possible to exactly define this point in time. The point
is to actively and explicitly agree on a point in time where you think not deciding
is more harmful than not deciding at all. This needs experience that can only be
gained by practice. So try to define the last responsible moment and improve your
judgment on those moments you judged wrong.
This also means that the Development Team could add a yet-unclear Product
Backlog item to the Sprint to be clarified during implementation. When a
Development Team is confident that it will be able to implement something
during the Sprint, this makes it “ready” for a Sprint.
Th e Product O w ne r I s Pr e s e nt
The Product Owner in the opening scene is interested in the progress of the
Development Team. She wants to know about details they discuss and deci-
sions they make so that she can actively support them.
9780134862156_web.indb 8 06/10/20 8:04 PM

Many Product Owners see their main responsibility as creating a clear and
transparent Product Backlog. To do this, they discuss and align stakeholder
needs and formulate requirements, often in the form of User Stories. The User
Stories are then briefly discussed by the Product Owner and the Development
Team to get an estimate in Story Points. In Sprint Planning, the Development
Team has one last chance to ask clarifying questions and then has to make its
commitment.
This dysfunctional way of fixing Product Backlog items prior to a Sprint

usually leads to problems. The Development Team tries to clarify all of its
open questions, which increases the up-front effort of backlog refinement.
Some questions are not evident to the Development Team before it starts
working, and so they can’t be taken into account during refinement and
estimation. This leads to the Product Owner’s assumption that every
question is answered but leaves the Development Team wondering if this
is the case.
In Scrum, the Product Owner and Development Team should collaborate as

much as needed in order to optimize product value. This starts with the
Product Owner aligning and consolidating the different needs of the stake-
holders. It continues with refinement to create a mutual understanding of
why the Product Backlog item is important. Refinement also clarifies the
expected outcome and what needs to be done in order to reach it. Refinement
doesn’t stop with Sprint Planning but continues as questions arise that need
to be answered.
A Product Owner who wants to collaborate in this way needs to be present

during the Sprint either by being physically near to the rest of the Scrum
Team or by making sure collaboration is possible. A Product Owner not
working near the Development Team all the time could offer regular con-
sultation hours, for example, every day from 9:00 until 11:30. Alternatively,
subject matter experts have to be available for a team, or even working
inside the Development Team, so that they can answer ad hoc questions
during the Sprint and be experts for the solution created. As long as they
don’t act as a communication filter between the Product Owner and the
rest of the Development Team, this arrangement can work fine.
9780134862156_web.indb 9 06/10/20 8:04 PM

C r e ating Tr an s par e ncy a s a S c ru m Te am

Scrum relies on transparency.
—Scrum Guide
(https://scrumguides.org/scrum-guide.html#artifact-transparency)
Transparency is the first pillar on which Scrum is built; it is the precondition

for regular inspection and adaptation.
Transparency in Scrum is created through the artifacts. The Product Backlog,

Sprint Backlog, and Increment are the minimum transparency you need in
order to implement empirical process control. They are your view into the
past, the present, and the future. Teams usually need additional ways to cre-
ate transparency; however, this varies from team to team and from context to
context. Every Scrum Team has to find out how to best create transparency
for its context and needs.
The Scrum Team sits together and discusses the Product Backlog during backlog
refinement. The Product Owner describes a feature that she would like to get
implemented.
“With the new registration process in place, we now need a way to share this data
with our patients,” she says. “To do this, I have already prepared some sketches
for the screens and the way patient and medical office work together. Our graphics
designer has put them into user interface designs that you can use to implement
the functionality. I have described the process of how this will work in detail in the
Product Backlog item. Have you all had a chance to read it?”
“I looked at it, and the team discussed it over lunch yesterday,” a developer an-
swers. “The way this is currently described makes it a really big feature that will
take us several Sprints to implement. How can we be sure that this is really the
way our customers want to work?”
“I talked to several of our key users who know their patients quite well. They gave
me their detailed requirements documents, which are attached to the Product
Backlog item,” the Product Owner says, a bit impatiently.
10
9780134862156_web.indb 10 06/10/20 8:04 PM

Creating Transparency as a Scrum Team
Hy poth e si s - D rive n Product Back log

The Product Backlog contains everything that you currently think is necessary
for your product. The interesting question is, How do you know that this is
really necessary? Many Product Owners ask their customers and stakeholders
to get a better picture of the market and its needs, and that is a good thing. It
can become problematic if this input is seen as a given requirement.
The term requirement suggests that you already know what is needed and the
way it should work. It leads you to believe that there is certainty where there
is none. This usually has two effects:
• Your assumptions are not questioned and validated. You think that the
•
person who has specified a requirement will know best and do what he or
she has asked for.
• You often put too much effort into a solution because you think this is the
•
final one. You try to get it right the first time and not to waste time and
effort revisiting work results later.
Together, these effects lead to solutions that are suboptimal or just not help-
ful in meeting a customer’s or user’s need. We encourage the Product Owners
we work with to look at Product Backlog items as hypotheses. A hypothesis is
an assumption that has to be validated. It might be wrong; therefore, we don’t
want to spend too much effort in building it.
A better way of working for the Scrum Team described in the previous scene
would have been to create a small and simple Product Backlog item that
describes the problem. Based on this problem, the team can formulate a hypoth-
esis that it would like to validate. The hypothesis could be about the process by
which data is shared or about the user interface needed for the patients and
medical offices. The Product Backlog item then needs acceptance criteria in the
form of the expected result. The Scrum Team could use the following questions
to decide on the Product Backlog items: How do we decide if our hypothesis
was right or wrong? What is the expected outcome, and how do we measure it?
This approach creates transparency on more than one level. The obvious level
is that the Development Team creates transparency about its work. It also
11
9780134862156_web.indb 11 06/10/20 8:04 PM

makes transparent what result or outcome it expects from the delivery of a

Product Backlog item. The team describes measurable results that lead to
follow-up actions.
Product Bac k log D r iv e s Con v e r sation

Another problem we often see is visible in the Product Owner’s handling of
the discussion during backlog refinement, as previously described. She pres-
ents a detailed description for the Development Team. Why should that be a
problem? Isn’t the Product Backlog a way to create transparency?
Yes, the Product Backlog makes the work for the future transparent. It should
not, however, shut down conversation. A Product Backlog item that seemingly
doesn’t leave any open question doesn’t invite conversation. People assume
that the description is complete and correct.
Product Backlog items that foster conversation grow through collaboration.

Consider the following example.
The Product Owner and Development Team sit together for Product Backlog re-
finement. The Product Owner has prepared a Product Backlog item she would like
to discuss with the team. She has already discussed the users’ needs with relevant
stakeholders and has created a Product Backlog item with a descriptive title and a
small paragraph explaining the need.
“Okay, from your explanation, this feature is for staff in the doctor’s office, right?”
one of the developers asks.
“Yes, that’s right. The employees scheduling appointments with a doctor would like
to provide the doctor with some information that they collect from the patient.”
“What kind of information is that?”
“When a patient describes why he or she wants to see the doctor, the front-desk staff
asks about the kind of illness, how long the patient has had it, and what symptoms the
patient is experiencing,” the Product Owner explains. “For follow-up appointments,
they also ask about changes in the patient’s health since the last visit. It would be great
if the receptionist could add this information to existing data for the doctor.”
12
9780134862156_web.indb 12 06/10/20 8:04 PM

“That shouldn’t be a problem. We could always format the newest data in a

different color or show it in bold font,” the frontend developer suggests.
“Let’s try bold text at first. I will add it to the backlog item,” the Product Owner says.
The Scrum Team proceeds to clarify this Product Backlog item and notes relevant
information that they agreed upon. The Product Backlog item is not yet ready to
be developed during a Sprint, so the Development Team and Product Owner fur-
ther discuss it during their next refinement. They find out that it is too big to be
developed in one go, so they slice it into three smaller items that can be developed
independently. After three weeks, the first of those items is part of the Develop-
ment Team’s Sprint Backlog and can be implemented.
Over the course of a few days, sometimes weeks or months, conversation on

different levels with different audiences leads to important insights:
• What is needed
•
• What this product could look like
•
• How the team can validate whether it is valuable
•
• How much work it takes
•
These conversations create transparency and continuously add further trans-
parency to the Product Backlog. They deepen the shared understanding inside
and outside the Scrum Team.
During backlog refinement, the Scrum Team discusses some small changes to a
backlog item that has already been discussed a few times.
“Where is the value in that?” one of the developers asks. “Those small updates
to the functionality force us to touch different parts of the source code for very
small changes.”
“Do we have to work on such small Product Backlog items?” another one adds.
“Well, our Product Backlog items have to be small; otherwise, the risk increases that
we won’t be able to finish them,” the Scrum Master explains. “Remember our first
Sprints when big parts of our forecast were not delivered by the end of the Sprint?”
13
9780134862156_web.indb 13 06/10/20 8:04 PM

The Product Owner chimes in. “It’s quite a lot of work for me to prepare the
Product Backlog in a way that items are small enough for you to work on,” she
says. “To be honest, it would be easier for me to present bigger pieces of work and
have you figure out how to deliver them. But when we talked about the feature
two weeks ago, you said that it was too big to be implemented in one Sprint, and
so we sliced it into different backlog items.”
S e eing th e B ig Pictu r e
The discussion in the preceding scenario is a common one. Many teams
struggle with the balance of Product Backlog item size and seeing the big pic-
ture. Often, the Product Owner has this big picture in mind, but it isn’t visi-
ble in the Product Backlog.
A good solution is to keep bigger Product Backlog items, the “parents” of the
smaller items, in the Product Backlog. Those bigger items help communicate
the larger goals the Product Owner tries to achieve. They should explain the
value they should deliver. Bigger Product Backlog items act as beacons in the
Product Backlog to give the Scrum Team and stakeholders guidance. They
often don’t describe concrete functionality.
Because of their size, these beacon Product Backlog items themselves can
never be pulled into a Sprint by the Development Team. Smaller Product
Backlog items that are refined from this parent can be further clarified and
refined, however, and pulled into a Sprint for implementation. The Product
Owner can decide after every Sprint whether the current sum of child Product
Backlog items is enough to reach the goal of the parent item or if more work
is needed.
If an intermediate target or goal is hard to put into a Product Backlog item, a

Product Owner might want to formulate a goal and add that goal to smaller
Product Backlog items. The important thing is that the big picture is visible
and understood by the whole Scrum Team.
Sometimes the situation is worse than the one described in the narrative. Some
Product Owners don’t see the big picture. They see themselves as “Product
14
9780134862156_web.indb 14 06/10/20 8:04 PM

Backlog managers,” and their responsibility is to collect the requirements of

their different stakeholders and communicate them to the Development Team.
If this is the case, the most important goal for a Product Owner and the sole
reason for the role—optimizing the value of the product being created—is
unachievable. How can a Product Owner optimize something if he or she
doesn’t see and understand the big picture?
This dysfunctional situation has to be rectified by the organization. Product

Owners need a mandate and the power to optimize product value. They need
to know what value means for their customers and stakeholders. Their deci-
sions in the Product Backlog to increase this value have to be respected.
Product Back log Ite m s N e e d to C r e ate Va lue

The next topic often comes up with the missing big picture previously described.
Development Teams, but also stakeholders, often complain that they cannot see
the value in a Product Backlog item. This is problematic, as it remains unclear
why something should be implemented. Without a clear understanding about why
a piece of functionality is needed, it is difficult to deliver the optimal solution.
Avoiding this situation requires a capable and present Product Owner.

Capable Product Owners are able to describe the overall value that is created
through the product. They are able to define the top goals that need to be
achieved in order to increase value. Present Product Owners are near enough
to their Scrum Team and stakeholders to explain those value propositions.
They are also there to repeat this message so that it sticks.
The value a Product Backlog item creates should be visible from the item itself.
This can be the “so that I . . .” part of a User Story, where the user describes
the purpose of the item or what he or she is trying to achieve. It can also be a
visible and prominent set of goals for the product that are added to Product
Backlog items. One of our customers had the five most important goals for the
product written on a flipchart in the team room. For every Product Backlog
item, the Product Owner specified the goal or goals this item would help
achieve. If none of the goals would be supported by a particular Product
Backlog item, a discussion clarified whether and why this item was needed.
15
9780134862156_web.indb 15 06/10/20 8:04 PM

During Daily Scrum the next day, the Development Team discusses its work at the
Sprint Backlog.
“Today I will start my work on the appointment logic,” one developer says. “This
will probably keep me busy for the rest of the week.”
“All right, I will work on the user interface for the appointments. As soon as you
are ready, we can put it together,” another one follows.
One by one, the team members tell their colleagues what they are planning to work
on today. Sometimes their Scrum Master interrupts them with a question. “I didn’t get
that. Which task will you work on next? I would like to update it on our task board.”
After eleven minutes, everybody is updated on the current work and the Daily
Scrum is over.
S print Back log I s M or e th a n a Ta s k B oa r d

This scene is quite typical for many Scrum Teams. The Development Team
together with the Scrum Master work on the detailed planning of their work
for the upcoming day. The discussion in the Daily Scrum seems useful, and
yet, there are some potential hidden problems.
What we often see is that the Sprint Backlog is just a task board. And this, in
itself, is not bad.
The Sprint Backlog makes visible all the work that the Development Team
identifies as necessary to meet the Sprint Goal.
—Scrum Guide
(https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)
Yes, a task board creates visibility around the work a Development Team plans
to execute. But where can we see the overarching goal the team is working on?
A Sprint Backlog that is just a task board usually doesn’t make that visible.
A Sprint Backlog should also make the Sprint Goal prominently visible, and
discussions around work should take the Sprint Goal into account. The dis-
cussions in the previous scene would then most probably have changed.
16
9780134862156_web.indb 16 06/10/20 8:04 PM

People would have discussed their work and how it would help achieve the
Sprint Goal.
The easiest way to have the Sprint Goal present during those discussions is to add
it to the Sprint Backlog. For a physical backlog with paper on the wall, this is just
a bigger piece of paper that contains the Sprint Goal. Most digital Sprint Backlog
tools have a way to add meta information; some even have a way to store the
Sprint Goal for a Sprint, which then can be shown on the Sprint Backlog.
By adding the Sprint Goal, the Development Team is able to fulfill the
requirements on a Sprint Backlog from the Scrum Guide. The Sprint Backlog
contains the Product Backlog items selected for this Sprint. It also describes a
plan for delivering the product Increment and realizing the Sprint Goal. Thus,
it talks about the why, the what, and the how of the Sprint. The why and
what are represented by the Sprint Goal and the selected Product Backlog
items. The plan for delivering these Product Backlog items, often described as
tasks that people from the Development Team work on, describes the how.
By working toward a Sprint Goal, the Development Team can also adjust
scope in a Sprint when unforeseen problems happen. They can then collabo-
rate with the Product Owner and decide how to change the Sprint scope in
order to still reach the Sprint Goal.
Who S hou ld U pdate the S print Back log?

Maybe you noticed this from the preceding scene: The Scrum Master updates
the Sprint Backlog. Why does she do this? Isn’t the Development Team able to
update its plan for doing the work in a Sprint? This is a pattern we still often
see in Scrum Teams, especially when the Sprint Backlog is a way to report sta-
tus (see “Sprint Backlog as Status Report”). So why is this a problem?
The Development Team owns the work in a Sprint. It is responsible for deliv-
ering releasable Increments of product. It is also responsible for creating and
executing the plan to reach the Sprint Goal. It is a self-organized team that is
able to do all of this.
If a Scrum Master updates the Development Team’s Sprint Backlog, this often
shows that a Scrum Team has not yet been able to fully leave behind their old
17
9780134862156_web.indb 17 06/10/20 8:04 PM

roles and behaviors. In a traditional project, a project manager usually assigns

work packages to people. A project manager also follows up on the progress
of these work packages and reports the status to management.
This takes away self-organization and leads to behavior typical of a command-and-

control environment. Development Team members don’t really feel responsible for
their work and consequently are unlikely to feel accountable for it.
Th e S print Back log S hou ld N ot B e H idde n

At least our Development Team has a visible Sprint Backlog. Often, the problem
starts where this visibility is missing. When a physical Sprint Backlog is hidden
in a corner of a room nobody ever enters, the Scrum Team has lost an impor-
tant opportunity to create transparency. For everyone outside the Scrum Team,
the development work is a black box, completely invisible. Of course, this is
also true for a digital Sprint Backlog that is only accessible to the Scrum Team.
Why is it important for ongoing work in a Sprint to be visible? Is it really nec-

essary to update the people outside the Scrum Team about everything that is
going on? We think so; it helps to create a shared understanding of what
development work means. Having a visible and accessible Sprint Backlog has
some positive side effects.
By making both progress and obstacles visible to everyone interested in the

product, you are able to create trust and confidence. The stakeholders see
what you are working on and what you are struggling with. They can under-
stand the unforeseeable things that Development Teams have to cope with in a
complex environment. Maybe they can even help the Development Team over-
come problems. But they need to see the current progress in order to do so.
A visible Sprint Backlog also makes the Sprint Goal visible, which makes it
easier to talk about the work the Development Team currently does. “I am
working on the user interface in a form for our appointment workflow” might
be difficult to understand for someone outside the Scrum Team. A Sprint
Goal such as “This Sprint exists to improve the appointment workflow” is
much clearer, as it addresses the business needs, not technical tasks.
18
9780134862156_web.indb 18 06/10/20 8:04 PM

Toward the end of the Sprint, the Development Team is a bit behind in its planned
work. The team members have underestimated some of the tasks they needed to
do for a Product Backlog item. That work took longer than expected, and now
they must find a way to still meet their Sprint Goal and (possibly) forecast.
“This burndown looks terrible,” one of the developers complains. “It seems like no
work has been done for three days.”
“The burndown is not important,” a colleague answers. “Our Sprint Backlog shows
what really happens during our Sprints. It is not a status report that has to look good.
When we started with Scrum, every Sprint Burndown chart was perfect, but we still
didn’t have a releasable product Increment by the end of our Sprints. I prefer the cur-
rent situation where we know what’s going on and focus on getting something done.”
S print Back log a s Status R e port

The second developer expresses a very sophisticated view. Many Development
Teams try to perfectly deliver their Sprint Plan forecast as frequently as they
can. The interesting thing is that this would be a strong indicator that the
work is not complex, but only complicated, which means predictable.
We have already briefly touched on the topic of Sprint Backlog as status

report. Organizations coming from traditional project management often try
to reach their forecasts. This is no wonder, as delivering on time, on scope,
and on budget are typical performance measures for traditional project teams,
and these traditional organizations often act as if the result and its quality is
less important than time, scope, and budget. If the Sprint Backlog is treated
as a status report to measure team performance, the team might, consciously
or unconsciously, try to make the Sprint Backlog status report look good and
take less care to deliver a releasable Increment of product by the end of the
Sprint.
The Sprint Backlog is not a status report. It creates transparency into the work
the Development Team does to reach a Sprint Goal. If things go smoothly, this
will show in the work and, if the Development Team uses them, in the Sprint
19
9780134862156_web.indb 19 06/10/20 8:04 PM

burndown charts. If the team discovers unforeseen problems and has to react,
this will also be visible. The team can then either find another way of reaching
its forecast or discuss and negotiate scope in order to still reach the Sprint Goal.
Wor k B u r n dow n I s R a r e ly Pe r fect

The same pattern that leads organizations to view the Sprint Backlog as a sta-
tus report often leads to perfect burndown charts. A burndown chart shows
the amount of remaining work over time. For a Sprint Burndown, this typi-
cally means the remaining work on the different days of the Sprint. Every
piece of work completed will “burn down” on the chart.
If a Development Team’s performance is measured against the “success” of

its Sprints, this can lead to perfect burndown charts (see Figure 1.2). Success
here typically means that the team is able to deliver everything that it has
pulled from the Product Backlog and forecast during Sprint Planning.
Work
Sprint
Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue
Figure 1.2 Perfect Sprint Burndown
20
M01_Gotz_C01_p001-p026.indd 20 06/10/20 11:16 PM

It is possible to have this kind of burndown without anything being wrong. It

is also possible to roll a pair of dice 50 times to produce the first 50 digits of
the number Pi; it is just very unlikely. So, if this happens sometimes, as a
Development Team, be happy and celebrate your good luck. If it happens
often, then this is an important indicator that transparency is impeded.
A Sprint Burndown, like the Sprint Backlog, creates transparency around the
work and progress toward the Sprint Goal. If transparency is lacking, the
Development Team might not be able to correctly assess its current situation.
Therefore, a burndown chart is not good or bad, it just is.
Pr e ve nting S print Back log from G rowing Sta le

The opposite of a Sprint Backlog status report with a perfect burndown chart
is a stale Sprint Backlog. This is a backlog that is created during Sprint
Planning and then forgotten. Typically, toward the end of the Sprint, someone
cleans up the board. This can be done by moving all the items into the
“Done” column or by removing them from the board altogether.
A Sprint Backlog like this doesn’t create transparency and visibility. It is, in
the language of lean, waste—wasted time and effort in creation and clean up.
A stale Sprint Backlog is like having a car dashboard that you never consult in
order to adapt your driving: You won’t know how fast you are going, you
won’t know if your oil light is flashing, and you won’t know if you need to
shift gears (if you prefer manual transmission cars, as we Germans still do).
A stale Sprint Backlog (in our opinion) is worse than no Sprint Backlog at all.
If a Sprint Backlog doesn’t exist, at least nobody relies on the information it
shows. A stale Sprint Backlog does not simply reduce transparency, it shows
false data.
The question we typically ask teams that don’t actively use their Sprint
Backlog is, Why? We want to understand why the Sprint Backlog doesn’t pro-
vide value to them. And then we want to make the Sprint Backlog valuable
(again).
21
9780134862156_web.indb 21 06/10/20 8:04 PM

If a Development Team has only specialist team members who do only their
part of the work through the Sprint, the visibility of others’ work might not
be useful. Those teams don’t collaborate, and they normally aren’t cross-
functional enough. They focus on doing their tasks, not reaching a Sprint
Goal. We try to help those teams become more cross-functional and learn
how to collaborate toward a common goal.
Other teams that don’t actively use their Sprint Backlog work together so closely
that they don’t see the benefit of transparency. Everybody on the team knows
what’s going on at all times anyway. It helps those teams to understand that the
Sprint Backlog is also valuable for people outside the Development Team.
Sometimes teams just use (or have to use) the wrong tool for their Sprint Backlog
management. Teams working closely together often don’t see the point of using a
digital tool to manage their Sprint Backlog. If management forces them to do so,
they often neglect it. The same is true for a team that would like to use a digital
Sprint Backlog and someone forces them instead to use sticky notes and pens.
As soon as you discover the reason why the Sprint Backlog is not used, it is
usually fairly simple to reinstate its value.
“That is great,” the marketing department lead says. “How soon can we get it to
our customers?”
“For us, it is just a push of a button to bring this version into production,” a devel-
oper answers. “The increment is currently on our integration stage. We just have
to deploy it to production, and it will be live.”
The Product Owner interjects. “Yes, we can deploy it easily. The question is,
should we do it now? Does this increment already provide enough business value
to our customers and ourselves to justify a release?”
“How can we know that if we don’t show it to our customers?” the department
lead retorts.
“Fair point. Let’s do it.”
22
9780134862156_web.indb 22 06/10/20 8:04 PM

D one I s R e le a sa ble
The most important artifact in Scrum is the releasable product Increment. It is
the sole reason for all the work we put into Scrum. It provides us with trans-
parency around our hypotheses. Were our assumptions correct? Do our cus-
tomers and users want what we have to offer? And do they get value out of it?
These are questions that can’t be answered in a laboratory. Therefore, produc-

tive use of our product is indispensable. It closes the feedback loop to our
customers and users and tells us where to concentrate our efforts next.
“Done” is a very important, if not the most important, idea in Scrum. “Done”
means releasable, and releasable means everything that the Development Team
needs to do in order to offer this product Increment for productive use is done.
This typically includes testing and verification both inside the product and
from the outside. It also includes the necessary amount of documentation for
productive use. Releasable in a regulated environment might even mean special
verification or testing against laws, norms, or an external audit.
Much of the innovation in software development in the past twenty years

came from the idea that we need to be able to deliver releasable software in
short iterations. If we look back to our typical customers in the early years
after 2000, this was not taken for granted as much as it is today. Development
cycles of several months were the norm, not the exception.
Other industries will probably follow and find their own strategies and tactics
to be able to deliver incrementally, whatever their definition of “Done” is.
M e a su ring an d Ve rif y ing Va lue in a Product

Transparency alone is not a goal, it is a precondition. You need transparent
data to measure results and verify your hypotheses. But what should you
measure, and how do you verify your assumptions?
Transparency is one precondition; goals are the other. The goals tell you
against what to verify, and using the goals together with the data you collect,
23
9780134862156_web.indb 23 06/10/20 8:04 PM

you can measure the right thing: your metrics. These topics are relevant for
the Product Owner, as he or she is responsible for optimizing the value of
the product.
To identify relevant metrics, a Product Owner should look at the product

vision. The vision, with its quality goals,1 represents the highest-level assump-
tions and value propositions for a product. If usability and ergonomics are
key quality goals, a Product Owner should find ways to measure them. This
might be difficult, as those goals are often qualitative and perceived subjec-
tively. It is necessary nonetheless.
You might need to ask your customers what they like about your product and
what can be improved. Often, customers and users don’t know what they
would like to have or why exactly they like this product over that. Consequently,
you also have to monitor their usage of your products. You need to measure
what features they use, when, and how. You need to deliver functionality in
slightly different forms and measure which form is used more often or for lon-
ger periods.2
If you don’t find metrics that help you measure your quality goals to reach
your product vision, you will fall back to metrics that are easy to collect
and analyze. The problem is that they might not be helpful in validating
your assumptions. Eric Ries, the author of The Lean Startup, calls them
“vanity metrics.”
Vanity metrics are dangerous.

—Eric Ries, The Lean Startup
We talk more about metrics that help measure business value in Chapter 6,
“Measure Success.”
1. The top (maximum three to five) quality criteria for a product are its quality goals; for software
products, the ISO/IEC 25010 (former ISO/IEC 9126) defines quality criteria: https://en.wikipedia.org/
wiki/ISO/IEC_9126#Developments
2. https://en.wikipedia.org/wiki/A/B_testing
24
9780134862156_web.indb 24 06/10/20 8:04 PM

Summary
S u m m ary
In this chapter, we met our Scrum Team. We saw them collaborate as a team
and with their stakeholders in various ways. We also saw how they use the
Scrum artifacts to create transparency in order to reach their goals.
Usually it takes time to get to this stage of professionalism and familiarity

with Scrum. In the following chapters we will describe potential ways, ideas,
practices, and tools that might help you to get there.
25
9780134862156_web.indb 25 06/10/20 8:04 PM

Common Problems
2
In this chapter, we look back into the first Sprints our Scrum Team experienced.
Many teams struggle with the change from using a traditional project manage-
ment approach to an agile way of working. Their struggle is visible in recurring
patterns, which we describe in this chapter. These patterns are often expressed
as an organization or team claiming that “Scrum doesn’t work.” When we look
closer into their specific situations, we find that it is true that Scrum doesn’t
work in their context because of various impediments. Fortunately, many of
those impediments are solvable, and we describe those solutions.
A term that describes many of the problems these teams experience is mechan-
ical Scrum. It refers to the situation in which an organization and its Scrum
Teams apply the Scrum Framework mechanically without understanding its
rationale of intent. Mechanical Scrum is sometimes called flaccid Scrum1 or
zombie Scrum. Organizations that are trapped in mechanical Scrum find their
Scrum events are empty rituals, lacking real purpose; they find it difficult to
make sense of Scrum’s elements and the rules that bind them together. This is
especially true and can have serious consequences if the organizational mind-
set and understanding is in conflict with an agile mindset.2
1. https://www.martinfowler.com/bliki/FlaccidScrum.html
2. See Chapter 3, “Theory X: The Traditional View of Direction and Control,” and Chapter 4, “Theory Y:
The Integration of Individual and Organization Goals,” in Douglas McGregor’s The Human Side of
Enterprise [McGregor05].
27
9780134862156_web.indb 27 06/10/20 8:04 PM

Chapter 2 Common Problems
Organizations also struggle with Scrum because of the Dunning-Kruger

effect,3 a cognitive bias in which competent people usually underestimate their
competence, whereas incompetent people often overestimate their competence
[Dunning05]. Competence here means the knowledge and skill about a spe-
cific area of interest. In our example, this is Scrum. Teams that are relatively
inexperienced overestimate their competency in implementing the framework
and often make wrong decisions.
This chapter describes basics that organizations and teams are often missing.
Those missing basics create an inadequate environment for a Scrum Team to
operate in. We then discuss some common misunderstandings about Scrum
that lead to a situation in which Scrum doesn’t work. Last but not least, we
talk about common but avoidable errors that many Scrum teams make.
The Ro o t C a u s e s of M e c h a nic a l S c r u m
Mechanical Scrum is the most common organizational dysfunction that we see
today. Larger organizations, especially, fall into the trap when they try to do Scrum
instead of be agile. In their attempt to implement Scrum, they focus on the ele-
ments and rules but neglect the values and principles behind Scrum.
This is particularly prevalent in organizations who tend to require a clear and strong
delineation of management authority. People working in such an organization often
have been conditioned to need such rules and the safety and stability they bring. The
job descriptions are very clear on the responsibilities of a person, which is often only a
small fraction of a larger, value-adding process. And, too often, the rigidity of the rules
and structure gets worse over time. If errors occur, the organizational instinct searches
for a missing rule, finds it, and creates a new one to prevent the error in the future.
Scrum is different. It has very few rules and defines only the structure that it deems
absolutely necessary to deliver “Done” product Increments every Sprint. Values and
principles guide our actions in Scrum, not strict sets of rules that grow over time.
Organizations that suffer from mechanical Scrum experience real Scrum as disrup-
tive. It shakes their beliefs and often creates a sense of insecurity and instability.
Yet becoming comfortable with this instability is necessary in order to reap the
benefits Scrum can create.
3. https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
28
9780134862156_web.indb 28 06/10/20 8:04 PM

Missing Basics
A change in the process, which translates to “how we do things here,” needs a

change in culture first. Unfortunately, culture is harder to change than process. The
good news is that a change in process can make transparent dysfunctional cultural
aspects, which can change over time.
M i ssing Ba sic s
It is the third Sprint of our Scrum Team. The company CEO and the Scrum Master
discuss the progress they have made in implementing Scrum. The CEO is disap-
pointed, as the success is less than he expected.
“Do you know what else we need to do?” he asks. “We have very good people on
our teams and have equipped them well. When do you expect us to see positive
results from our Scrum Team?”
“Yes, that is true. From an outside perspective, we have everything we need, yet
still we are struggling. From what we discussed in our last Sprint Retrospective, I
don’t think there is one impediment blocking us. It looks more like general things
that hinder us in our day-to-day implementation of Scrum.”
The CEO tries to understand. “Can you be more specific?”
“Well, I think we need to learn to know each other better. Most of us have never
worked with each other before. I guess it will take a bit of time to grow into a team.”
“I see. But I need to see results soon. We planned to have Scrum working opti-
mally within three months, and I would hate to have to stop the experiment. Based
on what we estimated when we were considering using Scrum, your velocity and
output should already be increasing.”
E a r ly Stu m ble s with S c ru m

This scene is typical of what we see in many organizations: They try to
implement Scrum as a project, complete with a goal, a budget, and a road-
map with milestones. They think Scrum is like a tool that they can simply
install and start using, like a new group chat tool.
29
9780134862156_web.indb 29 06/10/20 8:04 PM

Scrum is a framework for delivering solutions to complex adaptive problems,

which are inherently unpredictable. Just as it is impossible to predict a time-
line, milestones, and budget for solving these problems, it is also impossible
to predict a timeline, milestones, and budget for adopting Scrum. In fact,
“adopting Scrum” isn’t a goal by itself; the real goal is to solve the complex
and unpredictable problem. Scrum is just an aid to achieving this goal. This
means that, by definition, you can’t be “done” implementing Scrum, just as
you can’t be done learning a musical instrument; you have to practice and
play in order to achieve proficiency.
The organization most likely will have to adapt to this different way of
working and solving problems. Old beliefs, structures, and processes often
impede the amount and intensity of collaboration and feedback that
Scrum needs. If we could talk about “installing Scrum,” it would be the
installation of a new mindset, not a simple tool. It would be value-driven
and based on very simple principles. It would definitely not be imple-
mented according to a predefined roadmap against which we can check
milestones.
So how should you start with Scrum? Well, just start. The precondition is that
you have a goal that you really want to achieve that you can solve in no other
way than by working empirically. Then set up your Scrum elements, the roles,
events, and artifacts, and start scrumming. After every Sprint, talk about
what helps and what hinders you in reaching your goal. Do more of the things
that help and fix the things that hinder.
This last point is especially important, as in most cases, the ability to fix lies
outside of the Scrum Team’s competency. The surrounding organization
needs to support the Scrum Team by removing obstacles and helping improve
the structures and processes. You may want to look ahead to Chapter 8,
“The Agile Organization,” and Chapter 9, “Continuous Improvement Never
Stops,” where we talk about the organization and the role of management in
Scrum.
30
M02_Gotz_C02_p027-p054.indd 30 06/10/20 8:52 PM

Missing Basics
A member of the Development Team approaches the Scrum Master after the
Daily Scrum.
“Could you please talk to our new backend developer, the one who supports us
from the other team? During the Daily Scrum, he always talks about what he is
going to do, but then he gets distracted by his former colleagues who bother him
with work that has nothing to do with our Sprint.”
“Have you talked to him about this already?” the Scrum Master asks.
“No, I don’t know him so well and would rather that you sort it out. You are our
Scrum Master, after all.”
“I think it would be better if you first try to sort this out with him personally. I am
sure he appreciates your concerns. Maybe you can even help him keep the focus
on our Sprint.”
“Do you really think? But how can I start this conversation?”
“I can help you with that. Let’s have a short walk and discuss this.”
M i ssing Com mon Va lu e s

This scene is a fairly typical situation in many Scrum Teams: Team mem-
bers ask the Scrum Master for support in difficult situations. This is natu-
ral, as the Scrum Master is responsible for the rules and values of Scrum
and for helping to enable continuous improvement. The Scrum Master in
our scenario refused to interfere, though. Was he correct to refuse? We
think so. The Scrum Master is a servant-leader and should, above all, help
the Scrum Team and surrounding organization increase self-organization
and accountability. Feeling responsible for a change and taking action is
exactly that.
This scenario also illustrates what happens when a Scrum Team does not
embrace the right set of values, the most important of which are
• Focus
•
• Openness
•
31
9780134862156_web.indb 31 06/10/20 8:04 PM

• Courage
•
• Commitment
•
• Respect
•
These values are officially part of Scrum since 2017 but have been recognized
as necessary for many years prior to that. They provide the foundation on
which Scrum is built, and organizations that don’t embrace these values never
progress beyond mechanical Scrum.
So, what is happening in this team, and what does it have to do with the
Scrum values? The backend developer who is the target of the conversation
obviously has difficulty keeping focus.
Focus is essential in Scrum; it helps us to concentrate our efforts on the next

most valuable hypothesis to work on and verify. It also helps us to finish work
we have started and to not start new work as soon as there is a minor block
with what we are currently working on. Without focus, we see situations
described previously: team members planning to do specific work but not able
to follow up on their plan.
The backend developer also seems to lack commitment. Supporting his former
colleagues when they need him is good, but not when this support keeps him from
his work for his current Scrum Team. Commitment needs to come from inside.
When we feel commitment for something, we fully say yes to it, which means that
we have to say no to something else. Commitment helps us stay focused.
The colleague who asks the Scrum Master to intercede with the backend
developer also could improve her openness and courage.
Openness can take many different forms. Scrum Teams need to be open for
change and open with each other. In the example, the Scrum Master encour-
ages the team member to be more open with the backend developer. She asks
her to discuss her observations and her wishes directly and openly, not through
the Scrum Master. This openness will increase self-organization in the team. It
also decreases the chance of conflict; people talking with each other typically
have fewer misunderstandings than people talking about each other.
32
9780134862156_web.indb 32 06/10/20 8:04 PM

Missing Basics
To be this open requires courage. It is difficult to approach someone and con-

front him or her with behavior we would like to see changed. Yet this courage
is essential in Scrum. We regularly have to discuss difficult topics and diverging
opinions. It is easy to remain silent, but if we do so, nothing ever improves.
The Scrum Master has acted in just the way she should have, by helping the
Scrum Team members to become more open, to exhibit courage, and to
improve the ability of the Scrum Team to self-organize. She also opened the
door to increase respect, as it is more respectful to have an open, face-to-face
conversation about a difficult topic with a colleague than to talk about his or
her behavior with others.
In Scrum, the Sprint Retrospective provides the Scrum Team with an opportu-
nity to identify concrete actions for improvement. Organizations should also
use regular retrospectives outside the Scrum context to continuously improve
their way of working.
If you see problems in your team or organization, try to find out where the
Scrum values are not upheld. It is not important to find the culprit; focus
instead on how the Scrum values can help prevent and correct the identified
problems. Working on those violations and finding a way back toward value-
driven behavior means working on the root cause, not fixing symptoms.
Right at the start of its Scrum journey, the Scrum Team encountered a common
but serious problem: It lacked a vision for the product. Consequently, the Prod-
uct Owner has trouble making sense of her Product Backlog. She asks the Scrum
Master, “How should I order this Product Backlog? All the Product Backlog items
are important and we have to deliver them all; it doesn’t make a difference which
ones come first.”
The Scrum Master tries to explain. “The Product Backlog isn’t ordered by impor-
tance or priority, but by business value. Are all of these Product Backlog items
equally valuable to the customer?”
33
9780134862156_web.indb 33 06/10/20 8:04 PM

M i ssing Product Vi sion

When inexperienced Product Owners start working in a Scrum Team, they
often have difficulty in ordering their Product Backlog. They usually come
from an environment where project success is (partly) defined by the delivery
of a predefined scope. Therefore, success is binary: Either you deliver the
specified functionality or you don’t.
Scrum is different. Scrum Teams work on a Product Backlog, an “ordered list

of everything that is known to be needed in the product.”4 The more impor-
tant, or valuable, items are at the top of the Product Backlog; less valuable
items fall lower on the list. But what does valuable mean?
This is where the product vision becomes important. The complex adaptive
problem that we are trying to solve with Scrum has a goal, our envisioned target
state. Every step we take should bring us nearer this goal. Some steps will help us
to make greater progress toward this goal, while others will make smaller contri-
butions. To order a Product Backlog, a Product Owner puts the Product Backlog
items that represent bigger steps toward the goal higher in the Product Backlog.
To aid in organizing the Product Backlog, the first step a new Product Owner
should take is to define or refine the product vision. Every decision about value
that the Product Owner makes will be informed by this vision. Having a
strong vision also makes it easier to discuss and represent a specific Product
Backlog order with stakeholders. Stakeholders who see only their specific area
of interest in the product can usually accept decisions of backlog ordering
when those decisions are based on hypotheses that support the product vision.
“We would like to move this feature to ‘Done’, but we can’t test it because we don’t
have a dedicated environment where we can install the software and run the tests.”
“Then why don’t we prepare one ourselves?”
4. https://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog
34
9780134862156_web.indb 34 06/10/20 8:04 PM

Missing Basics
“Because we don’t have the administrative rights on our test infrastructure to do that.”
“But couldn’t we just prepare one of our old computers and run the tests there?”
“In theory, yes. But we would need a license for our testing framework, which only
QA is able to purchase.”
M i ssing C ross - functiona lit y on the S c ru m Te a m

This conversation is one that we have heard often. Development Teams in a
Scrum setting are responsible for delivering releasable Increments of product
every Sprint, but they don’t have all the knowledge, skill, or permissions to do
so. As a result, some work that is essential to delivering a releasable product
Increment isn’t done by the end of the Sprint. If the Product Owner actually
wanted to release the Increment, additional work would be needed. The real-
ity is that the Scrum Team failed to produce a releasable Increment.
If the Scrum Team is truly cross-functional, it has all the knowledge, skill,
and permissions to produce a releasable product Increment by the end of
every Sprint. If the Development Team doesn’t include every expertise that is
needed to create this releasability, “Done” is not achieved. But where does the
expertise come from?
Most organizations today are organized in a way that puts specialists together
in their own departments. They group the business analysts, graphic design-
ers, frontend developers, electrical engineers, testers, operations engineers,
and more. This grouping by specialization may have advantages when it
comes to standardization of skills and specialization of roles. Yet it weakens
the organization’s overall ability to integrate work from specialized depart-
ments into a finished product Increment. It also diffuses accountability, as
everybody has done “their” work and nobody feels responsible for the overall
result.
To achieve the benefits of using Scrum, organizations need to move away

from optimizing for specialized skills and toward optimizing their overall
results. In a cross-functional team, every team member will work subopti-
35
9780134862156_web.indb 35 06/10/20 8:04 PM

mally some of the time.5 Planning as a whole team and aligning with, learn-
ing from, and helping others reduces the amount of time a person can spend
on “real” work. But this “unreal” work makes sure that the team has some-
thing valuable to show at the end of a Sprint. In the end, optimizing for the
whole creates better and faster results, even though they allow suboptimal
processes locally (i.e., on the team-member level).
The first step toward cross-functionality is to staff the Scrum Team with spe-
cialists from every area that is needed to create a releasable product Increment,
equipping the team with all the skills that it needs to form an idea about
improving a customer’s experience and to take that idea all the way to the
point where the idea is benefitting a customer. If this is not possible, then
identify what needs to happen so that it will be possible.
In the long run, many organizations will realize they need a different way of
organizing people. Communities of practice6 are a great way to share experi-
ences, improve skills, and foster standardization (where desirable) across
cross-functional teams.
It shouldn’t be a surprise that cross-functionality cannot be achieved all at

once. Instead, you will have to identify areas where a team lacks all the skills
that it needs. Then gradually help the team acquire those skills, either by
bringing in new team members or by helping existing teams learn new skills.
Making a series of small changes over a period of time enables huge improve-
ments over time.
M i ssing S e lf - orga niz ation

Maybe you have already realized that cross-functionality is not the only thing
impeded in our scenario; the Development Team also doesn’t seem to be
really self-organized. It doesn’t have the permissions and means to organize
its working environment and decide how the team works. It depends on the
people outside the team who are able and allowed to create testing instances.
5. The assumption that a specialist works optimally most or all of the time in a specialist environment is
wrong, in our opinion, but that is not the topic here.
6. https://en.wikipedia.org/wiki/Community_of_practice
36
9780134862156_web.indb 36 06/10/20 8:04 PM

Missing Basics
Like inadequate cross-functionality, infringement on self-organization can be

a big issue. It usually also has the same effects. The main problems that we
can see in teams that can prevent their self-organize are lack of responsibility
and demotivation.
Daniel Pink, in his book Drive, describes autonomy as one key factor for
motivation in cognitive work [Pink11]. Self-organized teams have autonomy
over their work, tools, and processes.
So, what is self-organization?
Let’s start with what self-organization is not. It is not anarchy. We often hear
our customers say, “They can’t decide that.” Sometimes “can’t” is replaced
with “don’t want to.” What many of them should say instead is, “They aren’t
allowed to decide that here.”
Self-organization needs boundaries. Every person is able to self-organize; we

do it every day in our personal lives, subject to various boundaries such as the
laws of physics, societal norms, and regulations. Organizations often estab-
lish additional boundaries, such as contracts, job descriptions, and company
values, among others.
Organizations can choose to loosen or tighten these boundaries. Some com-

panies allow their developers to choose what hardware, operating system, and
software they want to use; others don’t. Both are fine, as long as the boundar-
ies are clear.
What we need is to identify and resolve areas in our working environment

where lack of self-organization impedes us in achieving our goals, just as
with cross-functionality. In order to improve their ability to self-organize, the
Development Team in the preceding scenario would need the permissions
and competencies to set up its development and testing environment. This
would enable the team to create a “Done”, releasable product Increment
every Sprint. If the team cannot achieve this in a single step, it should con-
tinually strive toward this goal, step by step, improvement by improvement.
37
9780134862156_web.indb 37 06/10/20 8:04 PM

Com mon M i sunde r standings about S c ru m

After the first few Sprints, the team members feel they are slowly starting to make
progress. They are currently planning their fourth Sprint.
“Last week, I had to support Dan from marketing again,” one developer says. “He
needed a report, and I had to query and prepare the data. This interrupts me from
my development work in the Sprint. During a Sprint, we shouldn’t be disturbed.
We need to work on our commitment.”
The others in the team agree that eliminating distractions would help them focus
on the work they are planning to do in the Sprint. They decide not to work on any-
thing that has not come into the Sprint at Sprint Planning via the Product Backlog.
They continue their planning, select the Product Backlog items they think will be
delivered in the Sprint, and build a plan on how to deliver them.
At the end, their Product Owner asks, “Okay, so this is what you are committing
to? That’s great. Those Product Backlog items are important to our customers. I
am looking forward to seeing them delivered at the end of the Sprint.”
S e a ling th e S print
At first glance, this looks like a productive Sprint Planning event, since the
Scrum Team found ways to increase focus and work on the most important
things first. What could be wrong with this scenario?
The problem starts small, as many problems do. The team members tried to
increase focus by sealing the Sprint and locking themselves in. They wanted to
focus on their Sprint Goal and limit collaboration with their stakeholders
to the work planned during the Sprint Planning, so they worked only on the
Product Backlog items they selected and planned for the Sprint.
Two problems resulted. First, it increased the chances for conflict, since stake-
holders depended on the Development Team for urgent ad hoc work that
couldn’t be predicted and planned for. Delaying this work increased the time
it took to get this work done, sometimes creating crises.
38
9780134862156_web.indb 38 06/10/20 8:04 PM

Common Misunderstandings about Scrum
Second, it created a disconnect between stakeholders and the Development

Team, who stopped collaborating and started communicating only through
Product Backlog items. This amplified a separation between different teams or
departments (sometimes called siloing). Silos create or worsen the problems
that Agile and Scrum set out to solve: Scrum is about solving complex adaptive
problems collaboratively. It acknowledges that a complex world is unpredict-
able. Disruption is to be expected and will be solved by working on it together.
The Sprint is a container in which the Scrum Team is able to work on a com-
mon goal. This common goal is the main objective for the team. Yet a Scrum
Team, including the Development Team within it, should be able to react to
and interact with the outside world. Urgent and important work that doesn’t
interfere with the Sprint Goal can and should be done.
Com mit ting S cope

There is a second problem in the use of the word commitment in the preceding
scene: Commitment is one of the five values in Scrum, because individuals and
organizations need commitment to reach their goals. But real commitment comes
from the inside; it can’t be pushed at someone. In the scenario, the Product
Owner seems to be forcing the Development Team to make a commitment.
Commitment has a difficult history in Scrum. The term has been used in the
past to express that a Scrum Team needs commitment to reach its Sprint Goal.
The misunderstanding lies in that some organizations understood that as a
promise or contract that wouldn’t be broken. Since most of those organizations
didn’t use Sprint Goals but only planned scope in the form of Product Backlog
items during Sprint Planning, this led to an implied promise on the scope that
would be delivered. Does that remind you of something? It is the old mindset
that you could predict the future if you would only plan it correctly.
Complex problems can’t be planned with absolute accuracy. Therefore, the

term commitment has been replaced with forecast in the context of Sprint
Planning. The weather can’t be predicted with accuracy, and therefore the
weatherperson doesn’t commit to tomorrow’s weather. The same is true for a
Scrum Team and its Sprint. The team tries to predict the Sprint well enough
39
9780134862156_web.indb 39 06/10/20 8:04 PM

with the Sprint plan but treats the plan as a forecast. If something unforeseen
happens, the Scrum Team may need to change the scope of the Sprint. It
should not change the Sprint Goal, though; that should be fixed.
Making it clear that the forecast from Sprint Planning is not a promise is very
important. Stakeholders, especially in organizations that see missed plans as
failure, need to understand this in order to be able to find value in Scrum.
This inherent unpredictability in Scrum comes with some benefits that can be
reaped only if you accept it. As a Development Team’s experience with Scrum
grows, its forecasts usually become more reliable. It is also better able to
account for the “normal” unknowns that happen all the time, such as phone
calls, meetings, and urgent and important ad hoc tasks.
When we see organizations use the word commitment in the old way, we gently
try to steer them to the term forecast instead. Changing the word also changes
their perception of a Sprint, as it improves transparency because teams don’t
need to use opaque buffering to accommodate unpredictability. Transparency
enables organizations to work to remove impediments that lead to unexpected
but avoidable work. Transparency also helps to improve understanding, collab-
oration, and trust among different teams and departments in an organization.
This doesn’t mean that a Development Team can say, “We can’t say if we can
make it during this Sprint, as it takes as long as it takes.” That would be the other
extreme. A Scrum Team should refine the top of its Product Backlog into small
enough items so that it can create a realistic forecast. This forecast can turn out to
be wrong if something unforeseen happens, but otherwise it should be accurate.
A little after the Sprint Planning, the Development Team members are back in
their room, starting to work on their Sprint Backlog.
“All those meetings! I am really glad that we are back to real work,” one of the
developers says. “Yesterday afternoon was the Sprint Review, then the Retro-
spective, and today we had two hours of Sprint Planning. That is really too much
overhead. We hardly get any work done.”
40
9780134862156_web.indb 40 06/10/20 8:04 PM

Too M an y M e etings ?
The Scrum Guide describes maximum time-boxes totaling twenty hours of
events for a four-week Sprint plus up to 10 percent of the Development
Team’s capacity for Product Backlog refinement. That’s four and a half work-
ing days. For the whole team. Isn’t that a bit too much?
Many organizations complain about the high number of meetings in Scrum.

They claim that the team members hardly have the chance to get anything mean-
ingful done because they sit together and talk the whole time. And that is on top
of all the other organizational meetings in which employees must participate.
This second complaint is the problematic one: Events in Scrum make many
other meetings that organizations use to align their employees and teams
obsolete. Separate status meetings, in which employees tell their superiors and
each other what they are currently working on, should not be necessary to
learn what is going on. When appropriate transparency is created, even some
management meetings are unnecessary. In addition, many ad hoc meetings for
clarification or alignment can be made obsolete by the Daily Scrum or regular
Product Backlog refinement sessions.
Scrum creates transparency on several levels. Team members use the Daily
Scrum to collaborate with each other and update their Sprint Backlog accord-
ingly. Since the Sprint Backlog is transparent to anyone, management inter-
ested in short-term progress can get the status from there. The Scrum Team
reviews the Increment with stakeholders at the end of each Sprint and asks
for feedback, which takes the place of status/progress review meetings. Since
Scrum Teams are self-organized, their management usually doesn’t need very
detailed status reports. Stakeholders can usually go visit the teams and see
their status presented transparently on information radiators such as a task
board or cumulative flow diagram.
Let’s get back to the first complaint—all those meetings, and no real work
gets done.
First, the maximum time-boxes for events are just that: maximum time-boxes.
Teams don’t need to use those time-boxes; they can optimize their work and
41
9780134862156_web.indb 41 06/10/20 8:04 PM

finish meeting quicker. Second, if they can’t finish quicker because there is so
much to clarify, the events’ durations shouldn’t be a problem, as the time is
obviously needed. Communication and collaboration prevent waste and
defects.
Most teams we work with spent more time in meetings before they started
with Scrum. Think about all those little alignments and clarifications, often
done ad hoc, that you need in order to do the right things. Scrum defines
fixed opportunities in every Sprint to do them and calls them events. Those
events should replace and make obsolete those smaller meetings spread over
our working days.
In the beginning of their journey, the Scrum Team members did the Sprint events
on their own. For example, for Sprint Review, the Development Team showed the
Product Owner what they had achieved and got feedback from her.
“Now we come to a new feature that we implemented. Patients now can make
and cancel appointments via our portal. They don’t have to call the doctor’s office
if they don’t want to.”
The Development Team walks the Product Owner through the Sprint Backlog and
tells her what it was able to implement and how it is being used.
“Okay, that looks nice. Do patients always have to enter the date manually? What
if they enter a wrong date?” the Product Owner wants to know.
“The date is being validated, and an error message is shown to the patient. The
patient has to enter a correct date and select a time slot that is still available in
order to store the appointment,” a developer explains.
“Okay, got it. But wouldn’t it be easier for patients to select a date in a visual cal-
endar and then select a free slot on that day?”
“Yes, sure, we can do that. It would take a bit of effort, but it is possible. Should
we add this to the Product Backlog?”
“I will first check with our marketing department to see if our customers really
need this. We can discuss that in our refinement next week.”
42
9780134862156_web.indb 42 06/10/20 8:04 PM

N o Stak e holde r in S print R e vie w

This is a typical situation in many organizations: The Scrum Team sits
together for the Sprint Review and discusses the product Increment and what
could be the next valuable improvements. The way our team executed its
Sprint Review shows some of the positive effects of Scrum. The team’s work
results are inspected frequently, and feedback is being collected and used to
further improve the product. But it is not as effective as it could be. There are
a few points that can be improved.
First, the Product Owner isn’t sure if the improvement she discussed with the
team is valuable enough to justify the extra effort. She wants to discuss that
with her stakeholders and will come back to the Development Team. It would
be better to have the stakeholders in the Sprint Review to give feedback
directly.
Doing so would provide the Development Team with firsthand feedback, posi-
tive as well as negative. When the people doing the work are connected to the
people who use their results—their customers and users—empathy is improved
in both directions. Development Teams empathize more with their customers
and users and better understand their needs and wants. Stakeholders also
empathize more with the Development Team. They learn about the team’s
constraints and understand the reason behind technical decisions.
Second, the Product Owner can’t provide important feedback during the Sprint
Review but has to check with her stakeholders after the review. This delayed
feedback means a loss of days, sometimes weeks. Once the Development Team
receives the feedback, it will need to adapt to it. If stakeholders are part of the
Sprint Review, they can share their feedback immediately, and the team can
take action as soon as the next Sprint.
The more stakeholders actively participate in the Sprint Review, the better the
feedback will be. Therefore, instead of showing stakeholders the work results
in a presentation or demonstration, let them use the product. This will greatly
increase the quality of the feedback received during and after the Sprint
Review.
43
9780134862156_web.indb 43 06/10/20 8:04 PM

When stakeholders are present in a Sprint Review, the Product Owner can
share the current state in regard to midterm planning. Many Scrum Teams
work from Sprint to Sprint and don’t have enough focus on and visibility of
the midterm planning. With stakeholders in the Sprint Review, the Product
Owner can show what bigger goals are currently being worked on and what
the status after this Sprint is. She can also give a rough forecast on what the
goals of the next Sprint or Sprints will be. This creates transparency for stake-
holders, who are usually interested in the big picture of product development
and not so focused on the specifics of each Sprint.
Having stakeholders participate in Sprint Reviews has another indirect bene-

fit. When the Product Owner is the target audience of the Sprint Review,
there is not much need for in-Sprint collaboration. The Product Owner often
sees the product Increment for the first time during Sprint Review. This is a
big risk. A Development Team could work for a whole Sprint, up to a calen-
dar month, without the Product Owner’s feedback on its work results. A
Sprint Review that targets the stakeholders usually changes this situation
dramatically. The Product Owner becomes the host of the Sprint Review and
needs to be prepared. Therefore, she collaborates with the Development Team
during the Sprint and gives feedback on the way things are implemented. This
feedback can already be included in the product Increment, which means a
better result can be shown during the Sprint Review.
Having stakeholders in the Sprint Review has many advantages. Sometimes

organizations claim that their stakeholders are too busy to join the Sprint
Review. They want to be updated personally by the Product Owner after-
wards. The downsides of this approach are serious enough, in our opinion, to
justify stakeholders taking this time out of their busy calendars. We think that
it is more efficient to make sure this time together happens instead of working
on the wrong things or slowing down the whole Scrum Team unnecessarily.
“Okay, I understand why this might make sense. Let’s see what the Scrum Guide
says about it.”
44
9780134862156_web.indb 44 06/10/20 8:04 PM

S c ru m I s N ot a R e ligion
The comment in this short scenario is repeated time and again in endless
teams worldwide. Don’t get us wrong—there is nothing wrong with checking
the Scrum Guide if you want to read up on a specific rule and make sure you
get it right. The problem starts when individuals, teams, and organizations
start to see Scrum as some kind of religion and the Scrum Guide as its
scripture.
Scrum is a framework that describes the fundamentals of how to solve com-

plex adaptive problems. It can’t and doesn’t give guidance for every situation
imaginable in an organization. On the contrary, it relies on self-organization
and a simple set of values and principles.
Why is it counterproductive to try to follow Scrum as strictly as possible? The

answer is quite simple: If you focus on following Scrum dogmatically, you lose
the ability to act in a context-sensitive manner. All organizations have their
own specific context. We have never seen a company or team that was able to
do “perfect” Scrum, whatever that might be. You have to find your own spe-
cific implementation of Scrum to suit your challenges, context, and people.
Scrum is based on the principles of empiricism. It inspects the status quo

frequently and adapts it for continuous improvement. Relying on the Scrum
Guide to do the right thing and be done with it goes against these very
principles.
If you find yourself discussing a question purely from the viewpoint of “doing
Scrum right,” please stop. Then think about what would make sense in your
situation. Check whether your solution adheres to the values of Scrum and
the principles of empiricism. Finally, you could check whether your solution
already has a place in the framework; its roles, events, and artifacts; or the
rules that bind them together. If one of those checks is negative, try to adapt
your solution so that it adheres to the values and principles and, maybe, the
Scrum Guide. If this is not possible but your solution still makes sense, imple-
ment it and let empiricism show whether this solution helps you or has some
unwanted side effect. If it has, inspect and adapt.
45
9780134862156_web.indb 45 06/10/20 8:04 PM

Avoidable E r ror s
The team’s Scrum Master was formerly a project manager. She managed the compa-
ny’s software development projects, which ran six to twelve months. The projects
were set up classically to start with analysis and design, followed by implementa-
tion and testing, before they were handed over to operations for productive use.
With the change to Scrum, the role of project manager has become obsolete, and
so she took the opportunity to become a Scrum Master for our team. At first, she
struggled with the new role, as the vocabulary and process are quite different from
what she was used to do.
“How is our Scrum Team doing?” the CEO asked the Scrum Master.
“It looks good. The Development Team has just finished its Daily Scrum, and I have
already updated the tasks and burndown chart. If you want, I can give you a more
detailed update on the status.”
“We have our weekly management meeting this afternoon. Why don’t you join us
and give us an update there? I am sure the others in my team are interested in the
data as well.”
“Sure, I will be there.”
“And could you please also give us some insights into the planning of development
resources for the next year? We are working on next year’s budget in the upcom-
ing weeks and would like to factor this in.”
“Sure, no problem.”
S c ru m M a ste r in N a me O nly
New Scrum Masters aren’t the only ones who struggle with Scrum. Many
people who are new to Scrum, both inside and outside the Scrum Team, have
difficulty adapting to this new way of working. Scrum Masters have a partic-
ularly large challenge because they are responsible for helping everyone in the
organization to understand how to use Scrum correctly and continuously
improve their way of working.
46
9780134862156_web.indb 46 06/10/20 8:04 PM

Avoidable Errors
The Scrum Master in the preceding scenario still acts as a project manager.
She prepares status reports, plans resources,7 and is the interface between the
team and management. Although this was her role when she was a project
manager, it is not part of her role as Scrum Master.
Scrum shares the accountability for the process, the product, and its delivery
between the three roles: Product Owner, Development Team, and Scrum Master.
The Scrum Team is self-organized, and every role should take responsibility for
its part of the work. The Product Owner is responsible for the product; therefore,
she makes transparent the product status. The Development Team is responsible
for doing the work as a self-organizing team, so the team members themselves
plan their work. They are also able to report their own status, so updating the
Sprint Backlog and the means by which they will provide transparency (such as
burndown charts or other information radiators) is their responsibility.
Of course, a Scrum Master may support the Development Team members by

helping with development tasks when they are busy, but this service can create
unintended problems. The team members might become over-reliant on it and
push work onto their Scrum Master that they should be doing themselves (such
as providing transparency into progress). As a Scrum Master, you have to think
carefully when you take over others’ work, and you must know when to say no.
The “Scrum Master in Name Only” acts as a blocker, preventing people from
approaching management directly and preventing management from obtain-
ing information directly from the team. This impedes collaboration and pre-
vents the organization from fully embracing Scrum and obtaining the benefits
of doing so. Management and interested stakeholders should visit the Scrum
Team and get the information where it is being created. This creates opportu-
nities for direct communication and collaboration.
Most important, a Scrum Master who is acting as a project manager is usually

not fulfilling the Scrum Master’s responsibilities. The Scrum Master should
help everyone understand and enact Scrum and should support the Scrum
7. People are not resources; the concept is a pet peeve of ours, and we point that out whenever we hear
someone talk about “resources” and mean people.
47
9780134862156_web.indb 47 06/10/20 8:04 PM

Team and organization with techniques, tools, and practices to continuously

improve. He or she should support the Product Owner and Development
Team to work optimally in their roles, and that includes removing impedi-
ments to the Development Team’s progress.
All of this is a full-time job; therefore, the first step to being effective as a
Scrum Master is to stop working as a project manager and to start working
as a Scrum Master. If the organization thinks it needs those project manager
services, the Scrum Master should use this as an opportunity to help every-
body understand and enact Scrum.
The Product Owner is very careful with her Product Backlog. She tries to capture
all the ideas that she, her stakeholders, and her team colleagues have about opti-
mizing product value. As a result, almost every idea that anyone has gets recorded
in the Product Backlog.
With an overzealously populated Product Backlog, the Product Owner frequently
finds herself saying, “I want to talk to you about an idea. Let me show you the
Product Backlog item we created. . . . Now where is it?”
Too M an y Product Back log Ite m s

The Product Backlog is the single source of information for work to be made
on the product. It contains all the work that is known to be needed on the
product. This can be quite a lot; it is common for Product Backlogs to contain
more than a hundred Product Backlog items, and they sometimes grow far
larger.
This is not a problem if you are able to create additional internal struc-
ture in the Product Backlog. However, if your Product Backlog is just a
list of items, and every item is just a (physical or digital) scrap of paper
with a title and description, the Product Backlog will become incompre-
hensible.
48
9780134862156_web.indb 48 06/10/20 8:04 PM

Avoidable Errors
As a Product Owner, you have several options to create this structure. One
way is to add metadata to your Product Backlog items. If you use a digital
tool, you will most likely be able to tag Product Backlog items or assign
categories or a similar means of structure. For a Product Backlog on index
cards, you might want to work with cards of different colors and sizes.
Don’t hesitate to add categories or tags as you learn more about your
product, but make sure not to let them grow into their own unmaintain-
able mess.
Another way to structure a Product Backlog is to create a hierarchy of

Product Backlog items. Most Product Backlog items start as big pieces of
work and are cut and sliced into smaller items during refinement and
implementation. Don’t lose the big item that is the parent of the smaller
ones. Digital tools should be able to create and work with this parent–
child relationship. On paper, this is more effort, but again, you can work
with colors or paper size and reference the parent on the child’s card.
The most effective, but often the most difficult, way to keep a Product
Backlog manageable is to refrain from putting every idea into it. Product
Owners and stakeholders should carefully think about the value of a pro-
posed Product Backlog item and add new items only when their value is
higher than that of the existing Product Backlog items.
Regularly cleaning up the Product Backlog is also helpful. You might filter all
the Product Backlog items that are older than, say, three months, during
which no work has been done, neither refinement nor implementation.
Chances are high that they are not so important after all and can be removed.
Since it is a bit painful to effectively throw away the work and time you have
invested in discussing and adding the Product Backlog item, this should also
help you to think carefully about how much up-front effort you put into the
creation of Product Backlog items.
49
9780134862156_web.indb 49 06/10/20 8:04 PM

It is the Daily Scrum, two days before the Sprint ends. The Development Team
discusses how to finish all the remaining work to reach its Sprint Goal.
“What about this update in the appointment service that is still in progress?” one
developer asks. “It has been in progress for over a week now.”
Another developer answers, “The person working on this task has been sick for a
few days now. She pulled the task during Sprint Planning, since she knows the code,
but she’s not able to finish it. Who can take over the work? We need the change in
this service to work in order for the Product Backlog item to be ‘Done’.”
L ic king the Cookie

The example from the preceding scenario is what a colleague of ours calls a
“licked cookie.” Just as a child might lick a cookie to prevent anyone else
from eating it, prematurely pulling work items often prevents them from
being taken over if that becomes necessary. To avoid this situation, make sure
team members pull work only when they are ready to start it.
The Product Backlog and Sprint Backlog provide work for a pull-based
approach. The Development Team pulls Product Backlog items into the Sprint in
order to support reaching the Sprint Goal. Then the developers pull smaller work
items from the Sprint Backlog—and only items that they will work on now.
Even when certain work is usually (or always) done by a specific member of
the Development Team (because of his or her unique skills), prematurely pull-
ing work will mark this work as belonging to that person. This can create a
psychological barrier that prevents other team members from helping, as their
help might be perceived as interference even when it is beneficial or necessary.
In the preceding scenario, the Development Team member was on sick leave
and unable to work on the task, but that’s not the only case where things
might go wrong. A Development Team member might think that he or she
can finish all the work in one Sprint and might continue to believe so even
when evidence of work flowing through the Sprint shows otherwise. If work
50
9780134862156_web.indb 50 06/10/20 8:04 PM

Avoidable Errors
is already assigned, people often refrain from offering help, as they think the
assignee knows what to do and will ask for help if needed.
The solution is simple: Team members should pull work as they are able to
actually work on it. This is usually a small change in behavior with a huge
effect on transparency and flow.
Everything that applies to prematurely pulling work is also true for early assign-
ment of work. In addition, assigning work contradicts the pull principle in Scrum.
When the team was first getting started with Scrum, everyone was scrambling
to adjust. The Scrum Team and organization had to find their way to implement
the framework and create an environment in which it could grow and be applied
successfully. The Product Owner was especially busy: aligning with all the relevant
stakeholders on product matters, discussing budgeting and product goals with ex-
ecutives, and working with the Development Team to make this vision come true.
The Development Team was often frustrated; the team members frequently had
questions concerning details about a Product Backlog item or wanted to get quick
feedback on something they had built.
“Where is our Product Owner?” was a frequent question heard in the team’s room.
“She is in a meeting somewhere. I haven’t seen her in a while,” was a common
response.
U n avail a ble Product Ow ne r

Direct communication is a great contributor to success when using Scrum.
This especially applies to the Product Owner. Product Owners should be in
near-constant collaboration with their teams, clarifying or renegotiating the
scope of a Sprint, clarifying Product Backlog items, or communicating with
stakeholders. Trade-offs must be discussed, or the scope of a Product Backlog
item needs to be adjusted. The Product Backlog needs continual refinement.
All of it is done in close cooperation with the Development Team.
51
9780134862156_web.indb 51 06/10/20 8:04 PM

Development Teams find it extremely frustrating to face a problem inside the

Sprint that can’t be solved or negotiated in time because of an absent Product
Owner. Scrum Teams get into trouble if the Product Owner
• works on too many tasks in parallel.

•
• is available only part time.
•
• is working remotely or hard to reach.
•
• has no authority over the product and its value optimization.
•
Product Owners should be chosen so that these problems are avoided.
Product Owners need to work with the stakeholders, the Development Team,
and the Product Backlog. It is a good idea for them to reserve time explicitly
for this work and collaboration—for example, every day from 9:00 to 11:00—
and be available for questions from anyone. Stakeholders and Development
Team members can come by during that time to discuss ideas and progress,
ask questions, or get feedback.
Product Owners also need to be able to answer the questions that arise. They
must be authorized to make extensive decisions on product matters without
checking everything with management first. This shortens feedback cycles
and improves workflow. There will always be cases when questions arise and
the Product Owner must seek answers elsewhere, but he or she should have
broad authority to make decisions within defined boundaries.
Product Owners should also be with their team. A remote Product Owner is
often as bad as an unavailable one. If the Product Owner must be remote,
then he or she will need to make extra effort to be available to the team.
Regular conversations by phone and video help create proximity; regular vis-
its to the Development Team are even better.
52
M02_Gotz_C02_p027-p054.indd 52 06/10/20 8:52 PM

Avoidable Errors
“The Daily Scrum always interrupts my work. And it is useless, by the way. I don’t
need to know what everybody else is currently doing. I want to focus on my own
work.”
The frontend developer is obviously displeased. He proposes to reduce the Daily
Scrum frequency to twice a week.
“We could do it Tuesdays and Thursdays. Then Monday, Wednesday, and Friday
are undisturbed, and I can concentrate on my tasks.”
A Daily S c ru m Twic e a We e k?
The Daily Scrum provides a daily opportunity to replan work in order to
reach the Sprint Goal. The Development Team aligns on their current work,
decides what they will do next to progress toward the Sprint Goal, and raises
concerns if they are stuck or see impediments. When teams reduce these
opportunities, they increase their risk of doing the wrong things and not
reaching their Sprint Goal.
When members of the Development Team propose reducing the frequency of

the Daily Scrum, or suggest skipping it entirely, they are saying that they
don’t see value in it. One reason can be that it has turned into a status report
rather than being a replanning session. To address their concerns, which are
probably valid, we like to ask, “What needs to happen so that the Daily
Scrum becomes valuable for you personally?” This often focuses the perspec-
tive away from being annoyed by this mandatory meeting and toward an
improvement for the team members personally.
The Scrum Master has a responsibility to help the Development Team find
value in the Daily Scrum. He or she can facilitate a discussion like the one we
mentioned or may choose to facilitate the Daily Scrum, for a while, to make
sure it doesn’t become a status report meeting. If the Scrum Master is the one
everybody reports to, he or she might want to stop facilitating it.
53
9780134862156_web.indb 53 06/10/20 8:04 PM

One reason the developer in our example finds the Daily Scrum annoying is
that it interrupts his work. This problem can be solved by changing the time
of the Daily Scrum. For example, scheduling it for a time when work is
already interrupted, such as just before or just after lunch or at the start or
end of the day, can help reduce the disturbance.
S u m m ary
In this chapter, we noted many different common problems that Scrum Teams
face. We looked at some early problems many teams encounter and some mis-
conceptions and errors that can be avoided. We also discussed ways to avoid
those errors or remedy them.
We have seen all those problems with real Scrum Teams, but obviously not all
of them at the same team. They are examples of misunderstandings and mis-
interpretations that can happen when starting to practice Scrum. This is by
no means a conclusive list as every Scrum Team will find their own things to
get or do wrong. The important thing is to spot and improve these errors as
soon as possible.
54
9780134862156_web.indb 54 06/10/20 8:04 PM

S crum I s N ot
E nough 3
The Scrum Guide describes the Scrum Framework, its elements, and the rules
that bind them together. It describes the foundation of Scrum and what it
provides to help teams solve complex adaptive problems. It does not talk
about concrete practices that teams should use when they apply Scrum. The
Scrum Team’s job is to find those practices that best help them and to apply
them to deliver “Done” Increments.
Scrum Teams usually focus on their immediate next steps: their next task, their
next event, and their next Sprint. This is good; focus helps them to finish work
they have started and concentrate on what they want to achieve. Yet it some-
times narrows their view too much, and they lose sight of their greater goals.
To meet these goals, Scrum Teams must overcome another challenge: to

expand their cross-functionality. They must undo the role/skill specialization
that organizations have promoted over the past century. This specialization has
created a workforce of people who know exactly how to perform their own
job but do not know what anybody else is doing in concert to create value.
When the world was static, this specialization served organizations well, but
it cannot cope with today’s changing world with its rapid shifts in customer
55
9780134862156_web.indb 55 06/10/20 8:04 PM

Chapter 3 Scrum Is Not Enough
needs and technology options. Scrum Teams need to rapidly respond to these
changes to deliver products that satisfy their customers’ need. Becoming more
cross-functional helps them to respond by increasing collaboration and
finding better solutions for the overall goal, not for just small parts of it.
Cross-functional teams also become more cross-functional over time, as
knowledge and skills broaden throughout the team.
This chapter describes practices that Scrum Teams can use to overcome these
challenges. These practices are not specific to Scrum, but they greatly help
Scrum Teams to solve complex adaptive problems.
Str ategy: Tak e Car e of the B ig Pictu r e

The Development Team is planning its current Sprint. A completely new type of
feature has to be implemented, and the team members argue over how to do it.
“There is no architect in Scrum,” one developer says. “Architecture emerges as we
work on the Product Backlog to deliver our product.”
Another developer disagrees. “This doesn’t make sense. We need some gen-
eral foundations to build our solutions on. Our decisions can have severe con-
sequences, and we have to make sure we get them right. Otherwise, the product
will be a mess. We need some help from a software architect.”
“But architecture changes all the time,” the other developer replies. “When I look
back at our solutions from a couple of years back, their architecture has changed
a lot over time; we shouldn’t spend a lot of time defining things that are going to
change anyway. Let’s choose the solution that fits today’s problem and solve to-
morrow’s issues as they come.”
“I think both of you are right,” a third member of the team chimes in. “At least
in parts. We should not just do whatever first comes to mind. Instead, we should
take our time to make the most important and difficult decisions. On the other
hand, we need to accept the fact that today’s technical best practices are tomor-
row’s legacy problems. As a result, we should take into account the time we need
to refine and refactor our solutions.”
56
9780134862156_web.indb 56 06/10/20 8:04 PM

Strategy: Take Care of the Big Picture
Who I s S olving Str ategic Proble m s in S c ru m ?

Many Scrum Teams struggle with exactly this problem; they must balance the
immediate need to deliver value with the long-term need to have a product
that can cope with change. Scrum focuses on delivering value today, but what
about strategic work on the product? Who is doing that, and how is it done?
First, the question of who does strategic work: Development Teams in Scrum
consist only of “developers”; there is no further specialization of roles. This
doesn’t mean Scrum Teams can’t include people who are responsible for a
specific aspect of the work; it just means that Scrum does not describe any
further specialization of roles. How Development Teams decide to partition
the work is up to them.
The question of software architect or software architecture illustrates this

point. Every software product needs an architecture that helps the team to
make significant design decisions, “where significant is measured by cost of
change.”1 This architecture may or may not need to be defined by a software
architect, a person who focuses, full-time, on defining software architecture.
The same is true for many other kinds of significant decisions, such as prod-
uct design, usability, marketing and branding, and legal issues, to name but a
few. Development Teams may make these decisions themselves, but they are
frequently assisted by people who focus on these issues full time.
Often, those persons are not fully dedicated members of a Development Team.
They are usually needed only at certain times or on a part-time basis. They also
are often supporting many different teams and working with different stakehold-
ers in an organization. Consequently, Scrum Teams can’t rely on being able to
work with these experts and benefit from their expertise when they are needed.
We usually recommend one of two options for this problem. Which one is
selected depends on the organizational context. The Scrum Team and the
1. Full quote by Grady Booch: “Not all design is architecture. Architecture represents the significant
design decisions that shape a system, where significant is measured by cost of change” (quoted in Frank
Buschmann, Kevlin Henney, & Douglas C. Schmidt, Pattern-Oriented Software Architecture, Vol. 5, On
Patterns and Pattern Languages, Wiley, 2007, p. 214).
57
9780134862156_web.indb 57 06/10/20 8:04 PM

expert involved need to choose, and often adapt, the solution that best fits
their context.
If possible, Development Teams should try to become more independent of out-

side experts by increasing their own expertise. Outside experts can support the
team in this goal by teaching and mentoring one or several team members to be
able to do the expert’s work. This approach usually requires more time and
effort than simply having the expert do the work, but it pays off in the long run.
If this approach is not possible, for example, because legal advice can be pro-
vided only by a lawyer, we recommend that the expert work with the team as
much as possible and whenever necessary. This often includes a part-time
allocation of the expert to the Scrum Teams that need their expertise. It often
also means the expert must divide his or her time for the different teams and
stakeholders and offer “office hours” when people can rely on having access
to the expert’s knowledge and experience.
Wh at I s E m e rging Structu r e ?
In the previous section, we talked about who makes important strategic deci-
sions. Now we look at how the decisions are made.
In our scenario, one of the developers talks about emergence, which is quite pop-
ular in the agile world. In a complex environment, it is impossible to fully analyze
a problem and build a solution. Instead, teams develop the solution in a series of
steps, validating their solution incrementally. In this sense, the solution emerges.
Often, emergent and emerging are used to mean that something will happen
anyway, without our having to take any action. People who use the term in
this way typically assume that they can focus on the day-to-day work and the
bigger picture, with its important decisions, will take care of itself. This is a
dangerous belief. Not explicitly considering strategic questions and simply
letting matters take their course usually leads to poor results in the long run.
We often use an architecture pretzel metaphor (see Figure 3.1) to discuss this
issue with our customers. The left half of the pretzel focuses on architecture,
but it can be replaced with every other strategic work as well.
58
9780134862156_web.indb 58 06/10/20 8:04 PM

Ideas/Decisions Requirements Feedback

(Frame and Context (prioritized) (from Implementation,
for Implementation) Test and Integration)
Deployment
(continuously)
Architecture Implementation
Figure 3.1 Architecture pretzel
Whenever a Scrum Team is refining or working on Product Backlog items, it

has to consciously decide whether the work described is “just work” or has
strategic implications. The standard path is that it is just work that has to be
done, the right side of the pretzel. The team members plan and execute this
work with what they have and know. They close the feedback loop by deliver-
ing the Increment, collecting feedback, and acting on it. Sometimes stakehold-
ers require something that is strategically relevant and that needs work on a
higher level. In such cases, the team deliberately enters this higher level and
works strategically, the left side of the pretzel.
Teams should identify strategically relevant work as soon as possible.

Following are some questions that indicate work that is strategically relevant:
• Do we currently face problems that have implications to a broad area of

•
our product?
• Is it difficult or impossible to implement and deliver a Product Backlog
•
item without changing (parts of) the general structure of our product?
When teams identify strategic work, they have several options: They can put
the strategic part into its own Product Backlog item if they expect a lot of
work leading to the decision. If the strategic work can be done alongside the
59
9780134862156_web.indb 59 06/10/20 8:04 PM

tactical work, we recommend making transparent that there is a strategic

aspect to a specific Product Backlog item. This can be as simple as adding
acceptance criteria describing the strategic decision.
This strategic work and the related decisions, which the team undertakes in
the left half of the architecture pretzel, become input for the right half of the
architecture pretzel, where the team implements the architectural decisions in
the solution. In turn, the learnings from the right part become inputs for the
left part. The precondition is that the team as a whole is fully responsible for
the delivery of a releasable product. If it is not, the chances are high that
learnings from both loops won’t feed back into the process but will have to be
handled outside of the Scrum Team if they are taken into account at all.
Similarly, a central architecture group that is not actively working with the
Development Team can easily miss learnings about suboptimal architecture
decisions that are visible to the Development Team in its daily work.
“Why should we document that?” a backend developer asks. “This way of struc-
turing modules will most likely not be the last solution, as we constantly learn and
update our structure. Doesn’t the agile manifesto say working software is more
important than documentation?”
“Yes, but we should at least describe the current way of working so that everyone
can look it up if needed,” another developer answers. “For example, I don’t usually
work with these modules and am always unsure how to work with them when I
have to touch them. I will feel more comfortable if I can check how it is supposed
to work.”
“But then we will have to constantly update the documentation on top of our solu-
tions. That is really a lot of unnecessary work.”
The Scrum Master has kept silent so far to watch where this discussion is going,
but she now speaks up. “I wouldn’t call it unnecessary if this documentation helps
prevent mistakes and clarify things. It is true, this documentation will need to be
updated when there are relevant changes, so I would like to ask a different ques-
tion. Instead of asking if you need to maintain this documentation, wouldn’t it be
better to ask how you can make sure you don’t forget to do it.”
60
9780134862156_web.indb 60 06/10/20 8:04 PM

Wh y # N o D ocu me ntation I s a Ba d I de a
The first developer in the preceding scenario is correct. The Manifesto for
Agile Software Development states in its second value that working software
is more valuable than comprehensive documentation. This sentence has influ-
enced many teams to disregard documentation altogether, or at least to do as
little documentation as they can get away with. Many software teams claim
that “the code is the documentation.” This claim is shortsighted.
While code should be as clear as possible, both readable and maintainable,

and the structure should be clear and should respect industry standards, it
cannot convey why specific decisions were made or even what those decisions
were. Understanding why something was done often helps later, when situa-
tions have changed and different decisions need to be made. This big picture
and the reasons for doing things a certain way are usually not visible from the
code alone; they have to be explained separately to fellow developers and,
sometimes, stakeholders.
Documenting decisions is not always the most interesting type of work, and it
can become quickly outdated when the team makes new decisions. Since doc-
umentation is written for a reader and not the author, writing that documen-
tation often loses out over more interesting work. Nevertheless, it is
important and needs to be done.
Teams should document with the readers in mind. Understanding the audi-
ence they are writing the documentation for and what those readers need to
get out of it helps teams to create just the right amount of documentation.
Documentation should live as near to the solution as possible. For software,

this means documentation should be versioned with the source code and
included with the build and deployment artifacts. As a developer, if I don’t
need to change tools when documenting part of my solution, the chances are
higher that I will remember to do it. The Docs as Code2 approach helps in
doing this.
2. https://www.writethedocs.org/guide/docs-as-code/
61
9780134862156_web.indb 61 06/10/20 8:04 PM

Documentation should be part of a team’s definition of “Done.” The defini-

tion should specify what type and amount of documentation is needed. This
creates transparency on what can be expected when you deliver a releasable
product Increment.
Documentation is not an end in itself. Frequently, the goal of written docu-

mentation can be achieved more effectively by other means, such as the
following:
• Pairing team members to collaboratively solve a problem when the purpose

•
of documentation is to share and spread knowledge
• Using peer review of work results to define common work standards
•
• Using comments in code to share the intent, decisions, and alternatives
•
considered behind a change, to communicate the thought process as well as
the result
The goal is not to create a standard for documentation but to fulfill the pur-
pose behind the need for documentation.
Tactic s: Wor k from I de a to R e su lt

“How can I discover the most valuable items for my Product Backlog?” the Prod-
uct Owner asks the Scrum Master. “Most of our current Product Backlog is made
up of requests from our users and customers. Marketing and sales collected them
and brought them to me. But I feel that we are missing out on opportunities that
are invisible to them all.”
“Have you tried to deliberately explore the problem and solution spaces of your
product?” she replies. “There are several workshop formats that might be inter-
esting for you. Each of them targets a specific level of abstraction in your Product
Backlog.”
“What do you mean with level of abstraction?”
“Ok, let me explain this. . . .”
62
9780134862156_web.indb 62 06/10/20 8:04 PM

Tactics: Work from Idea to Result
Th e D iffe r e nt L e ve l s of A bstr action of a Product

Bac k log
In its simplest form, a Product Backlog is an ordered list of Product Backlog
items describing work that has to be done for the product. This is the mini-
mum form a Product Backlog has to have, according to the Scrum Guide.
Since the Scrum Guide doesn’t describe everything that could make sense in a
specific context but the basic foundation upon which to build a team’s own
practices, this simple definition of a Product Backlog usually is not sufficient.
Typical Product Backlogs can be viewed from more than one perspective. The
most prominent one is usually the order of items in the backlog. But you can also
look at the backlog from the perspective of different users’ or stakeholders’ needs.
Another way of understanding your backlog is by its levels of abstraction. The

topmost level of abstraction is the product vision, which describes the overall
goals for a product without going into any details. Below the product vision
there are large groupings such as the major features of the product, product
areas, and user types. Those groupings can be broken into smaller pieces to
make them more easily understood. This decomposing of Product Backlog
items goes on through refinement until the Development Team is able to work
on a Product Backlog item and deliver it in a releasable product Increment.
A variety of techniques can help teams with abstraction: If you want to dis-
cover valuable features to achieve a specific goal, you could try impact map-
ping [Gojko12]. This very lightweight workshop format tries to find actors
that can help achieve or impede a goal. It then discovers impacts that those
actors can have either support or obstruct the goal. Finally, it explores poten-
tial deliverables that help achieve the positive impacts and prevent the nega-
tive ones.3
Once you have an idea on concrete deliverables, you can use user story map-
ping [Patton14] to get a clearer picture about how the deliverable would look
and feel and how it would be used to fulfill its goal. With a user story map,
3. See https://www.scrum.org/resources/blog/extending-impact-mapping-gain-better-product-insights for

more information on using impact mapping in a Scrum context.
63
9780134862156_web.indb 63 06/10/20 8:04 PM

you can visualize a usage path through a bigger feature and identify its
smaller parts. User story maps can focus on an existing way of solving a
problem or develop a completely new solution. In a user story mapping work-
shop, users of your product are asked to describe how they solve a specific
problem or how they would like to solve it. They do so by telling the story
from problem to solution. The individual parts of this story are captured as
smaller items that can be ordered according to their value and importance.
Those smaller items are Product Backlog item candidates that decompose a
bigger deliverable, for example from an impact mapping workshop.
Both workshop formats and their visualization techniques are just examples
of how to work with different levels of abstraction in a Product Backlog.
Every Scrum Team has to find, and sometimes invent, its own practices and
tools to work on these different levels. If abstraction is done well, a Product
Owner and Scrum Team are able to talk about the needs of their stakeholders
and the solutions they will provide on different levels. The CEO of a com-
pany is interested in the big picture, so a Product Owner needs to be able to
talk about the higher-level deliverables and milestones. Users are more inter-
ested in the smaller building blocks and how they work together. They want
to know how their problems will be solved. The Development Team is inter-
ested in all of these levels but focuses mostly on the smaller-level Product
Backlog items that can be implemented in a Sprint.
The Scrum Team is in its biweekly refinement session. After the Product Owner
describes a Product Backlog item that should be implemented in the next Sprint,
she asks the question that is dreaded by the Development Team: “Okay, so how
many story points is this story?”
The Development Team thinks for a while, then one after another, the team mem-
bers reluctantly select a card from their hand.
“Let’s see what we have here,” the Scrum Master says expectantly. “Okay, that’s
three times a 5, then we have one 3 and two 13s. I think those with the highest and
lowest estimates should explain their estimate.”
64
9780134862156_web.indb 64 06/10/20 8:04 PM

“Well, the work we have to do is not really difficult,” one of the developers says.
“The change has to be reflected in different areas of the source code, but those
adaptations are simple.”
One developer, who pulled a 13, answers, “True, it is an easy change, but we have
to touch dozens of different places in our source code. And the change is risky.
Therefore, we have to invest heavily in testing that we didn’t break anything.”
“But we don’t estimate effort, we estimate complexity,” the other one interrupts.
H ow to E stim ate M e a ning fu lly

We often see scenes like this in our work with clients, and everybody involved
thinks that this is how you should estimate. And of course, you can estimate
this way. We are convinced, though, that there are better ways of working.
The most important question to ask in such a situation is, What is the goal of
estimating Product Backlog items? In our experience, there are three main
reasons for a Development Team to estimate:
1. To assess the amount of work needed to deliver a Product Backlog item to

be able to forecast the next Sprint(s)
2. To give the Product Owner an idea of how big, and therefore expensive,
something is
3. To see if there is a shared understanding of the Product Backlog item
The first reason for estimates is solely for the Development Team. The second
reason can be used by the Product Owner to judge cost and expected value
and to decide whether the ratio is acceptable for this Product Backlog item to
be implemented. The third is to reach a common understanding of the
Product Backlog item through open discussion.
How well does the estimation session in the case study support those three
goals? Not very well.
Many Development Teams think that in Scrum they have to estimate “com-
plexity.” They think that agile principles forbid them from estimating effort,
65
9780134862156_web.indb 65 06/10/20 8:04 PM

since the exact work needed to completely implement something is often

poorly understood. But what does it mean to estimate complexity? Many
people (including us) are unable to exactly describe what it means. It usually
has something to do with how difficult the team will find it to deliver a
Product Backlog item or how uncertain the team is about what it will take to
implement a Product Backlog item. What is usually neglected is the amount
of work that they expect the Product Backlog item will require to implement.
In our work with teams, we don’t use the term complexity in the context of esti-
mates; instead, we talk about size. This changes the focus from how complex the
Product Backlog item is to how big is it. Most people have an intuitive concept of
size. A piece of work can be big or small, and the size includes uncertainty, risk,
effort, and other aspects that are important to the type of work someone does.
This brings us to the second aspect of estimation that we often miss when
working with our customers: reference Product Backlog items. It is very hard
to estimate size without a reference point. How big is a tree? How far away is
that house? How tall is a person? It is easier for us to answer a comparative
question regarding size, such as Which of those trees is bigger? Is this house
nearer to us than that one? Is this person taller than me?
As a result, we recommend estimating Product Backlog items in relation to other

Product Backlog items. Then we can assign simple size units such as tiny, small,
medium, big, or huge. We can also use a concept such as story points or T-shirt
sizes to assign size attributes to a Product Backlog item. The important thing is
that those attributes relate to something and are not assigned without reference.
The third aspect of estimating that is important also happened in the previ-
ous scenario: The Scrum Master asked the team members with the highest
and lowest estimates to explain their estimates. Asking for an explanation can
signal to the persons estimating that they might be wrong and need to justify
their estimate. This in turn can cause team members to estimate in a way that
avoids being called out on their estimate.
Estimates that differ don’t need to be explained; estimates that differ are an
indication of different understandings of a Product Backlog item. The whole
Scrum Team should be curious to understand these different interpretations
66
9780134862156_web.indb 66 06/10/20 8:04 PM

and should want to come to a common understanding. A question we often

use is, I am curious about what you know that I don’t. Could you please
explain to me what I am missing?
# N o E s t im a te s
Vasco Duarte’s 2015 book, No Estimates: How to Measure Project Progress without
Estimating, explains an approach to forecasting and measuring progress without
estimating. The book led to an ongoing discussion in the agile community about
whether this approach is possible and allowed in Scrum, as an estimate is one at-
tribute of a Product Backlog item.
In our experience, Scrum Teams can use the #NoEstimates approach and still work
according to the rules of Scrum. The minimal “estimate” a Product Backlog item
needs to have is that the Development Team knows whether or not it can deliver
the product in a Sprint. The Scrum Guide doesn’t advocate how to do that.
Teams working with #NoEstimates cut their work into small enough items that
they can deliver it in a few hours or days. This even exceeds the minimal require-
ment described here. Therefore, #NoEstimates is a valid way of estimating Prod-
uct Backlog items, even though it sounds contradictory.
The Development Team stands together in front of the task board for the Daily
Scrum. The team is in the middle of the Sprint and is making good progress.
“There is one thing that would increase our development speed even more,”
someone says.
“What’s that?”
“We should get rid of all this Scrum overhead and use Kanban. We just work from
an ordered backlog and can focus all of our time on getting work done.”
D o We N e e d S c ru m Whe n We H ave K a nba n ?

Sooner or later, many Scrum Teams feel that the numerous feedback loops that
Scrum offers (or mandates, depending on your point of view) are impeding
instead of helping them. The alternative that is suggested usually is Kanban.
67
9780134862156_web.indb 67 06/10/20 8:04 PM

Most people know that the Kanban board visualizes workflow through a pro-
cess. Not so many people know that having a Kanban board is not all there is
to Kanban. Kanban is much more rigorous than that.
True, Kanban doesn’t describe much in terms of process—it just demands

that teams visualize it, however that looks like at the moment. What it also
requires is that teams working with Kanban measure workflow through their
process and improve it continuously. To do this, teams usually measure how
long it takes for work to flow through the process, how many work items
enter or leave the process, and how old the work items in the process cur-
rently are. To improve flow, work in progress is limited.
For us, Scrum and Kanban are not alternative approaches—they work very
well together. Scrum provides a sound structure to work in short cycles and
maximize the value of the work on the macro level. Kanban is useful for
improving the process, collaboration, and workflow on the micro level.
Many teams we work with start with Scrum, focusing first on the macro level.
This means they try to improve their collaboration from the idea for a prod-
uct to its delivery. They create a Product Backlog and work from it to create
releasable Increments of product quickly.
As soon as they become effective at the macro level, they can focus on the
micro level. There they can measure workflow rigorously and improve their
collaboration as a Development Team.
The work in progress limit is the most important factor in optimizing flow. The
rule of thumb should be to minimize work in progress as much as possible, but
not more. The work in progress limit in each workflow state creates a pull sys-
tem, as work can only be pulled from an upstream state if the work in progress
limit is not yet reached in the current state. If it is already reached, the down-
stream state has to pull work that is finished before new work can be pulled.
With this improved visualization of work, Development Teams can visualize

and measure workflow. To do this, they also need to measure relevant metrics
such as cycle time, work item age, and throughput. Cycle time describes how
68
9780134862156_web.indb 68 06/10/20 8:04 PM

much time has elapsed between the start of a work item and its finish. Work
item age is the amount of time a work item is already in progress (i.e., how
long it has already been worked on). Throughput is the number of work
items that are finished per unit of time (e.g., days).
With these preconditions set up, a Scrum Team can optimize workflow by
monitoring the metrics and working on bottlenecks and impediments. The
team can use the Scrum events to analyze the different resulting metrics and
define and implement strategies to improve them.
This short outline gives only a brief glimpse into how Scrum Teams can use
Kanban to optimize their work. To learn more, please read the books on this
topic by Daniel Vacanti:
• Actionable Agile Metrics for Predictability: An Introduction [Vacanti15]

•
• When Will It Be Done? Lean-Agile Forecasting to Answer Your Customers’
•
Most Important Question [Vacanti18]
The advantage of Kanban when used in a Scrum context is that a team

focuses on effectiveness and efficiency. The Scrum Framework, with its focus
on product value and reaching goals in short cycles, tries to enable and
improve the ability to do the right things (effectiveness). Kanban and the
focus on flow and removing obstacles in the workflow increases efficiency.
The Scrum Master has been summoned by the company CEO, who seems puzzled.
“The Product Owner has told me that our Development Team doesn’t have the
velocity we need. Is that true?”
The Scrum Master is surprised; she wasn’t aware that the team’s velocity had been
discussed between the Product Owner and her boss.
“What do you mean, they don’t have the velocity we need?”
“Well, as far as I understand, the velocity describes how much work the team gets
done in a Sprint,” the CEO explains. “And from what we can see, it is not enough
to reach our planned goals. Therefore, we need to increase this velocity, right? I
would like to understand how I can support the team to make this possible.”
69
9780134862156_web.indb 69 06/10/20 8:04 PM

“You are right. The velocity measures how much work the Development Team can
finish in a Sprint. Yet this is not a performance metric, it is a planning metric. We
should focus on measuring value creation, not on how busy our team is. Why don’t
we ask our Product Owner if she is available, and I can tell you a bit more about
this? I think this topic is interesting for her as well.”
“Good idea. Can the three of us meet this afternoon?”
H ow to M e a su r e S ucc e ss
The reaction of the Scrum Master in the preceding scenario is fairly typical.
Many companies measure metrics that are simple to collect but often are not
very meaningful, and velocity is foremost among metrics that organizations
misuse. Velocity measures how much work can be done in a specific Sprint,
but it does not, and cannot, measure how much impact or value this work
has. Put in other words, if organizations measure performance in velocity,
they create busy people, while what they want are happy customers.
Organizations need to switch from measuring output-based metrics to mea-

suring outcome-based metrics. Outcome-based metrics measure the impact of
work, not the work itself. A great collection of sample metrics that Scrum
Teams could use can be found in Evidence-Based Management (EBM), a
framework developed by Ken Schwaber and Scrum.org. EBM looks at the
value an organization produces with its products or services. This value
comes in four Key Value Areas (KVAs):4
• Current Value (CV): Delivered to customers or users today

•
• Unrealized Value (UV): Could be realized by meeting all potential needs of
•
the customer or user
• Ability to Innovate (A2I): Effectiveness at delivering a new capability to bet-
•
ter serve a customer or user need
• Time to Market (T2M): The speed of delivering a new capability, service,
•
or product
4. See https://www.scrum.org/resources/evidence-based-management.
70
9780134862156_web.indb 70 06/10/20 8:04 PM

How to Improve Cross-functionality
Organizations should determine metrics that they find meaningful in each of

the KVAs on which they want to focus, then measure and improve them. Since
those metrics focus on product value, they deliver an indication on the impact
our work has with our customers and users.
Improvement can start in a Scrum Team’s regular Sprint cycle. The Product
Owner will update the stakeholders during the Sprint Review on the current
state of the metrics as measured. During the Sprint Retrospective, the Scrum
Team decides what, if any, metrics could be improved and how. Those
improvements are then implemented, and the changes are monitored. This
continuous cycle of process improvement in small steps is able to generate sig-
nificant results over time.
Chapter 6, “Measure Success,” talks about metrics and how they are used to
drive value optimization in detail.
H ow to I m prov e C ross - functionalit y

The Scrum Master has finished explaining outcome-based metrics to her CEO and
Product Owner. She starts wrapping up the meeting when the CEO interrupts her.
“Since we have you here already, there is one other question that came up the
other day. Is it correct that our whole Development Team works on a single task?
Can you tell us more about that?”
“Yes, the team has decided to try out mob programming,” the Scrum Master ex-
plains. “The experience so far seems to have been promising.”
The CEO and Product Owner look skeptical, but curious. “But that doesn’t sound
very efficient,” the CEO says. “I agree that it is sometimes good to share knowledge
with the whole team, but it sounds a bit too much for me. What is the benefit?”
Coll a bor ation I s a n I m prov e m e nt D r iv e r

Collaboration is a key aspect in enabling high performance in a cross-functional
team. Collaboration enables the team to be (or become) cross-functional, which
71
9780134862156_web.indb 71 06/10/20 8:04 PM

helps its members to share knowledge and skills and create a common under-
standing.
A popular form of collaboration introduced by eXtreme Programming

[Beck04] is pair programming. Two software developers collaborate with each
other; one, the driver, is writing code, while the other, the navigator, reviews
it and offers instant feedback and ways for improvement. They switch roles
frequently to avoid getting stuck in one or the other role. What sounds at first
like a waste of development capacity is a great way to improve skills.
Team members, in pairs, share knowledge about the business domain, code
base, technical practices, tools, and a way of working. This creates a shared
understanding that has benefits in reducing errors caused by misunderstand-
ings, and it makes the code easier to maintain. It also creates an environment
where strengths and weaknesses of team members can be balanced perfectly.
And it breaks up areas of specialism where one person holds all the knowl-
edge and nobody else in the team can take over if necessary. Overall, it is a
productive way to help a team find a common way of working and become
accustomed with each other’s strengths and weaknesses.5
A technique that builds on top of pair programming, though controversial, is

mob programming. Here it is not a pair of people but a whole team collabo-
rating. They share one space, one screen, and one keyboard. Mob program-
ming has the same benefits as pair programming but a much bigger impact,
as it involves the whole team and not just individuals.
Even though pair programming and mob programming have their roots in
software development, the concepts are transferable to any type of work.
Here are some examples where our non-software-centric customers use the
ideas and work as a pair or mob:
• Legal work on documents, contracts, or offers

•
• Conceptual work on user interfaces for new products before the products
•
are developed
5. See the Norming stage in Tuckman’s stages of group development: https://en.wikipedia.org/wiki/

Tuckman%27s_stages_of_group_development.
72
9780134862156_web.indb 72 06/10/20 8:04 PM

• Modeling the risks for financial products
•
• Creating and validating job profiles in an HR department
•
Teams that do not currently work in a pair or a mob are often afraid that the
organization will react as the CEO did in the preceding scenario. We recom-
mend starting small—working in pairs from time to time and measuring the
results. Our experience has been that working in pairs is not inefficient in the
end; the increase in quality through having more eyes on the solution contrib-
utes more than the time “lost” sitting beside a colleague, helping from and
learning with them.
If those small experiments show that there is no negative consequence, a team

can start making bolder experiments. They can set up a mob working session
and test how it feels, empirically measuring what works and what doesn’t. Do
more of the things that work, and stop doing those that don’t.
A while later, the Development Team plans out its day in the Daily Scrum.
“After our mob programming session this morning, I would like to fix the bug in
the new way we store patient records,” one developer says. “I don’t know anything
about this part of the application and would like to learn about it. Who can sup-
port me and would like to work with me on it?”
The data specialist is surprised, but smiles. “That’s a great idea, and I am happy
to work on this with you. I have to finish my current task, but I am available after
that. How about that?”
“That’s great, thanks. Just come to my desk whenever you are ready, and we can start.”
D oe s Eve ryone N e e d to D o Eve ry thing ?

This scene illustrates a common challenge that teams new to Scrum face:
Does cross-functionality mean that every team member has to be able to work
on everything? And does self-organizing mean that every team member can
choose what to work on?
73
9780134862156_web.indb 73 06/10/20 8:04 PM

In general, yes, that is what being a cross-functional and self-organizing team

means. Yet there are a few nuances that we would like to reflect on.
It is true, Scrum doesn’t recognize dedicated experts or subteams inside the

Development Team. It is a cross-functional team that, together, is able to deliver
releasable Increments of product. But this accountability for releasability means
that the team has to choose the best way to deliver a piece of work. Best in this
context means with the quality needed and reducing risk where possible.
In the previous example, an inexperienced developer wants to work on some-

thing he is interested in. This is great, but it would be risky to work on it on
his own. The chosen piece of work is crucial for the functionality to be imple-
mented, and because he lacks experience, his decisions may affect the quality
of the entire team’s work. The work requires experience and expertise that
the developer may not have.
The question for support is a great way to open conversation, show willing-
ness to learn, and find a partner to learn from. The specialist can be the lead
in this work and can teach her colleague how to fix the bug in the patient
records storage component. Pairing up increases expertise in the team and
helps it to become more cross-functional.
Another point that is worth mentioning is the assertion that, in a self-orga-

nizing team, everybody can choose what to work on. Again, this is generally
true. A self-organizing team chooses the way in which it does the work it has
taken on, but this same self-organization does not unilaterally apply to team
members; they cannot decide to do whatever they want without consulting
other team members. The team should find the best way of solving a specific
problem and doing the work. If the developer in the previous scene would
have just stated that he will start to fix this bug, someone else from the team
should have spoken up and started the discussion if this was the right way to
work on this crucial task.
We have often witnessed that team members hesitate to raise their concerns
because they prefer to avoid conflict. The line of thought typically is that
74
9780134862156_web.indb 74 06/10/20 8:04 PM

“someone should interfere now.” Yes, someone should do that. And that
somebody can be anybody from the team.
We recommend that team members speak up whenever they feel something is

going in a wrong direction. State your doubts from your point of view and
without attacking your team member. We found that questions work better
than statements. So, instead of saying, “You shouldn’t work on that because
you lack the expertise,” you might ask, “I fear that this task is too risky to
learn your first steps with it. How could we, as a team, reduce risk and still
have you work on this topic that is of interest to you?”
Scrum Teams need to carefully weigh the risk and individual and team inter-
ests when working on their Sprint Backlog. And if something goes wrong, the
Sprint Retrospective is a great place to discuss the chain of events that led to a
problem and how to avoid it in the future. A great method of unraveling this
is a blameless postmortem.
B l a m e l e s s Po s t mo r te m
In order to get the most out of errors, we need to use them as a data source to
mine and generate learnings.
In 2012, John Allspaw wrote a blog post6 about how Etsy handles errors and mistakes.
Etsy uses the format of a blameless postmortem. Postmortem is Latin for “after death”
and is often used to describe the examination of a dead person to find out the death
cause. The same can (and should) be done after an error or mistake occurs.
Teams and organizations often have these postmortems but focus on the wrong
things: They try to find out who was responsible for the error. The more important
and valuable questions are, What was the sequence of events leading to it? What
can we learn from it? and What do we have to change in our way of working to
avoid it next time?
This is where “blameless” comes into play. A blameless postmortem focuses on the
process, not on the people. Doing so makes it easier for everyone directly involved
to share the events in exactly the way they happened, and it helps them to focus
on creating the knowledge to avoid the same mistake in the future.
6. See https://codeascraft.com/2012/05/22/blameless-postmortems/
75
9780134862156_web.indb 75 06/10/20 8:04 PM

“It is always the same,” the Product Owner complains. “During the Sprint, every-
thing seems to be fine until the last two days—then the problems start. And the
reason is always that errors surface when you run the tests. How can we avoid this?”
The Development Team waits in awkward silence. No one wants to be the first to
speak. After a few uncomfortable seconds, one developer tries to explain. “You
are right—it is annoying. We work on implementing our features and everything
does look good. Toward the end of the Sprint, we are able to test our functional-
ity, and sometimes things don’t work as expected. These errors have to be fixed,
which messes up our plan during the last days of the Sprint.”
“But we are only able to test functionality when it is implemented,” another devel-
oper adds. “How should we test while we are still working on something?”
U sing a Te st- Fir st A pproac h

This is a valid question: How should we test while we are working on something?
Many organizations and teams are heavily influenced by the phase-driven

approach to (software) projects. Every phase follows another one, and testing
is usually the second-to-last phase, right before a solution will be used pro-
ductively. The reasoning behind this approach makes sense at first glance: If
every new thing we build can potentially invalidate already-tested results, we
should refrain from testing until everything is built so that we can minimize
the amount of retesting we have to do.
This thinking is wrong in a complex environment. Because Scrum delivers a

solution in small working Increments, each of which is releasable to custom-
ers and each of which may or may not create value for them, change is inevi-
table. Customer feedback alone will cause a team to have to make changes,
retest that work, and release again. For this reason, teams need to excel at
retesting, because they will need to do it a lot.
This has significant consequences. For a complex problem that has to be solved
over a substantial period of time, it is almost impossible to manually test and
76
9780134862156_web.indb 76 06/10/20 8:04 PM

Coping with Constant Change
retest every aspect of the solution at the end of a working cycle. Manual test-
ing is not going to keep pace; teams have to automate their testing.
One way to automate testing is to start with the end in mind and use a line of
thought that has its origins in software development: test-first development.
This approach tackles every problem, be it big or small, with the question,
How can I validate that I did the right thing? This thinking turns around the
usual approach of testing something after it has been implemented.
The first thing that is created in a test-first approach is the test. For end-user
functionality of a product, this means that we have to think about what the
customer wants to do with the product in a specific context and what should
happen as a result. This test is then described in an executable way; it can
even be a step-by-step description of the manual test procedure. During
implementation of the solution, the people involved in the work can check at
every point whether the solution holds up to the test plan.
Ideally, the team will codify this test procedure and automate it. That way, it
can be re-executed with every change at practically no cost. While this is easy
for software solutions, it is also possible for physical products.7
Coping with Con stant C h ange

Two developers sit together over a change in their source code. They are work-
ing on a Product Backlog item that adds some functionality to an existing feature.
“Okay, now it is working,” one of them says. “We can commit our changes and be
done. What should we do next?”
The other one disagrees. “I don’t think we should stop here,” she says. “We have
made a lot of changes to the existing code base, and I think it is becoming unread-
able. We should refactor the code and make it cleaner.”
7. In the software industry, this way of working is often called Specification by Example or Acceptance
Test–Driven Development (ATDD). For more information, read the great book Specification by
Example by Gojko Adzic [Gojko11].
77
9780134862156_web.indb 77 06/10/20 8:04 PM

“But that isn’t part of this change. Let’s discuss that during tomorrow’s Daily
Scrum. If the others agree, we can talk to our Product Owner and add a refactor-
ing ticket to the Product Backlog.”
“No, I don’t want to have the code running as it is. We agreed that clean and well-
structured code is part of our definition of “Done”, and we have not achieved that.”
Wh y R e factoring I s N ot O p tiona l
Refactoring means changing the internal structure of code without changing
the external behavior. It is frequently used in software development, but the
idea behind it is also relevant in other domains. When functionality is con-
stantly changing, past changes to the product don’t always match current
needs. When this happens, the product needs to be adapted even if doing so
adds no direct customer value.
When you don’t refactor, the quality of the product declines. Subsequent
work becomes increasingly harder, as you spend more and more effort work-
ing around problems without making any real progress toward value and
innovation.
Refactoring is a responsibility of the Development Team. The team is

accountable for the long-term quality it delivers. This responsibility includes
cleaning up code that once was useful but no longer serves a purpose.
Just as a factory owner doesn’t ask its customers’ permission to restructure its
shop floor to better suit current needs, the Development Team doesn’t ask the
Product Owner’s permission to refactor; it is the team’s duty.
So how can a team continuously refactor? There are different kinds of refac-
toring. Martin Fowler, the author of Refactoring: Improving the Design of
Existing Code [Fowler18], separates refactoring from the broader concept of
restructuring. He reserves the term refactoring to mean very small changes
that won’t break functionality for more than a few minutes. Restructuring is
also applicable to big changes that might leave a system in an unbuildable
state for a longer period. In Scrum, we prefer a constant stream of small
78
9780134862156_web.indb 78 06/10/20 8:04 PM

changes and frequent releasable Increments to a system that is under major

construction and is not buildable.
The simplest form of refactoring happens while a team is working on a part

of the product: Someone working on a change realizes that the structure
declines and responds by fixing it within a few minutes. Developers should be
aware of this constant need for refactoring and should look at their product
structure with open eyes. Working in pairs, as a mob, or as peers reviewing the
work of others can help the team recognize when refactoring might be needed.
Making a series of small changes without sufficient refactoring can result in

the need for large-scale restructuring. Development Teams touching parts of a
system that needs restructuring should discuss how they can improve the
structure while working on the next change.
Both refactoring and restructuring require no involvement from the Product

Owner. These tasks are done as part of the day-to-day work of a
Development Team, as natural a part of its work as switching tools for differ-
ent tasks or discussing an open question with a colleague. In other words,
refactoring is just part of the job and is included in the team’s velocity.
Sometimes big changes are needed, such as when the Development Team
discovers a new way of solving a problem that requires extensive changes to
existing code, when an unforeseen feature demands restructuring to be
implemented, or when new technology requires restructuring to be incorporated.
In those cases, the Development Team needs to have a discussion with the
Product Owner. Our rule of thumb is that when the anticipated work will
take more than a few minutes or hours and has an impact on the team’s fore-
cast for the current Sprint, the Product Owner should be informed. If the
team is aware of the need for restructuring before a Sprint starts, it can add
information to the Product Backlog item during refinement. If the team dis-
covers the need while working on a change, the team members must decide
whether to change scope in the current Sprint or make the changes to the
code in a later Sprint. If they decide to do the work in a subsequent Sprint,
they create a Product Backlog item to reflect the work that needs to be done.
79
9780134862156_web.indb 79 06/10/20 8:04 PM

Product Owners who are involved in these discussions can always ask for
more information on why this restructuring is necessary and how critical it is.
Just as car owners should be able to trust their mechanic when the mechanic
tells them that major repairs are needed, Product Owners should be able to
trust their Development Team when it requests a major change in the prod-
uct. Restructuring shouldn’t be done for its own sake; Development Teams
that see a need to restructure a part of the product usually add to its value.
Fix S m a ll Proble m s B e for e The y B ecome

B ig Proble m s
The previous scenario is a good example to illustrate another important point
when it comes to refactoring and continuous change: It is easier to fix small
issues before they become big issues.
When you are working on something and spot a problem, you are mentally
prepared to fix the problem; it is easy to fix it right then. When you (or some-
one else) finds a problem in something that nobody is currently working on,
fixing it is harder: Someone has to stop his or her current work, then take the
time and effort to understand the problem and the code that needs to be
fixed. Only then can he or she fix the problem. The greater the context
change from what this person was working on, the more effort is required.
As a result, Scrum Teams should avoid postponing work. Problems often arise
unexpectedly. It’s natural for a team to want to continue on its planned course
and leave fixing the problem for later. It’s almost always better, at least for
small(ish) problems, to adapt the plan and do the unexpected work immedi-
ately. At the very least, the team should make an explicit decision on whether
it makes sense to fix the problem immediately or defer it and possibly incur a
penalty for having to re-create the mental context of the problem.
When unsure, the team discusses this question as a group. This doesn’t mean
everybody in a team has to be involved, but it helps to have a second opinion
from colleagues about the relative merits of fixing it now or fixing it later. If
they decide to delay, they should make the delay as short as possible.
Sometimes they can do a temporary workaround that makes the problem less
80
9780134862156_web.indb 80 06/10/20 8:04 PM

worrisome without fixing it entirely. The positive effect of a workaround is

that the team can finish its work and tick it off mentally. Unfinished work
tends to be present in our minds and decrease our focus.
The Scrum Master and Product Owner meet in the kitchen. The Product Owner
is happy to be able to catch up.
“Hi,” she says. “How is the Development Team coming along? I haven’t been in the
office for a few days and am a bit out of touch”.
“Oh, it’s difficult. One of the team’s laptops broke down at the end of last week,
and it wasn’t replaced until today; two developers have been pairing full time in-
stead of on a per-task basis, as usual.”
“That’s bad. Why did it take so long? Shouldn’t it be possible to just get a new
laptop?”
The Scrum Master laughs. “Yes, it should be possible. The problem is not getting a
new laptop. The problem is that we have to work through the official process. We
are a small company, but with the processes we have in place, you would think we
were a large corporation. I have done little else besides filling out forms, having
them signed, and discussing next steps with our IT department.”
Wor k with Principle s , N ot R u le s

Many organizations have processes that are not designed to be as responsive
as Scrum Teams need them to be. They have become unwilling captives of
processes that are not intended to be responsive to the needs of people and
teams, but instead serve the needs of the bureaucracy that owns the process.
Young organizations start out with little process and few rules; decisions are
made ad hoc, with little concern for decision-making consistency. As the
organization grows and more people have to collaborate, it develops processes
and applies various rules.
81
9780134862156_web.indb 81 06/10/20 8:04 PM

This in itself is normal and healthy; people need structure to collaborate with
others beyond the boundaries of their own team. A few simple rules are good,
but things begin to go wrong as the number of rules to follow increases. The
bureaucracy creates new rules to fix problems or gaps in the old rules, and so
they layer rule upon rule over time rather than fix the root cause of problems.
A better way of working is to use principles. Principles are more general than
the rules described previously.
One example of a good principle is Google’s “be frugal.” Employees at

Google acknowledge this principle to not waste money and other resources
that Google provides. For example, Google has no strict rules on how much
money an employee is allowed to spend for a flight or a hotel when on busi-
ness travel. Google provides general guidance, in the form of a price range, on
how much such travel usually costs, and then it trusts its employees to make
appropriate decisions. This principle removes a lot of rules around booking
and accounting of business travel. It also empowers employees to do the right
thing and treats them like the adult and responsible persons that they are.
In the previous scenario, the process for acquiring a laptop was put in place
to centralize purchasing so that the company could save money when ordering
equipment. The problem is that it loses far more money by reducing the effec-
tiveness of team members because they cannot get a replacement quickly.
While principles can be abused, the risk is small and easily avoided by making
decisions transparent. In the case of the team in the scenario, the company
could have avoided lost time and productivity if, instead of a lengthy process,
it had established a guiding principle that so long as the team remains within
its aggregate budget, it can spend its money as it deems necessary. The bene-
fits of improving the productivity, motivation, and satisfaction of the team far
outweigh the small benefit of negotiating centralized purchasing discounts.
Changing from a rule-based to a principle-based governance usually occurs

through a long sequence of small steps. In the example, the change starts
when management takes the complaints of the Scrum Team seriously and
works to reduce its process overhead so the team can be more productive.
82
9780134862156_web.indb 82 06/10/20 8:04 PM

Summary
Instead of treating the symptoms of problems with new rules, the organi-
zation considers the cost and risk of different solutions and chooses alter-
natives that increase empowerment and accountability while also increasing
effectiveness.
One question we have found useful in such situations is, What do we need to
change in our organizational environment to prevent this problem from hap-
pening again? This question should be asked under acceptance of Norman
Kerth’s Prime Directive [Kerth01]:
Regardless of what we discover, we must understand and truly believe that

everyone did the best job he or she could, given what was known at the
time, his or her skills and abilities, the resources available, and the situa-
tion at hand.8
—Norman Kerth, Project Retrospectives:
A Handbook for Team Retrospectives
S u m m ary
Complementary practices help Scrum Teams bring the Scrum Framework to
life. These practices are context-specific, so not every practice is useful in
every situation or for every team or organization.
The practices we described are examples that we have seen work for organiza-
tions and teams; you may find them useful, too, but don’t feel that you have
to use them. If you face at least some of the challenges described in this
chapter, you might want to give some of them a try.
As you gain experience, you will find that your complementary practices will
evolve and change. Over time, some practices may become less useful as you
find others to replace them, and you will refine others as you learn more.
Reading books, blogs, and articles or listening to podcasts, watching webi-
8. Kerth’s Prime Directive not only is applicable to Sprint Retrospectives but also is a great guiding
principle whenever we have to improve a situation where people made mistakes.
83
9780134862156_web.indb 83 06/10/20 8:04 PM

nars, and attending conferences and meet-ups to learn from others’ experi-
ences can help you with your current challenges.
And if you don’t find anything that others have tried, why not create your
own complementary practice? You have a team of intelligent and capable
colleagues who know the context of the problem and can come up with a
solution. If you do that, you might want to write about it or speak about it at
a meet-up or conference near you.
The search for ways to improve the status quo through new and improved
practices is constant and requires time. Organizations and Scrum Teams
should accept this and make time in their Sprints to execute experiments to try
out new practices or tools and other ways to improve their way of working.
This culture of inventing and sharing is part of the foundation of success

that Agile and Scrum are built on.
84
9780134862156_web.indb 84 06/10/20 8:04 PM

R ele asable I s Less
Than R ele ased 4
In Scrum, the Development Team delivers at least one releasable Increment of
functionality per Sprint. When Scrum was developed more than 20 years ago,
this was a revolutionary innovation, as it was typical for software projects to
take months or years to deliver releasable results. Since then, much has hap-
pened. Step by step, Development Teams have improved their own ways of
working, and the software industry at large has changed, too. Continuous
integration and test-first approaches to developing software, among other
practices, have helped teams to deliver releasable results continuously in very
small batches. Collectively, these practices and many more have come to be
known as DevOps.
Despite widespread use of the term DevOps, myths and misunderstandings

prevent Scrum Teams from using DevOps to their advantage. Since DevOps is
not defined, there are many different interpretations of what it means. Some
teams think DevOps is the successor to Scrum or that applying DevOps vio-
lates Scrum’s rules. Those teams who decide to use Scrum and DevOps together
often struggle to find a workable balance between the two approaches. In this
chapter, we describe what DevOps means to us and how we have blended
Scrum and DevOps to the benefit of both.
85
9780134862156_web.indb 85 06/10/20 8:04 PM

Chapter 4 Releasable Is Less Than Released
What I s D e vO ps ?
The Development Team sits together on a Friday afternoon, presenting short
talks, discussing technical things they have learned that might help them improve
the way they work, and sharing knowledge with their fellow team members. One
team member has automated their builds and the subsequent deployment to test
environments, and she wants to share her expertise with her colleagues.
“You see, with this simple deployment pipeline, we can automatically deploy to our
test environment and execute different types of automated tests. From the test
environment, our Product Owner and others can also try out new functionality
and share their feedback with us. All of this is triggered by one of us pushing source
code into our central repository.”
“That’s great. That means we now have continuous integration and continuous
delivery, right?” someone asks.
“Yes, that’s true.”
“Awesome. Then we can call ourselves a DevOps Team now, since continuous
integration is part of DevOps.”
“No, it’s not that simple,” another developer says. “We would need a dedicated
DevOps engineer or DevOps department for that.”
“Isn’t DevOps just another way of saying that software development and opera-
tions work more closely together?” a third developer asks.
It ’s a R ole . . . It ’s a Tool . . . It ’s D e vO ps
Some people in the software industry believe that DevOps is enabled by prod-
ucts such as build automation tools and application lifecycle management
tools (a claim often made by tool vendors). Others believe that DevOps is a
role and that teams wishing to implement DevOps need a DevOps engineer
or a DevOps team or perhaps even a DevOps department in order to “do”
DevOps. Still others think that DevOps is just a fancy word to describe the
collaboration between software development and operations.
86
9780134862156_web.indb 86 06/10/20 8:04 PM

What Is DevOps?
The reason for this confusion is that the term DevOps never has been defined.
Some thought leaders in the DevOps community have described what
DevOps means to them, but there is no official definition for it in the way
that the Scrum Framework is defined by the Scrum Guide.
The idea that comes closest to a definition of DevOps is the Three Ways of
DevOps described by Gene Kim and his coauthors in The DevOps Handbook:
How to Create World-Class Agility, Reliability, and Security in Technology
Organizations [Kim16]. The three ways describe the values and principles
behind the practices and tools of DevOps. They describe a mindset and culture
within which software development can deliver better results with less risk.
The Th ree Ways of Dev O p s
Th e Fi r s t Way : Sy s t e m s Th i n k i ng
Organizations take into account the whole value stream of product development,
not just a part of it. The goal of the first way is to optimize the overall system in-
stead of a small subsystem, like a team or a silo of expertise. A major part of this
optimization is the increase of quality and flow inside this system.
Th e S e c o n d Way : A m p l i f y Fe e d b a c k L o o p s
Feedback loops are created and amplified. This means that feedback about results
from the value stream is collected quickly and frequently. Feedback loops are cre-
ated around the overall value stream as well as inside it. This generates understand-
ing and knowledge about the way of working and the results and creates insights
into how to further optimize the system.
Th e Th i r d Way : C u l t u r e o f C o n t i n u a l E x p e r i m e n t a t i o n
a n d L e a r n i ng
The culture of an organization is being reviewed and updated. Failure is a normal
result of experiments and shouldn’t be avoided. Yet failure needs to lead to learning
and new insights that help to further improve the environment. Therefore, the or-
ganization needs to develop ways to ensure that failure doesn’t lead to catastrophe
but to increased understanding. Learning from errors and failure and applying the
new knowledge makes the system stronger and more resilient.
Source: https://itrevolution.com/the-three-ways-principles-underpinning-devops/
87
9780134862156_web.indb 87 06/10/20 8:04 PM

Teams and organizations using these three ways continuously improve their
way of working, including their processes, their tools, and their collabora-
tions. Processes, tools, and role descriptions are the result of pursuing a
DevOps approach, but they are not the source of improvement.
When we work with teams that would like to learn more about DevOps, we
always start with the three ways. We then ask which tools and practices they
think would help them pursue a particular way, as well as what else could
help them. This helps them shift their focus away from how toward why.
H ow D oe s D e vO ps R e l ate to Tool s ?
Automation is typically essential to achieving better results with DevOps
practices. Build and deployment automation, test automation, and infrastruc-
ture provisioning automation are just a few examples of practices that help
teams to “walk” the three ways. Continuous deployment, containerization,
and container orchestration are only possible with tools. Yet tools are not the
most important aspect of DevOps; they are simply a means to an end. Tools
help teams to improve their workflow, create and amplify feedback, and create
an environment in which experimentation and learning can flourish without
introducing instability.
Development Teams often fall in love with tools: Tools are interesting and
necessary to solve problems, and they help teams to reach their goals and cre-
ate value for customers. But tools can’t replace communication and collabora-
tion within a team. Sometimes, excessive reliance on a tool can actually harm
collaboration.
Before you start using a tool, ask yourself why you need it. Will it help you
improve the overall system? Will it enable essential feedback that will help you
to increase your knowledge and understanding? Will it be possible to experi-
ment and learn while at the same time lowering the risk of damage?
Scrum’s Sprint Retrospective is the natural place to talk about opportunities

to improve your processes, tools, and ways of collaboration. When team
members insist on solving a problem with a tool, ask those questions and,
88
9780134862156_web.indb 88 06/10/20 8:04 PM

What Is DevOps?
together, look for other ways to achieve the desired outcome. Team members
often already have the means to improve their current way of working but
aren’t using it effectively. Introducing a tool may merely complicate the prob-
lem and introduce new problems, so make your choices carefully, with full
awareness of the strengths and weaknesses of adding the tool. Tools are often
necessary to solve complex problems, and teams need to know about state-of-
the-art technology that can help them, but in the end, remember the old say-
ing: A fool with a tool is still a fool.
These same cautions apply to DevOps practices, including infrastructure as

code and continuous delivery.
“I heard you are doing DevOps now,” the manager of the sales department says on
entering the Sprint Review. “You realize that it is not enough to align development
and operations, don’t you? We in the sales department want to make sure that
business concerns and customer perspectives are also considered. We have read a
bit about this, and we think we should do BizDevOps.”
One Development Team member inhales deeply in preparation of her answer.
“It’s great that you are interested in how we can improve cross-department col-
laboration. Let me explain to you what DevOps means and how we are trying to
develop a DevOps culture and mindset. Can we talk tomorrow when our Sprint
has started?”
“Sure. Can you send me an invitation?”
I s D e vO ps E noug h ?
The term DevOps was coined by software developers and operations profes-
sionals over a beer. The general idea behind it was to have developers (Dev)
and operations professionals (Ops) collaborate to actually release the product
Increment to customers. As more people have become interested in the
impacts of releasing product Increments to customers, the original scope of
the term has grown.
89
9780134862156_web.indb 89 06/10/20 8:04 PM

As a result, people have tried to add specific topics to DevOps, such as busi-
ness, security, software architecture, and others. Their thinking was that
DevOps is only about software development (production of code and config-
uration) and operations (running IT infrastructure and systems), resulting in
the suggestion that DevOps needs to be expanded to “BizDevSecOps” or even
longer concatenations of abbreviations.
As we described, the first way of DevOps tries to understand the whole value
stream of product development and improve its flow. This value stream
includes everything that is necessary in software development from the time
someone has an idea about a new way to improve the customers’ experience
until the product is actually delivering that new value to the customer. From
our perspective, adding more terms to DevOps isn’t necessary. The DevOps
mindset can be applied to all work streams that create value, which we hope
is true for every work stream. The DevOps culture and practices are also not
restricted to software development but can be used successfully outside of it.
One example of this is the frequently used slogan “Automate everything.” It

refers to the first, second, and third ways, as automation increases flow, can
amplify early and continuous feedback, and supports small and low-risk
experiments and learning in small steps. With this goal in mind, it is useful to
look at every part of a value stream and check what can be automated. It is
interesting how many parts of a process rely on manual work that is error-
prone and increases the overall risk.
It is for this reason that we talk about the DevOps mindset, culture, and prac-
tices not only with software development teams but with every team that is
involved in creating value in a value stream. The cultural aspects of DevOps
that are addressed mainly in the third way help whole organizations to
improve. Consider “error culture”: Many organizations try to avoid error
because they see it as a sign of fault. Both the third way of DevOps and
Scrum view errors as a way to test hypotheses. Organizations that embrace
failure and errors by learning from them increase their systemic resilience.
Avoiding all errors leads to an environment where an error that does happen
often has catastrophic effects on the system. In resilient systems, errors are the
norm and learning from them helps the system become ever more resilient.
90
9780134862156_web.indb 90 06/10/20 8:04 PM

How to Combine Scrum and DevOps
H ow to Com bine S c ru m and D e vO ps

The term DevOps was unknown to most people in the company—only a few mem-
bers of the IT department were familiar with it. At least, that was the case until
the CEO entered the Scrum Team room one morning.
“I have heard that many teams are already leaving Scrum behind and are doing
something called ‘DevOps.’ Apparently, this DevOps thing is all the rage and en-
ables companies to deliver software continuously. I want you to investigate it and
determine whether we can also move from Scrum to DevOps.”
And as quickly as he entered the room, he was gone again.
I s D e vO ps R e pl acing S c ru m ?
It is well known that immature managers are always searching for the next sil-
ver bullet that will solve all their problems, which has led some organizations
to believe that they need to decide between Scrum and DevOps.
DevOps and Scrum share the same roots in an agile mindset. Whereas Scrum
traces its history to the mid 1980s, the term DevOps was only coined in 2009.
Consequently, Scrum and DevOps have slightly different histories and termi-
nology.
Where Scrum talks about the “potentially releasable product Increment,” the
Three Ways of DevOps talk about closing and amplifying feedback loops and
optimizing an overall system. At their core, though, both focus on improving
cross-functional collaboration in teams to solve complex adaptive problems.
The tools and practices that have been developed around the DevOps mindset
are much more concrete than what the Scrum Framework describes, yet noth-
ing in Scrum precludes using DevOps practices and tools.
When we discuss Scrum and DevOps with our customers, we always go back to
the values and principles behind the rules, practices, and tools to understand why
something should be done. Compelling reasons make it easier to compare and
91
9780134862156_web.indb 91 06/10/20 8:04 PM

challenge potential solutions than to focus on the what and how. Understanding
what they are trying to achieve makes it easier for teams to decide whether mob
programming or using a test-first approach will help them to reach their goals.
To answer this section’s question: No, DevOps is not replacing Scrum. The
two approaches complement one another and do not compete, as we discuss
later in this chapter.
The Scrum Team was at a loss when the CEO left the room. The team had dis-
cussed DevOps practices and tools in the past weeks while searching for ways to
improve their software development approach. Their CEO’s appearance restarted
the discussion.
“I really think we should deploy to production more often,” one developer says. “For
our backend services, this should be easily doable, at least for updates that don’t
change the interface used by our mobile clients. That way, we would be able to close
a feedback loop earlier and validate whether an update is valuable and helpful. Over
time, we could even be able to deploy our mobile apps and fat clients more often.”
“Yes, but that would be illegal in Scrum,” another developer answers. “You can
only have a releasable product Increment at the end of a Sprint. It has to be signed
off during Sprint Review first.”
“No, I don’t think that’s true. The Scrum Guide says that we have to have a releasable
product Increment by the end of a Sprint, but it doesn’t say we can’t have one earlier.”
“But how do we get the sign-off if there is no Sprint Review?”
D oe s S c ru m A llow Continuous D e ploy me nt?

When Scrum was first developed, the ability to deliver a releasable product
Increment every four weeks was revolutionary, even impossible, for many soft-
ware development teams. Since then, much has happened. Continuous inte-
gration is now the norm for most Scrum Teams. This means that changes to
source code or configurations are frequently checked into a central version-
controlled code repository, triggering immediate integration and validation.
92
9780134862156_web.indb 92 06/10/20 8:04 PM

Doing so reduces the risk that incompatible code and configuration changes
will accumulate and make subsequent, infrequent (and often manual) integra-
tion complex, expensive, and painful.
Continuous integration only goes so far, though. Many problems and bugs in
software products can be found only when the resulting product has been
deployed and tested on various staging systems. Each of those stages is usu-
ally responsible for a certain type of check or validation (e.g., end-to-end
functional testing, load and performance testing, security testing). Therefore,
many teams extend their continuous integration pipeline to deliver and vali-
date over different staging systems.
The ultimate validation is to have a continuous deployment pipeline that

enables the Development Team to build confidence by continually integrating
and testing every change, on every staging environment, so that successful
changes can be automatically deployed to production as its last step. This is
called continuous deployment, and it’s a great example of how all of the
Three Ways of DevOps work: It improves the workflow from idea to cus-
tomer experience, it creates a feedback loop that helps to improve the overall
system, and it creates an environment where frequent deployments to produc-
tion reduce the risk of fatal failure.
Nothing in this conflicts with Scrum’s rules as described in the Scrum Guide.
As one of the developers in the preceding scenario correctly states, the Scrum
Guide has a minimum requirement of a releasable product Increment by the
end of a Sprint. Teams that deliver working products more frequently over-
achieve this minimum requirement and are able to reap the benefits of the
Three Ways of DevOps.
When teams consider continuous deployment, they often raise a question:

Shouldn’t the product Increment be inspected in the Sprint Review before cus-
tomers use it? This question has two aspects:
• Is the Sprint Review an event to sign off on the product Increment?

•
• Who makes the final decision regarding the productive delivery of a prod-
•
uct Increment?
93
9780134862156_web.indb 93 06/10/20 8:04 PM

The Sprint Review is an event that creates transparency and generates feed-
back. The Scrum Team wants to create transparency about what they
achieved during the last Sprint, namely, the Sprint Goal and the resulting
product Increment. Based on this product Increment, the team wants to col-
lect feedback from the stakeholders on the product Increment to further
improve the value it creates. If a sign-off to release is necessary, it should be
part of the definition of “Done” for the product Increment, and it should be
obtained during the Sprint as part of the continuous deployment pipeline.
The second question is context specific to the environment in and for which
the product is being developed. The decision about a productive release of
functionality is normally a business decision. In Scrum, this means that the
Product Owner should have the last say on whether a set of features should
be delivered to customers. The Product Owner can leave this decision to a
continuous deployment pipeline if he or she is confident enough that the
quality expectations can be met and if no further (manual) checks are needed.
If manual approval is mandatory, this can even be included in many continu-
ous integration and deployment solutions.
One way to still achieve continuous deployment is to separate the parts of a

product that need to be audited and signed off from the rest of the system.
For Product Owners who would like to decide from a business perspective
when updated or new functionality can be used by customers, the
Development Team can take technical measures to make that use configu-
rable. If you are interested in learning more about this topic, please read up
on feature switching, or feature toggling.
After trying different things to do what their CEO asked of them and using
DevOps, the Scrum Team sits in a retrospective reflecting on its success so far.
“I still think we have too many issues using all those new tools and practices,” one
developer says. “Our build and deployment automation works, but more often
than not, it fails. The reason is not always an error in what we did but a glitch in
our scripts or infrastructure.”
94
9780134862156_web.indb 94 06/10/20 8:04 PM

“And we don’t make enough progress,” the Product Owner complains. “All this
fiddling with infrastructure and automation gets in the way of delivering value.”
“That’s true, but it is a necessary precondition for us to move more toward
DevOps. We were explicitly asked by our CEO to do so. You were there and
heard his request.”
“But isn’t Scrum done right one way of following the three ways of DevOps?”
another developer asks. “I mean, we are trying to deliver a product end to end,
we have the Scrum events to close feedback loops on different layers, and we are
always optimizing our practices, tools, and processes.”
S c ru m Pr inciple s a n d D e vO ps C u ltu r e Com ple m e nt

E ac h O th e r
We wouldn’t go as far as the last developer in the preceding scenario, but she
is right in principle: Scrum and DevOps are built on the same agile principles
and values of working iteratively and incrementally toward a goal in a com-
plex environment. As a result, Scrum Teams generally find it quite easy to fol-
low the Three Ways of DevOps. DevOps goes further than Scrum, though, by
making delivery of products, from idea to productive use, the goal of the first
way. This requires more than having a releasable Increment of your product
by the end of a Sprint. It requires the Scrum Team to exhibit a high degree of
technical and processual excellence. For most Scrum Teams, this is an aspira-
tion rather than a starting point.
So how do the Three Ways of DevOps fit into Scrum?
The first way is about improving the overall product development system
instead of just a part of it. This means not increasing efficiency in one part of
an organization, such as quality assurance, in isolation from the entire sys-
tem. Instead, the whole value stream needs to be considered and improved in
areas that need it most to make the whole system more effective. The Scrum
Team, including the Development Team, works as a cross-functional team to
develop and deliver solutions toward a common goal without the need for
outside support. The first way of DevOps perfectly aligns with this autonomy.
95
9780134862156_web.indb 95 06/10/20 8:04 PM

The second way installs feedback loops throughout the overall system of
product development in order to quickly and easily see deviations from the
goal. The Scrum events do the same thing: They use the transparency created
by the Scrum Team in various ways (e.g., through the Scrum artifacts) to help
the Scrum Team to inspect and adapt a specific part of the system. The
Scrum events are concrete examples for the second way of DevOps. The
events are not the only ways to close feedback loops, and Scrum Teams will
find other feedback that helps them further improve their work, but they are
context specific and therefore not defined by Scrum.
The third way creates a culture in which constant experimentation leads to

continuous and low-risk learning. The Scrum Guide uses the term (continu-
ous) improvement to express the same idea. And as with the first way, the
third way of DevOps describes a stricter implementation of improvement, as
it requires the reduction of risk to encourage experimentation and learning.
Therefore, many DevOps practices, such as continuous integration, continu-
ous delivery, continuous deployment, pair programming, and mob program-
ming, aim to reduce risk in closing feedback loops.
Scrum Teams trying to use DevOps to their advantage should look at the
Three Ways of DevOps, not at specific tools or practices that are currently en
vogue. Just as Scrum’s foundation in empiricism is the guiding star for Scrum
Teams when they struggle with a specific element or rule in Scrum, the Three
Ways of DevOps can guide Scrum Teams in their search for further improving
their way of working.
When working with teams that would like to try a new practice or use a new
tool, we usually ask, What does this practice or tool help us do that we are
not able to do currently? This question helps us identify real needs for
improvement and broadens the team’s mind to what else could be done to fix
a specific need. It also helps prevent the use and installment of hype-driven
practices and tools just because everyone uses them currently.
96
M04_Gotz_C04_p085-p100.indd 96 06/10/20 8:51 PM

The one action for improvement the Development Team decided upon during
the Sprint Retrospective was to focus on fixing the issues with the deployment
pipeline in order to improve the delivery of updates to be tested and verified. This
took a significant amount of work during the next Sprint, but the team succeeded.
It was now able to reliably integrate, build, and deploy new releases any time they
needed to.
Two Sprints later, the Product Owner enters the team room after a meeting with
people from the marketing team. She is visibly pleased.
“My meeting was great. I showed the marketing team our change to the scheduling
overview for a specific patient that we planned for this Sprint. They liked it a lot
and want to have it in our productive version as soon as possible. What would be
necessary to put that out to production?”
“With or without all the other changes we have implemented since our last pro-
ductive deployment three months ago?” a developer asks.
“Preferably without. If this is a big problem, we have to discuss with marketing and
sales what they think about a bigger release at this point in time.”
“At the moment, we are unable to deliver parts of a release. We have already dis-
cussed that issue because we see value in it. It is possible with a technique called
feature toggles, where we deliver all the changes but can switch them on or off as
needed. There are several tools available for feature toggle management.”
“That would be great to have. Can you create a Product Backlog item for it?
I would like to discuss it in our next refinement meeting.”
H ow to I m prove Flow U sing D e vO ps

Technical excellence is not an end in itself. Scrum Teams need technical excel-
lence to be able to deliver value continuously and with low risk. DevOps prac-
tices that help teams make progress on the Three Ways of DevOps usually
increase technical or processual excellence. Two examples can be found in the
previous scenario: (1) reliably closing the feedback loop of any change to the
system, then integrating, building, and verifying them continuously; and
(2) being able to deliver continuously and still control what changes can be
used by the end user.
97
9780134862156_web.indb 97 06/10/20 8:04 PM

Development Teams need to be able to communicate measures of value deliv-

ered to their Product Owner and stakeholders lest their striving for technical
excellence becomes a meaningless exercise.
The goal of the Three Ways of DevOps is to improve flow. The first way
improves flow of work from idea to customers through the whole value-
creation chain. The second way improves flow of feedback by closing and
amplifying feedback loops through the value-creation chain. The third way
improves flow of ideas and knowledge by creating and improving an environ-
ment where continuous experimentation leads to a high rate of learning.
Since any progress that teams make on one of the three ways will improve flow
in their environment, how can teams consciously guide their improvements?
The greatest opportunities for improving flow can be identified and actions
can be taken in the Sprint Retrospective. During the Sprint Retrospective,
Scrum Teams should look where their flow is currently impeded. Impediments
might be identified in the flow of communication or work, in the flow of
feedback, or in reluctance to making specific changes because of their per-
ceived risk. In other words, teams should seek out bottlenecks in their current
environment and find ways to manage them in order to increase throughput
and so improve flow. Doing so will improve the flow at the bottleneck and a
new bottleneck appears. By constantly working on the current bottleneck and
improving flow, teams will gradually improve their overall flow, becoming
more responsive and better able to deliver change frequently with low risk.1
In the last two examples, the team first struggles with improving flow in its
deployment pipeline and is unable to reliably close a much-needed feedback
loop. The team works on that issue, and a second bottleneck becomes visible:
the ability to deliver its changes to production more frequently. Once this bot-
tleneck is removed, the organization’s ability to measure value often becomes
the next bottleneck that it needs to work on. As you can see, DevOps is not
only about technology but also about processes and collaboration.
1. See Theory of Constraints as described in “The Goal” by Goldratt and Cox
98
9780134862156_web.indb 98 06/10/20 8:04 PM

Summary
Many companies we work with are amazed by this simple yet powerful way
of continuous improvement. And most ask us one question: When will we be
done with this and have achieved DevOps? Our answer: You have achieved
DevOps when you continuously improve flow and feedback in an environ-
ment that values constant experimentation and learning. Yet you will never be
done improving. You could as well ask, When is a sports team done improv-
ing its skills and ready to just apply what the team has learned and improved?
S u m m ary
DevOps perfectly complements Scrum in ways that were unimaginable when
Scrum was initially developed. Organizations who understand this create new
opportunities for continuously improving their ability to deliver value.
Achieving this understanding, however, means debunking the many misunder-
standings and myths about Scrum and DevOps that we have tried to clear up
in this chapter.
The world of agile product development shouldn’t be a world of this versus

that. It should be an environment where organizations use their ever-growing
understanding of opportunities and challenges and learn how to meet them
collaboratively.
Scrum is a great framework in which various other ideas, processes, and tools
can be used to further improve the way of working. In particular, the Three
Ways of DevOps and the principles of Scrum fit together like hand and glove.
99
9780134862156_web.indb 99 06/10/20 8:04 PM

R esolving Conflict
5
People disagree with each other. Disagreement can lead to conflict that has to
be resolved, but not every conflict needs resolving from the outside.
In this chapter, we discuss different kinds of conflict and what to do with

them, including
• Conflicts that might not even be seen as such and can be solved by the par-
ties involved.
• Conflicts that need outside intervention to resolve.
• Conflicts that have escalated so far that they require extraordinary inter-
vention to resolve.
Since disagreement and conflict is unavoidable, Scrum Teams need strategies

to cope with it. In this chapter, we share some of the strategies we have used
and discuss the options that Scrum Teams have to resolve conflict.
101
9780134862156_web.indb 101 06/10/20 8:04 PM

Chapter 5 Resolving Conflict
Conflict Th at Ca n B e S olve d by People I nvolve d

The Development Team is working on a new feature that enables practice staff
to handle billing the patient’s health insurance provider. Two developers are pair-
designing the workflow and components before they start implementing it.
“Okay, first we retrieve the patient’s insurance information, and then we use that
to create the invoice,” one of them says.
“But we already have the patient’s information at this point in the workflow and
can directly create the invoice,” the other one answers.
“No, we only have the name and contact information. We also need the patient’s
insurance provider and the policy number.”
“I don’t like that. It creates an additional and unnecessary service call. I would like
to change the service interface so that we receive the patient’s data and insurance
information.”
“But this means changing a lot of other calls, because this functionality is used in
many different places.”
“Yes, maybe, but those calls would not have to change, as they are not aware of
the new information and will just ignore it. But my instincts tell me that there are
other places in our system where we use two calls to get this information. With
the change in the interface, we could later fix those unnecessary service calls.”
“Good idea. Let’s do it like that.”
N ot A ll D i sag r e e m e nt s R e su lt in Conflict
All conflict starts with disagreement, but not every disagreement leads to con-
flict. Disagreement is necessary for individuals, teams, and organizations to
learn and grow. If everyone agrees all the time, progress stalls, innovation
stagnates, and the status quo is set and stable.
Scrum Team members often disagree with each other; they disagree on the
order of Product Backlog items, how much work will fit into a Sprint, how
102
9780134862156_web.indb 102 06/10/20 8:04 PM

Conflict That Can Be Solved by People Involved
best to work through a Sprint Backlog, how to implement a specific part of

functionality, and more. They often disagree passionately, and an outside
observer might see conflict. Most of the time, it is just a sign that the mem-
bers of the Scrum Team are passionate about what they are doing and have
strong opinions about the best course of action.
As long as disagreements remain impersonal and stick to facts, the people

involved in the discussion can usually work it out for themselves, and there is no
need to intervene. The people involved in this conflict will exchange arguments
and facts and will struggle for the best solution; often, this solution builds on
the best aspects of the different ideas the people bring into the discussion.
These conflicts share a few characteristics:
• They are passionate, but the discussion remains friendly and kind.
• People involved exchange facts and arguments and don’t try to belittle oth-
ers or their ideas.
• People involved stick to the current question and don’t try to find prece-
dence in unrelated cases.
• People may try to convince each other but not by pulling others to their
side and build alliances.
When discussions depart from these characteristics, conflict escalates and the
people involved may need help working through it. This can be as simple as
suggesting a short break or guiding everyone back to the original question. If
these suggestions don’t help, more involvement might be needed.
“I have tried the new accounting workflow that you deployed to our testing en-
vironment,” the Product Owner says on entering the team room. “It looks good
from my perspective, and I would like to give it to our customers as soon as pos-
sible. Could you please release it without delay?”
103
9780134862156_web.indb 103 06/10/20 8:04 PM

The Development Team is surprised. “This feature is not yet done,” one team mem-
ber explains. “It should be working, but we have to test it thoroughly because it
involves financial transactions, and we can’t afford to experience any problems with
it. We also have made some major changes to existing services that we would like
to discuss with other teams to make sure we don’t break any of their functionality.”
The Product Owner doesn’t like this news. “All that can be done later. I only want
to give this feature to a handful of customers so they can try it out and give me
feedback. I am aware of the risk and willing to take it.”
“We still can’t deploy it,” the developer replies. “We have to do some more work
on it before it is ready for deployment to production.”
“I am the Product Owner, and I’m telling you to deploy this feature. I am respon-
sible for this product, and therefore it is my decision whether something can go
into production or not.”
“I am sorry, but I have to disagree. You are responsible for making the business
decision regarding deployment to production. We are responsible for the qual-
ity of the product and for ensuring that every increment we deliver is releasable
according to our definition of ‘Done’. Until we achieve that, we can’t and won’t
deploy to production.”
This makes the Product Owner really angry. “I still disagree and feel that it’s my
decision to make. I will discuss this with our Scrum Master and CEO.”
Who H a s th e L a st Say?
The Scrum Guide doesn’t describe any hierarchy inside the Scrum Team, nor
does it describe how organizational hierarchy relates to Scrum and the Scrum
Team. The Scrum Team consists of three roles that have different account-
abilities and responsibilities. No role is superior to any other role, yet every
role can make decisions inside its own area of accountability.
The Product Owner decides the quality criteria for the product, how business
value generated by the product will be measured, and how to maximize that
business value. The Development Team decides what work it will do in order to
deliver releasable Increments of product that exhibit the quality criteria the
Product Owner requests. The team is solely responsible for doing the work on
the product, and the team members can decide for themselves how to do this
104
9780134862156_web.indb 104 06/10/20 8:04 PM

Conflict That Can Be Solved by People Involved
work. The Scrum Master decides how best to support the other two roles and
the surrounding organization in their self-organization and continuous improve-
ment. In Scrum, nobody can tell a Product Owner how to order the Product
Backlog. Nobody outside the Development Team can force the team to deliver
product Increments that are not “Done”. And nobody tells the Scrum Master
how to help the Scrum Team and organization get better at what they are doing.
Most organizations we work with aren’t used to these high levels of responsi-
bility and accountability. In a traditional hierarchical organization, there is
always some higher-level manager who can overrule a decision made by some-
one who reports to them. Organizations have to let go of this “override
authority” and learn to respect decisions made within a person’s area of
accountability; when they don’t, the balance of power the Scrum Team has
worked so hard to create collapses.
When an organization can’t give the Product Owner, Development Team, and
Scrum Master the authority to make the decisions necessary for the account-
ability defined in their role, the role is not yet correctly occupied; for example:
• When someone in the organization other than the Product Owner is able to
overrule decisions made by the Product Owner, maybe this person is the
real Product Owner and he or she should explicitly take on the role.
• When a Development Team is not able to decide what work needs to be
done in order to create releasable product Increments or can’t do all the
work, then this Development Team is potentially not yet fully staffed.
• When a Scrum Master isn’t able to support a Scrum Team and organiza-
tion to correctly play by the rules of Scrum and continuously improve,
maybe he or she is not the right person for this role.
Organizations and Scrum Teams who want to be successful using Scrum should
think carefully about how they staff the roles, and they should ensure that the
people in those roles are able to fill them completely by taking the responsibility
and demonstrating the accountability they need to perform their job.
105
M05_Gotz_C05_p101-p120.indd 105 06/10/20 8:53 PM

“He has missed at least half of our Daily Scrums this Sprint and has been late for
the rest.”
The Scrum Team sits together in the Sprint Retrospective and talks about things
that could be improved. Several members of the Development Team have put up
sticky notes complaining about the missing commitment of one developer.
“He is not even participating in our retrospective now,” a developer says. “After the
Sprint Review, he left and said he had real work to do. I think we shouldn’t tolerate
that behavior anymore. I mean, these are the rules we gave ourselves, and he was
involved in scheduling our events.”
“Okay, what could you do about this?” the Scrum Master asks.
The Development Team thinks about this for a while. Then one developer starts
to speak.
“I think we should talk with him, not about him. What if I and one of you ask him
to have a coffee with us and tell him that we are annoyed by his behavior?”
“Yes, that’s a good idea,” another developer responds. “We have to be careful not to
come across as accusatory and let him know we would like to search for a solution
together. I would love to be part of this talk with him. What if we take some time
after the Sprint Retrospective and in the meantime think about how we can best
approach this issue and what we would like to say?”
“Good idea, let’s add this to our improvements for the next Sprint.”
Con flict S hou ld B e S olve d by the People I nvolve d

Conflict often starts with a misunderstanding or a misinterpretation of what is
important. Escalating this conflict too quickly to people outside the group that is
directly involved in, and affected by, the conflict can lead to hardened positions.
Before escalating, first try to have a direct conversation with the parties involved
in the conflict. Perhaps some of the parties aren’t even aware of the conflict.
Take the example of the previous scenario: Members of the Development

Team are angry about one of their colleagues because he doesn’t seem to take
the Scrum events seriously. Maybe his interpretation is different and he thinks
that working on the product is more important than sitting in meetings and
106
9780134862156_web.indb 106 06/10/20 8:04 PM

Conflict That Needs Outside Intervention
talking about work. The first thing that this team needs to do is to reach a
common understanding about the situation. From there, they will find it eas-
ier to talk about changing behavior to meet shared expectations.
Conflict is stressful, and resolving conflict is difficult and sometimes unpleas-

ant. Many teams try to avoid it by asking the Scrum Master or their manage-
ment to resolve conflicts that they should resolve themselves. The team in our
example didn’t try to pass on the conflict to anyone else, which is usually a
good sign. It leaves responsibility with the people involved in the conflict,
thereby strengthening self-organization.
When teams try to shift responsibility for conflict to someone else, ask them what
they can do to resolve the conflict on their own. If the team doesn’t seem to be
able to find potential solutions, be persistent in asking; someone in the team usu-
ally comes up with a possible solution they can try. But be careful: This approach
only works for conflicts that have not become personal and are still focused on
the facts; once the conflict becomes personal, teams usually need outside help.
Conflict Th at N e e ds O ut side I nte rve ntion

The two developers have talked to their colleague as they agreed to do in the
Sprint Retrospective. The developer said that he feels work on the product is
more important than discussing and planning during the events, but he under-
stands that the rest of the team sees this as breaking their mutually agreed-upon
rules. He agrees that he will attend the events, on time, and be fully present, on the
condition that unnecessary discussion will be minimized. The entire Scrum Team
discusses this after the next Daily Scrum, and they agree that they can and should
speak up if they think time is being wasted in order to come back to the point.
This solution works well for a few weeks until the developer again starts to come
late to Daily Scrums. When he comes late to the next Sprint Retrospective, the
atmosphere is already heated.
“Didn’t we agree on being on time?” one developer starts the attack. “This Sprint,
you came late to our Daily Scrums at least three times. You are not honoring your
agreement.”
107
9780134862156_web.indb 107 06/10/20 8:04 PM

“I am sorry for being late. I was working on this very important feature that we
promised to deliver. I had trouble getting it to work. And since none of you helped
me out because you were talking about your work items in the Daily Scrums, I had
to fix it on my own. I think the Sprint Review and the great feedback we just got from
our stakeholders shows that my commitment to getting this running has paid off.”
“Well, it may have paid off this time. But this is not just about you. We don’t need
a hero to rescue us, we need a team player, something you have never been.”
At this point, the Scrum Master intervenes.
“Okay, I think we need to stop and take a moment to collect ourselves. I don’t want
us to discuss this on a personal level; we need to stick to the facts of the situation.
And one more thing: Please don’t make assumptions about the other person’s mo-
tivations. If you are interested in that, you can ask. Let me summarize what I have
understood so far, and then we can continue to find a solution for this conflict.”
H e a lth y Con flict Th at E sc a l ate s

Conflict escalates in stages. The first three sections in this chapter described con-
flict that can be resolved in a win-win situation for everyone involved. Friedrich
Glasl has described nine stages of conflict grouped in three levels (see Figure 5.1).
Together into the
Lose-Lose
abyss
Total annihilation
Limited
destruction
Threat strategies
Win-Lose
Loss of face
Coalitions
Actions instead
of words
Win-Win
Debate
Tension
Figure 5.1 Stages and levels of the Glasl model
108
9780134862156_web.indb 108 06/10/20 8:04 PM

If a conflict at one stage is not resolved, the parties in conflict will escalate to
the next stage of conflict which makes it more difficult to resolve.1
This has happened in the preceding scenario. The team worked on the conflict
in the past and appeared to have resolved it. Subsequent events caused the
conflict to resurface, and it became personal; the focus of the conflict
switched from the behavior of the people involved to who or what they are
and aren’t. The parties in conflict create an atmosphere of us against them.
Conflict in this stage needs intervention from outside the conflicting parties.
The Scrum Master in our scenario steps in and interrupts the increase in ten-
sion and aggression and tries to bring the discussion back to a factual basis.
There are a few tools that can help to de-escalate and resolve conflict:
• Systems theory: Seeing groups of people as interrelated and interdependent

individuals where changes in one part will affect other parts or the whole
system, in contrast to a mechanical or strictly behavioral model in which
cause and effect can be predicted on the basis of function or behavior2
• Nonviolent communication (NV): A structured approach to conflict, by
Marshall Rosenberg [Rosenberg15], that helps avoid “violent” means of
communication such as coercion or manipulation and instead sets the focus
on human needs, feelings, and perceptions
• Focusing on solutions: A goal-directed collaborative approach based on the
psychotherapeutic work of Insoo Kim Berg and Steve de Shazer; it focuses
on solutions in order to improve the status quo, not on problems3
• Consensus decision-making: A group decision-making process that mea-
sures resistance against a proposal and finds ways to improve it until it is
acceptable to the whole group4
Scrum Masters should be able to work with their teams to resolve conflict,
and some or all of these approaches will help. It also helps if everyone work-
1. For more information, see https://en.wikipedia.org/wiki/Friedrich_Glasl%27s_model_of_conflict_escalation.

2. https://en.wikipedia.org/wiki/Systems_theory
3. https://en.wikipedia.org/wiki/Solution-focused_brief_therapy
4. https://en.wikipedia.org/wiki/Consensus_decision-making
109
9780134862156_web.indb 109 06/10/20 8:04 PM

ing in a team has a basic understanding of how conflict works and how it can
be used in a constructive way.
Co m p ro mis e ver s u s Co n s e n s u s
Making a decision requires weighing several options against each other to make
a choice. Those options are often heavily influenced by opinions about possible
solutions. Many people try to convince others of the superiority of their solution,
and they tend to find fault in the solutions of others. The decision process turns
into a fight for agreement or compromise, sometimes grudging, between parties in
conflict. The resulting decisions can leave a residue of this conflict when the result-
ing solution becomes a patchwork of different options to which no one is really
committed.
Consensus provides a different approach to reaching a group decision. To reach
consensus, the members of the deciding group present their solutions to the oth-
ers. For every solution, the group measures the combined resistance of its mem-
bers by having each person rate his or her own resistance to this specific solution.
Many agile teams use the “fist of five”5 to do that and show the fingers of one hand
to signal resistance, where showing all fingers means “I have no resistance; this op-
tion is great,” and showing a fist with no fingers means “I can’t accept this solution
and will actively sabotage it if it is selected”.
For the options with the lowest resistance rates, the deciders now ask each person
what needs to change for his or her resistance to decrease, and the group mem-
bers propose changes. The changed solutions are resistance rated again by the
group, and the process repeats until the group feels that one option is acceptable
or until they decide that no option will ever be acceptable.
In contrast to compromising, this process reaches a consensus by having everyone
consider how they can reduce their own resistance. People don’t try to convince
others of their solution but invite them to change it and make it better. Doing this
tends to increase the motivation of team members to work together to design the
best possible option. It also increases their commitment to the solution by increas-
ing collective involvement.
To make it easier to find a consensus, here are a few tips:
• Always offer one option where nothing changes and include it in your ratings; if
the status quo hurts, it is often easier to think about ways to improve options.
5. https://agilefaq.wordpress.com/2007/10/21/what-is-fist-of-five/
110
9780134862156_web.indb 110 06/10/20 8:04 PM

• As a group, agree on what value of resistance signifies a veto (e.g., two or fewer
fingers in a fist of five voting); options rated with those values can’t be selected,
as they would be not supported, at the least, and might even be sabotaged).
• Instead of a fist of five voting, you can use Roman voting (thumbs up, middle, down).
• The options and ratings can also be collected by people affected by a decision
and handed over to the deciders to help them find a solution.
Another conflict that the Scrum Team experiences is much more subtle. One
developer has always been introverted and quiet, but in the last few Sprints, the
Scrum Master thinks she is even quieter than usual. She doesn’t seem to socialize
with the rest of the team and fully focuses on her work. One day, the Scrum Mas-
ter meets her on the way to the Sprint Planning.
“Hi, good to see you,” the Scrum Master greets her. “How are you? Is everything
all right?”
“Oh, I am fine, thanks.”
“I’m glad to hear that. I have been thinking that we haven’t seen or talked to each
other very much in the last few weeks.”
“Well, there is a lot to do. I am busy working on my tasks, that’s all.”
“All right. If I can help you with anything, please don’t hesitate to reach out. It is
important to me that we as a team support each other if necessary. Okay?”
“Yes, thanks.”
S om e Con flict N e e ds to B e U ncove r e d

This doesn’t sound like conflict, does it? When people talk about conflict,
they usually talk about conflict between people; this is not the only conflict
that exists. Therefore, when working in and with teams, it is a good idea to
also watch for someone who seems to experience conflict that is not directly
visible.
111
9780134862156_web.indb 111 06/10/20 8:04 PM

In the previous example, there were some indicators that worried the Scrum
Master: The developer changed her usual behavior and became increasingly
silent and reclusive. Sometimes people try to mask an internal struggle by jok-
ing more than usual or becoming more talkative, but only about certain top-
ics. Working closely with people, listening to them, and knowing them well
helps in detecting changes in behavior that may signal internal conflict.
When you sense that someone is experiencing an internal conflict, the easiest
way to address it is to have a conversation. We think a heartfelt “How are you?”
is a good start; if you show that you are genuinely interested in the answer, you
usually will get one if the other person is open to sharing how he or she is feel-
ing. Even if the person is not ready to talk, signaling that you are interested in
his or her well-being opens the possibility for subsequent conversations.
In our experience, it is neither unusual nor bad if people don’t open immedi-
ately to a conversation; it is often difficult to talk honestly about a conflict with
another person, especially when many people’s concept of professionalism
doesn’t leave room for expressing emotions. Often, when they consider the
opportunity to express themselves, they come back and take it.
Offers of support must be unconditional: They can be accepted or rejected,

and there must be no consequences or stigma of rejection. Don’t force
unwanted “help” on someone, no matter how sincere the intent. Some people
prefer to work out conflicts for themselves, or they don’t want to discuss their
concerns, or maybe they just don’t want to discuss them with you. It may
even be that they don’t have any issue and your intuition is wrong.
“Do you have a minute?”

The Scrum Master turns around, surprised. She is on her way back from the Sprint
Planning to the team room. “Sure, how can I help you?”
“I wanted to say thank you for your offer when we met before the Sprint Planning.
There is something I would like to discuss with you if you have a moment.”
112
9780134862156_web.indb 112 06/10/20 8:04 PM

“Sure, I wanted to grab a coffee from the kitchen. Do you want to come with me,
and we can search for a quiet space in the lounge and talk?”
“That would be great. Thanks.”
When they are settled in the lounge, the Scrum Master asks again, “How can I
help you?”
The developer takes a deep breath and thinks about how to start. “I am in a bit
of trouble with my department head at the moment. He took over the role last
month and has been asking me to help him learn about what we are doing and how
we work. I have been in this department for a long time and know what needs to
be done and who specializes in what topics. While I am honored that he has asked
for my insight, it is taking time away from my work on the Scrum Team. I can’t keep
up with the work I need to do to support the team and help my boss learn about
our department.”
“That’s bad,” the Scrum Master responds. “I understand why it worries you. Let’s
think about what we can do and how I might help.”
B e Loya l to th e S c ru m Te a m or to You r
D e pa rtm e nt?
Traditional organizations are often organized in a matrix, with people placed
in functionally specialized departments and on a Scrum Team (or even on a
traditional project team).
As long as the goals of the (vertical) department and the (horizontal) Scrum
Team align and team members can focus on their Scrum Team–related work,
this can work well enough. Problems begin to creep in when people have to
decide where their loyalty lies: Do they feel most loyal to their department, or
are they more loyal to their Scrum Team? Since their line manager usually has
a great impact on their future career, they often choose to follow orders from
their manager even though they are formally assigned to a Scrum Team. Most
people also don’t want to let down their fellow team members, so they try to
keep up with the workload in the Scrum Team as well.
The first step to resolving this problem is to make it transparent and visible.
The person involved in this situation needs to be able to voice his or her
113
9780134862156_web.indb 113 06/10/20 8:04 PM

conflict. A Scrum Master can be a great ally here and can help to address the
problem with the right people: the Scrum Team, especially the Product Owner,
and their manager, all of whom need to be made aware of the negative conse-
quences of uncertainty, overwork, and increased errors in work results.
Resolving the conflict usually requires intervention by the person in the orga-
nization’s hierarchy who can decide for both the direct manager of the
employee and the Scrum Team they work in. That person must make clear
where priorities lie and what type of work has precedence over another. If this
doesn’t work, the conflict will usually escalate and become unresolvable, lead-
ing to greater problems. We talk about this situation in the next sections.
Toxic Conflict Th at N e e ds Stronge r

I nte rve ntion
“I have discussed this problem with the other members of your Scrum Team as
well, as it is personally important to me,” the head of the software development
department says to the developer.
They are sitting in their annual performance review and are currently discussing
the personal goals of the developer.
“I have already thought about what I think would help me become better in my role
as a software developer and would like to discuss it with you,” the developer starts.
“Let me first tell you what is necessary from my point of view, and then we can see
how your ideas fit into that, okay?”
“Sure.”
“First of all, it’s great that your team has adopted Scrum so quickly. We’re all
very happy that this new approach seems to be working. One thing is a bit disap-
pointing, though: We expected slower team performance in the first few Sprints,
but then your performance should have increased. It has been increasing, but at
a slower rate than we expected. At the current pace, our organization won’t be
able to achieve our business goals. We believe that your team has to focus more
on creating real value and deliver more features instead of optimizing technology.”
114
9780134862156_web.indb 114 06/10/20 8:04 PM

Toxic Conflict That Needs Stronger Intervention
“But you know that a lot of the work we do at the moment is cleaning up and fix-
ing issues that were introduced in the past when we didn’t focus enough on good
architecture and design. This made us fast at first, but it slowed us down in the
long run.”
“Yes, I understand that. And I’m not saying you shouldn’t work on becoming more
technologically excellent. But we also need to deliver value to our customers. And
the speed with which we are doing that at the moment is not fast enough. I have
prepared a team goal for you and your colleagues to increase valuable output by
fifteen percent compared to the last six months. If you have more capacity, you can
work on the technical improvements, of course.”
Put ting Pr e ssu r e on the S c ru m Te a m

We often see the preceding scenario in this or a similar form at our customers
where teams are adopting the principles and rules of Scrum and are starting
to shape their environment in order to deliver working, valuable products
more frequently and with higher quality. This often means having to clean up
after past decisions that shortchanged quality in order to meet artificial dead-
lines. Organizations that are expecting quicker improvement and faster deliv-
ery of value to their customers can be disappointed with the performance that
they see in the short run. In response, they sometimes resort to giving direct
guidance on what the Scrum Team has to do and how the team has to work
in order to achieve those goals.
Taking away self-organization and putting pressure on a Scrum Team kills

motivation and can destroy the team’s ability to make continuous improve-
ment. It also undermines self-organization and causes the team to question its
ability to make decisions. By being forced to focus on short-term productivity
goals and neglect long-term improvement, the progress that the team was
starting to make during its first Sprints can be largely undone.
Conflicts such as this one need strong intervention by the Scrum Master. He
or she needs to explain to the organization’s managers why Scrum Teams
need to be self-organized in order to improve the overall system in which they
are working. Self-organization helps teams feel accountable for their area of
work and to actively and effectively find ways to improve.
115
9780134862156_web.indb 115 06/10/20 8:04 PM

Being micromanaged is demotivating. It destroys the self-organization and

accountability that Scrum Teams need to nurture to achieve higher perfor-
mance. Teams and individuals fall back to merely following orders, even when
they see that their orders are wrong and lead to bad outcomes.
To maximize business value using Scrum, organizations must create and nur-
ture an environment in which self-organization can happen. This needs
boundaries (compare Chapter 2, section “Missing Self-organization”) that
separate the area of self-organization from the area that is defined and orga-
nized by other parts of the organization (e.g., management). Once these
boundaries are defined, the organization needs to trust that its employees will
use the environment in the best possible way to increase value. If an organiza-
tion doubts its employees’ competencies and capabilities, it can start with
narrower boundaries that are broadened as the team builds trust. Giving
teams a lot of autonomy and then taking it away leads to demotivation,
whereas progressively broadening boundaries helps to build trust and auton-
omy. It can also help Scrum Teams become accustomed to self-organization
and finding their way gradually into newly given autonomy.
The team is meeting for the Sprint Retrospective. As the team collects informa-
tion about the last Sprint that it would like to discuss, several team members bring
up an old conflict that has been discussed for over a year: One colleague has dif-
ficulty accepting team decisions and following them. It started with his not joining
Scrum events because work was more important than “just talking.” Over time,
the team has tried repeatedly to reach agreements with him that he could respect
and commit to. He changes his behavior for a while but always slips back to being
disengaged.
“We have tried so often now, I am sick of it,” one developer bursts out. “It seems
as if you don’t take us seriously and just want to do whatever feels important to
you. You don’t really care about this team, do you?”
“Wait a moment,” the Scrum Master intervenes. “Let’s try to stick to facts and
not interpret each other’s actions. What I hear you saying is that you are very
frustrated that not everyone on this team respects the rules we give ourselves.
And this makes you angry?”
116
9780134862156_web.indb 116 06/10/20 8:04 PM

Toxic Conflict That Needs Stronger Intervention
“Yes, it does. And we don’t have to beat about the bush. Everybody knows who is
this ‘not everyone’ you are talking about. I want to have a solution for this issue. We
waste too much time waiting to start meetings because we don’t know if he will join
us. And we have spent too much time talking about this disrespectful behavior and
discussing solutions that only get broken shortly after everyone agrees to them.”
“Okay, let’s try to take this step by step,” the Scrum Master tries once more.
“I think this has gone beyond what we can solve in our Sprint Retrospective. I sug-
gest that we calm down and schedule a meeting with everybody involved that is
dedicated to solving this conflict. All right?”
A lte r a Te a m to Protect It
Sometimes a conflict goes so deep that it can’t be resolved by the parties
involved. Feelings have been hurt, expectations have been failed, and trust has
been destroyed. If conflict escalates beyond level three, the team needs outside
support to reach a resolution. When it escalates beyond level six, even outside
help won’t achieve a satisfactory solution; instead, the parties need to be sep-
arated in order to limit further damage.
Scrum Masters must detect conflict and listen closely to understand the situation.
At early stages of conflict, this means encouraging open conversations, encourag-
ing team members to understand each other’s point of view, and mediating reso-
lutions. When conflict has escalated to the point where relationships are too
damaged, the Scrum Team may have to be split up. This always is a painful deci-
sion, like the end of a friendship or the dissolution of a marriage. The hurt and
grief must be acknowledged, and every side needs to be heard and understood.
When we encounter such conflicts, we seek professional support in conflict resolu-

tion, as we are not trained mediators. Management also needs to be involved, as
new jobs or roles have to be found for at least some of the team members; some-
times letting people find a different role or a different team in a new and unbur-
dened environment is the only way to move on from the conflict. This needs to be
decided together with the people involved, not for them.
Experiencing escalating conflict is distressing for everyone involved.

Therefore, it is imperative for Scrum Masters to react early and decisively.
117
9780134862156_web.indb 117 06/10/20 8:04 PM

Avoiding conflict, hoping it will go away on its own, is a natural reaction, but
conflict is usually much easier to deal with if you can bring it to the surface
where everyone involved can acknowledge it and start confronting it. When in
doubt, state it as a question and announce that you aren’t sure if there is con-
flict but that you sense something is wrong. If you are wrong, you will find out
quickly; if not, you will be happy later when the conflict has been resolved.
Ty p e s of Co nf l ic t
The examples of conflict used in this chapter represent different types of conflict.
Conflict can be categorized in many different ways. We use the conflict types de-
scribed by Vigenschow, Schneider, and Meyrose in their German book Soft Skills
für Softwareentwickler [Vigenschow19]. Since no English translation of this book is
available yet, we briefly describe the types of conflict the authors define plus the
way to resolve them:
• Factual conflict
• Cause: Different opinions collide in factual discussion
• Solution: Provide facts and settle understanding
• Interpersonal conflict
• Cause: Fears, needs, feelings are not appreciated sufficiently
• Solution: Listen, appreciate, and value each other
• Goal conflict
• Cause: Contradictory goals and/or interests collide
• Solution: Reveal underlying needs
• Values conflict
• Cause: Diverging deep convictions collide
• Solution: Appreciate differences and develop rules
• Role conflict
• Cause: Expectations for a role differ from those of the person implementing
it
• Solution: Reveal priorities and determine responsibilities
118
9780134862156_web.indb 118 06/10/20 8:04 PM

Summary
• System conflict
• Cause: Conditions outside of own scope trigger conflict
• Solution: Escalate conflict to people in charge; concentrate on scope
These types of conflict together with their level of escalation according to Glasl
define the tactic of conflict resolution.
S u m m ary
Conflict inherently accompanies collaboration. In most cases, people disagree,
sort out their different perspectives, and resolve the problem on their own;
afterwards, no one gives the conflict a second thought.
Sometimes, however, they can’t get past their disagreements; their conflict
escalates, and disagreement on factual questions transforms into disagreement
on a personal level. Sometimes conflict has a way of self-amplifying until the
smallest additional conflict causes a team to break apart.
Conflict needs to be acknowledged by all parties involved, even if they

observe different levels of escalation. It then has to be actively confronted in
order to be resolved. Creating conflict awareness is the precondition to con-
flict resolution.
Scrum Masters should have at least a basic understanding of how to resolve

conflicts. They needn’t be experts in conflict resolution, but they need to be
able to de-escalate and bring together people who don’t want to talk to each
other. A simple technique we have found useful is to listen closely, actively,
and with empathy to what people say. Active listening 6 means being fully
present and trying to understand what has been said, while frequently mirror-
ing your own understanding in order to clarify and better remember. This
slows down the dialog and can help to create a better understanding and
empathy among the conflicting parties.
6. For more information see https://en.wikipedia.org/wiki/Active_listening.
119
9780134862156_web.indb 119 06/10/20 8:04 PM

Unresolved conflicts have severe consequences, especially in the working envi-

ronment where it is often easy to avoid conflict. They lead to resignation and
detachment from work. Often, people resort to working by the rules and stop
thinking creatively and with motivation. This leads to decreased effectiveness
and efficiency, but worse, it can easily lead to health issues and psychological
and physiological problems, not only for the parties involved but also for peo-
ple working around them.
In retrospect, we wish we had actively addressed conflicts earlier and more

often. We would have avoided a lot of unnecessary hurt and grief if we had
taken time to work with people to create a common understanding of the sit-
uation. Take conflicts seriously, and don’t hesitate to give voice to your intu-
itions. It is better to have asked one too many times than not often enough.
120
9780134862156_web.indb 120 06/10/20 8:04 PM

M e asure S uccess
6
Scrum Teams need transparency to be able to work successfully in an empiri-
cal way. But what metrics should they collect and how should they use the
metrics to improve their work results as well as their way of working?
In the first part of this chapter we will talk about strategic metrics that help
the Product Owner optimize business value to realize the product vision. To
find these measures, she needs a good understanding of what is valuable for
the product’s customer, and how to measure their experience of value. There
usually is no one single measure of value, and finding the right ones usually
requires insight and experimentation.
The remainder of the chapter focuses on measures that a team can use to
assess and improve its own work. These measures help the team to improve
and create transparency about their work to the broader organization.
While transparency is one of the pillars of Scrum and essential for empirical
work, teams must be careful about what they measure and share because
measures taken out of context can be misused. To avoid this, we will also dis-
cuss how to anticipate these problems while still seeking greater transparency
throughout the chapter.
121
9780134862156_web.indb 121 06/10/20 8:04 PM

Chapter 6 Measure Success
Wor king Towa r d G oals

Sitting in the conference room, the team nervously awaits the CEO’s arrival at the
“Next Release Date” meeting that he called on short notice.
“It’s great to see you all here,” he says on entering the room. “I want to discuss a
recent event that affects us all. One of our competitors has just announced a fea-
ture that will allow patients to schedule their own appointments. The feature will
be available next month, just two weeks before our next release. This was one of
the key features in our marketing campaign for our release, and I would like us to
be the first ones to offer it. This means we need to deliver the release earlier so
we can beat them to the market. How can we do that?”
We N e e d to D e live r Fa ste r
Nearly every team has faced, or will face, external pressure to deliver faster
and reduce its time to market. Many organizations turn to Scrum to solve this
problem, but just adopting Scrum will not automagically guarantee that a
team will deliver faster.
To deliver faster, Scrum Teams must improve collaboration and the workflow
inside their team, often by reducing hand-offs and delays caused by their old
phase-driven, skill-siloed way of working. Those phases (e.g., analysis, design,
implementation, test, delivery) are usually executed sequentially, so many peo-
ple think that it is only possible to work on the different aspects of product
delivery in sequence. And the phase-driven, siloed approach is so common
that many people assume that it is the only way to work.
It is not only possible, but often essential, to break up these phases and help
teams to work in an integrated and cross-functional way. One example of
doing so is to start with the end in mind and think about how to validate
functionality at the same time as thinking about a possible solution for a
problem. It is not only possible to define tests at the same time you are imple-
menting the solution, it is essential to eliminate delays and bottlenecks caused
122
9780134862156_web.indb 122 06/10/20 8:04 PM

Working Toward Goals
by late testing, especially in an environment in which tests can be executed

automatically as part of a continuous integration process.
Teams also benefit from working together more closely when everyone on the
team adds their expertise and knowledge to their shared solution that they
can build and test together, instead of working on different teams on a small
part of the solution where they rarely see the overall result.
Scrum Teams can also increase their speed of delivery by reducing waste, or
non-value-adding, unnecessary steps, in their process. To reduce waste, they
first must have a good understanding of their current work process. They can
increase their understanding by making their work process visible by identify-
ing each step that work has to go through and then identifying:
• Value-adding steps that are essential.

•
• Non-value-adding but necessary steps that have to be performed but that
•
may be streamlined.
• Non-value-adding, unnecessary steps that can be removed from the process.
•
This simple variant of value-stream mapping1 helps challenge and ultimately
improve processes that have often grown over time until they are heavy and slow.
In determining which steps are unnecessary and which steps can be simplified,
quality should not suffer. This means that the Development Team must
• Understand the qualities that any solution must meet for it to be releasable.
•
• Ensure that these qualities are reflected in its definition of “Done”.
•
• Adhere to its definition of “Done” when making release decisions.
•
Scrum Teams who short-cut quality to speed delivery typically create more
problems than benefits; at best, they create technical debt2 that they have to
deal with later, but they risk reducing customer satisfaction when they cut
1. See https://en.wikipedia.org/wiki/Value-stream_mapping.
2. A term coined by Ward Cunningham in 1992 that compares badly designed code to borrowing money
and the extra effort needed to work with this code to paying interest. See a good explanation with
more information at https://www.martinfowler.com/bliki/TechnicalDebt.html.
123
9780134862156_web.indb 123 06/10/20 8:04 PM

corners on quality. The responsibility for not reducing the quality goals lies
with the Product Owner, while the Development Team is responsible for
delivering on those quality goals.
Three and a half weeks later, the Development Team has done the unimaginable: It
has beaten the competitor to market. By aggressively focusing on the goal and not
working on anything else that would distract the team, it has implemented and de-
livered the self-service appointment feature one week earlier than the competitor.
Four weeks later, the Scrum Team is gathered with the stakeholders in a Sprint
Review. The CEO is among them and interested in getting some information about
the market reception of the last release.
“How did we do? What do our customers think about the new functionality? Are
there any problems with it?”
The Product Owner hesitates a bit. “No, there are no problems with this piece of
functionality,” she says. “But it seems that not many of our customers are actually
using it. We have measured usage of this feature and found that only twenty-three
percent of our user base has even tried it. Out of those, only around four percent
have used it more than once.”
“But how can that be?” The CEO is incredulous. “We asked our biggest customers,
and they all said that this feature was essential. We are missing something here.”
“I agree, and it is one of the things I would like to work on during the next Sprint:
to make sure that we are really delivering value. When we focused all our effort on
this feature, we neglected a lot of other work that we thought was very important,
too. We need better insights into what real patients really value.”
A r e We D e live ring Va lue ?

Time to market isn’t everything; as we often say to our students and customers,
you can deliver the promised functionality on time and under budget and still fail.
Product Owners must be aware that delivering quickly is an important part of

optimizing product value, but there are other parts to it as well. What faster deliv-
ery really gives Product Owners is the ability to test their hypotheses about what
things customers really value. To do that, they need to be able to measure value.
124
9780134862156_web.indb 124 06/10/20 8:04 PM

Imagine that the Scrum Team in the preceding scenario hadn’t been able to
measure the usage index3 for the newly added piece of functionality: They
probably would have seen the quick implementation and delivery as a huge suc-
cess, and they would not have been aware that the feature wasn’t being used.
Scrum Teams need measures that will help them assess their expected success.
Optimally, those metrics will be collected and analyzed continuously and auto-
matically as part of the release itself; manual measurement and analysis
increases effort, delay, and the probability of error, and it’s among the first
things teams stop doing if they don’t see an immediate effect or if they become
busy. If they add it as an afterthought, after they have implemented all the
planned functionality, the chances are high that their good intentions will be
overtaken by more functionality, and ultimately, they won’t measure anything.
This kind of measuring and analysis is usually considered a part of systems

that monitor applications, providing telemetry.4 Application monitoring is
usually seen as a means of technically assessing the systems and infrastructure
in which an application runs to determine when something has gone wrong
that has to be fixed (e.g., CPU load, database timeouts). Adding usage- and
user-specific metrics to application telemetry provides valuable insights into
how customers are using the application.
Organizations can and should monitor if, when, and how functionality is being
used, by whom, and where. They should assess what types of products are being
bought, and when. These metrics, collected over time, make it possible not only
to analyze the past but also to forecast the future, helping to answer questions
such as these: What types of products do we need to keep in stock and in what
quantity? When should we expect the maximum (or minimum) load on a daily
(or weekly, monthly, yearly) basis? How does our business develop over time?
It is not easy to decide which metrics should ultimately be collected and how
they should be used. This is part of the iterative and incremental work that
Scrum Teams can and should do in short cycles. The next section talks about
this question and how to answer it.
3. Usage index: What part of our user base is actually using a piece of functionality, and how do they use it?
4. See https://en.wikipedia.org/wiki/Telemetry#Software.
125
M06_Gotz_C06_p121-p142.indd 125 06/10/20 8:54 PM

“Thank you very much for helping me to identify metrics that help us measure
business value,” the Product Owner starts the meeting. “I know this takes time
out of the work you have planned for this current Sprint, but I would appreciate
your input here. As you know, we delivered a feature with the last release that not
very many users have tried and that even fewer seem to like. How can we increase
our chances to deliver functionality that is valuable to our users?”
“I think it starts with the product vision. Could we go over that once more?” a
developer asks. “It might remind us all of what we are ultimately trying to achieve.”
“Great idea,” the Product Owner replies. She gives a brief summary of the product
vision, her current midterm goals, and the expected outcome.
“Okay, that sounds to me as if the most important goal we are currently working
on is to enable more self-service functionality for patients so that they can plan
appointments or hand in documents online. Is that right?” another developer asks.
“Yes, that is correct.”
“All right. We already know who of our users are staff in practices and who are pa-
tients. I think, therefore, we should monitor usage of functionality of the patient users.”
“Yes, we are already doing that,” the first developer says. “But we are only looking
at the data if someone asks us for it.”
“Okay, good thinking,” the Product Owner says, encouragingly. “I will collect our
ideas at the whiteboard so that we can select metrics that we want to focus on
afterwards. What else might be interesting?”
“Have we asked our customers what they would value?”
“Of course. Marketing does that all the time.”
“Well, I think they are asking our customers, that is, the ones who buy our product.
But in this case, isn’t our target audience the patients who are not buying the product
but whose satisfaction counts? How can we ask them about their opinion?”
The Product Owner is impressed. “To be honest, I have never thought about it.
But I think we should find out.”
Wh at I s Va lu e ?
When deciding what type of information to collect and use, Scrum Teams
should start from the product vision and the goals. The product vision
126
9780134862156_web.indb 126 06/10/20 8:04 PM

describes the purpose of a product; it describes what problems it tries to

solve, how it improves the future, and for whom. Intermediate goals make the
long-term product vision actionable and specific.
If your intermediate goal for the current year is to increase the number of
new users for your product, then the metrics you collect should tell you how
well you are achieving this goal. You will likely want to measure how many
new users buy and use your product. If your intermediate goal is to lower
operational cost for your product, then different metrics will help you. The
Product Owner in the preceding scenario knows what she is currently trying
to achieve. This makes it easier for her and the rest of her team to think about
and select metrics that help measure their achievement of objectives.
It is rarely straightforward to be able to directly measure what you are trying

to achieve, as in the case with customer satisfaction. To assess something that
you can’t directly measure, you have to measure something else that will let
you make inferences about the thing you really care about.
In the case of customer satisfaction, the easiest way is to ask your customers. If
possible, you could meet them where they use your product and ask them, but
this is not always possible, and it may only provide a small sample of the overall
users’ opinions. If your product is digital, it could be easy to ask your users
while they are using the product, as long as you don’t annoy them with too
many feedback forms. You may have to settle for measuring the duration of time
they use your product, even specific features, and infer their satisfaction from it.
Depending on what you are trying to measure, the type of product you offer, the
way your customers interact with it, and the way you are able to interact with
your customers, your goal is to find metrics that help you come to a conclusion.
You may have to evolve your measures in an iterative and incremental way by
creating a hypothesis of what you would like to measure and how to measure
it, then gather measurements and analyze the results. If the measures help you
to better understand the problem, you can refine the metric, and if not, you
will at least have data that will help you to think about different ways to mea-
sure what you need to know.
127
9780134862156_web.indb 127 06/10/20 8:04 PM

Improving business value entails more than considering product value; you
also have to measure and assess the means by which an organization is able to
deliver that value. Evidence-Based Management (EBM)5 is an empirical
approach that helps organizations to use those measures and base their con-
tinuous improvement on them. See the sidebar “Value Areas” for more infor-
mation about the different aspects of business value according to EBM.
Va l u e A re a s
Business value in an organization goes beyond the value a product brings. Organiza-
tions should measure, analyze, and improve in four value areas:
• Current Value (CV)
•
• Unrealized Value (UV)
•
• Ability to Innovate (A2I)
•
• Time to Market (T2M)
•
Current Value is the most obvious. It measures value delivered to customers or us-
ers today. This includes measures such as the already mentioned customer satisfac-
tion and usage index but can also include employee satisfaction, revenue per employee,
and product cost ratio. These metrics help assess the benefits that an organization
delivers to its customers or users.
Unrealized Value is the counterpart to current value. It measures value that could be re-
alized by meeting potential needs of the customer or user. Metrics include market share
and customer satisfaction gap, which measure how well we do in relation to our compe-
tition or our customer’s expectation. Unrealized Value metrics help us to understand
where we have opportunities to improve the value that we are delivering.
Ability to Innovate measures the effectiveness of a team or organization to deliver a
new capability that might better meet customer or user needs. It includes metrics
such as innovation rate to assess how much of our effort leads to innovation and more
technical measures, such as technical debt and defect trends. Improvements in this
area enable an organization to become better at innovation itself. Ability to Innovate
metrics often leads to insights on where waste can be removed in order to bring in-
novation to our customers instead of following meaningless and ineffective processes.
Time to Market measures the time it takes to deliver new capabilities, services, or prod-
ucts to customers and users. Metrics such as release frequency and cycle time help an
5. For more information, see https://scrum.org/ebm.
128
9780134862156_web.indb 128 06/10/20 8:04 PM

organization understand how long things take, which helps identify where the organi-
zation needs to improve workflow in order to deliver valuable outcomes more quickly.
These four value areas should not be considered individually, but together. Often, an
improvement (or decline) in one area leads to improvement (or decline) in other areas.
For example, improving time to market helps an organization to more rapidly try new
ideas that may improve current value, which may in turn reduce unrealized value.
Later that day, the Product Owner and Scrum Master are talking about the out-
come of the value discussion.
“I think that was really helpful,” the Product Owner says. “I have a much better
understanding about the different types of value that we, as a Scrum Team, and our
surrounding organization, are trying to deliver. But I don’t have a really good idea
on how to use these value areas and metrics to guide our continuous improve-
ment. What do you think?”
“Well, maybe I am thinking too simplistically, but I think it is not that hard. We
select those values that we would like to improve, and then we work on improving
them. Or am I missing something?”
“What I don’t know is how to decide what to focus on and how to plan and assess
improvements.”
“Okay, I see what you mean. But I think I know the answer to that: We should
work empirically and be hypothesis driven. Let’s think that through, why don’t we?”
Th e E x pe rim e nt Loop
Working in a complex environment requires iterative and incremental approaches
to finding a solution for a specific problem. Much is unknown at the start, and
the only way to make progress is to try ideas, measure the results, and adapt on
the basis of feedback. Every step toward the solution brings new insights and
learnings that help teams better understand the problem and the solution.
Sometimes large goals are too ambitious and abstract to make measurable
progress toward in the short run; specific and measurable intermediate targets
are more useful in assessing overall progress.
129
9780134862156_web.indb 129 06/10/20 8:04 PM

Organizations can use a closed-loop system to work from intermediate target

to intermediate target, all the while adjusting the course if necessary. This
experiment loop has four phases (see Figure 6.1):
1. Hypothesis: Idea to execute in progression toward the intermediate goal

2. Experiment and Measure: Execute the idea and measure leading and
lagging indicators
3. Inspect: Learn from the last experiment based on the measures
4. Adapt: What could be done next? Is it necessary to adjust the overall goal?
Hypothesis Experiment &

One idea for how to Measure
Challenge Metric
make progress toward Try out the idea. Strategic Goal

Intermediate Goal Measure lag and lead
results.
The
Experiment
Loop
Adapt
What might you try
next? Do we need to Inspect
adjust the Based on the measures,
Strategic Goal? what did you learn?
Intermediate Goal
Current State
Starting State
Time
Figure 6.1 The experiment loop6
6. Adapted from Toyota Kata by Mike Rother, McGraw-Hill Education, 2009.
130
9780134862156_web.indb 130 06/10/20 8:04 PM

Let’s recapitulate the journey of the Scrum Team through the last four sec-
tions. The Scrum Team tried to achieve the intermediate target of making the
patients more independent of the practice staff. The idea behind this could be
to relieve staff from work or to offer more flexibility for patients, maybe even
both. The team’s first hypothesis was that patients were willing to schedule
their appointment with a self-service solution even though the team had not
had specific requests for this feature. The feature was developed and delivered
to market, and usage rate was measured as a lagging indicator. During inspec-
tion, the team learned that not many patients are using this functionality and
even fewer use it more than once. This tells the Scrum Team that its hypothe-
sis was incorrect and needs to be adapted. The next step would be to find a
different way to make patients more independent of the practice staff or per-
haps find a way to test whether this intermediate target is the right target.
The experiment loop has strong relations to the value areas Ability to
Innovate and Time to Market. Organizations and teams need to innovate
quickly and with high frequency to be able to run small experiments that may
improve Current Value and reduce Unrealized Value. In the example presented
in this chapter so far, getting faster feedback that its improvement hypothesis
was flawed would have been beneficial for the team because it would have led
to work on a different hypothesis sooner, reducing the wasted effort of work-
ing on a solution that didn’t add (enough) value to the customers and users.
The experiment loop helps agile organizations and teams to continuously

improve their performance toward goals that go beyond a single Sprint. Using
the value areas and specific metrics to guide decisions and learning helps
improve overall agility and performance. It also offers tools and means to cre-
ate transparency and alignment inside an organization.
The Scrum Team in our case study might start its journey toward its Strategic
Goal by measuring its Time to Market and identifying bottlenecks that they
can remove. As it improves Time to Market, the team can run more experi-
ments that may result in increased Current Value. The team may also find that
it is working on too many things at once and needs to improve its focus (a mea-
sure of its Ability to Innovate). As it improves the Current Value that customers
experience, the team may also reduce its Unrealized Value, assuming nothing
else has changed, such as customer expectations or competitor offerings.
131
9780134862156_web.indb 131 06/10/20 8:04 PM

As you can see, this is a never-ending journey where insights and learnings
from the past guide future improvement. Increasing its ability to measure,
analyze, and act on the collected results helps a team to improve ever faster.
I m proving Te am R e sult s
The Scrum Master and Product Owner are having their weekly check-in where
they usually discuss topics of current interest in order to stay aligned with each
other. Today they are looking back at six months of using Scrum in their product
development.
“All in all, I am quite pleased,” the Product Owner says. “We all seem to have
found a nice rhythm in our Sprints, and I like being able to regularly inspect results
with the team. What do you think?”
“I fully agree. After the first few Sprints, the Development Team has reliably deliv-
ered product Increments every Sprint.”
“Exactly. There is just one thing that is bothering me.”
“What is it?”
“The team’s velocity doesn’t change. I have read a bit about agile estimating and
velocity, and many authors explain that with improved technical ability, teams will
increase their velocity and become faster. Why isn’t this true for our team?”
Ve locit y I s N ot Pe r for m a nc e
Many people equate effort with performance; they assume that the more hours
someone works, the higher their performance. The problem with thinking this
way is that effort has nothing to do with the value of our work. It is possible
to spend a lot of time and effort on something that does not create value.
Conversely, it is sometimes also possible to increase value with very little effort.
What organizations should focus on is creating and increasing value, not

merely doing more. The problem is that measuring value is usually more diffi-
cult than measuring effort, so many organizations fall back to what they can
easily measure.
132
9780134862156_web.indb 132 06/10/20 8:04 PM

Improving Team Results
Velocity is a bit like effort in this respect: It can easily be measured and
assessed, but it is not a measure of performance; instead it is a measure of
how much work a Development Team was able to deliver in a specific Sprint.
There is also no universal scale for velocity; it varies between both different
teams and different Sprints of the same team, as it is based on rough esti-
mates that the Development Team makes to size the work to know how much
work it can finish in one Sprint. These rough estimates are usually never
updated with the amount of effort that the item actually took, since they are
only used in planning. In addition, teams face different distractions and dis-
turbances during each Sprint, which makes it impossible to exactly forecast
what and how much a team will be able to deliver.
Velocity as an empirical measurement from past Sprints is a metric that can

help a Development Team to forecast future Sprints. Used as such, it is an
indicator, not a performance metric. It can be used to answer a question like
the following: How much work will we likely be able to deliver in our next
Sprint(s), provided we have roughly the same overall conditions, such as
capacity and disruptions?
If an organization would like to measure performance, it should look at the

value areas and metrics from the previous sections. By taking velocity as a
metric of performance, it is very easy to corrupt the metric, as you will see in
the next section.
“How can we make sure that the team will really work on improving the value it
delivers?” the Product Owner asks. She and the Scrum Master are still discussing
team performance. The Scrum Master has explained why velocity is a bad metric
for measuring performance, and they are now discussing ways to measure and
improve performance of the Scrum Team.
“The first thing we need to do is measure real performance, not effort,” the Scrum
Master says. “What about measuring something like customer satisfaction and
defect rate? They should be pretty good indicators of value that we as a Scrum
Team create.”
133
9780134862156_web.indb 133 06/10/20 8:04 PM

“What is defect rate?”

“Originally, it was a ratio of detected defects per lines of code delivered, and that
measure is sometimes still used. Personally, though, I think it is too complicated for
our purpose and suggest we take the ratio of defects per feature that the team de-
livers. Let’s say we deliver ten features and receive one bug report that describes a
defect in our software—that would be a defect rate of ten percent.”
“All right, got it. Good idea. Let’s start to measure the defect rate. I will think
about how to measure customer satisfaction as well. Now I would like to come
back to my earlier question: How can we make sure the Development Team will
focus on improving those metrics? I think we should speak to the team’s managers
and add targets into its annual appraisals. What do you think?”
H ow to (N ot) I nc e ntivize Pe r for m a nc e

Do you receive a performance-related salary? If yes, then how is your perfor-
mance measured? In most of the companies we have worked for, performance
was loosely defined as some arbitrary goals that we agreed upon with our respec-
tive managers and tried to reach by the end of the year. Since in most cases the
daily business very quickly became more important than the agreed-upon goals,
we only remembered the agreed-upon goals as the end of the year approached.
We then tried to reach the metrics in order to receive our bonus payments.
In our experience, this helps neither the employee nor the company; goals
should be meaningful for both the contributor and the organization.
Therefore, the Scrum Master and Product Owner in the preceding scenario
are trying to do the right thing: They are looking for goals that are relevant to
what they as a team are trying to achieve. Those goals have a higher chance
of remaining relevant and not being pushed aside by daily business, since the
goals are aligned with work people do every day.
The problem with such goals is that they don’t incentivize employees individ-
ually to meet specific goals. Scrum Teams achieve goals when they work
together as a team to improve their product and the system that produces that
product. Individual goals can be counterproductive when they incent people
to work separately toward individual goals rather than collaborate as a team
toward shared goals. In the worst case, a team member might actively damage
teamwork in order to achieve his or her individual goal.
134
9780134862156_web.indb 134 06/10/20 8:04 PM

To address this problem, some companies we have worked with have shifted
from individual goals to team goals and from individual incentives to team
incentives. If an organization’s goal is to improve teamwork, it is only logical
to incentivize team work.
Incentives can take many forms. For example, a Scrum Team could negotiate
a team bonus for specific team goals. If the team reaches the agreed-upon
goals, it receives a team bonus, and the team members can decide for them-
selves what to do with it. Some teams we have worked with split the bonus
money equally, as they felt that everybody did their part and was necessary
for the outcome. Other teams created ratios of distribution that they thought
were fair for their individual contributions. Others didn’t split the money
among team members but used it to pay for a team event.
One more question regarding performance bonuses: Did your bonus increase
your performance? We believe that the idea that an individual has to be
rewarded for good behavior (and punished for bad behavior) is a dangerous
fallacy. We believe that humans are curious and motivated when they are able
to work on something that is meaningful to them and when they have auton-
omy over their work.7 We don’t think incentivizing performance helps; it can
even impede real improvement due to misaligned incentives.
I nfo r m a t io n Va l u e N eu t r a l i t y
Once an indicator or other surrogate measure of performance is made a
target or incentive for the purpose of driving behavior, it loses the infor-
mation content that qualifies it to play such a role.
— Robert D. Austin, Measuring and Managing
Performance in Organizations
Organizations have to be careful how they use metrics to guide their self-
improvement efforts, as they can be easily misused. Metrics are an indicator of
status at a specific point in time, just like the speedometer in your car tells you how
fast you are currently going.
7. Compare Chapter 2, section “Missing Self-organization.”
135
9780134862156_web.indb 135 06/10/20 8:04 PM

As soon as you start rewarding the achievement of certain metrics, they will lose
their informational value. People will start changing their behavior in order to reach
the requested targets and will lose focus on the real improvement. As a concrete
example, if an organization asks its Scrum Teams to “improve” their velocity, those
teams will have this target in mind when they estimate Product Backlog items.
Over time, they tend to unconsciously become more cautious with their estimates,
playing it safe and accepting higher estimate values when in doubt. This tends to
lead to inflation of estimates, so Product Backlog items that would have been esti-
mated at 2 or 3 in the past suddenly are estimated at 3, 5, or even 8 story points.
We have seen this effect in situations where teams were incentivized on improving
their velocity. We have seen similar problems with other incentives to improve
measures such as customer satisfaction and defect rate; as soon as individuals or
teams are rewarded for reaching a specific goal, the people involved will focus more
on reaching the target than improving the underlying system.
As a result, the original metric on which the goal is based becomes more or less
useless. A Scrum Team that has an inflation of velocity going on will look good in
velocity reports, but it will have difficulty forecasting its Sprints. Even worse, the
Product Owner can’t use the team’s velocity to project release dates and scope
into the future. An organization that loses the information value neutrality has to
work very hard to re-create the usefulness of those metrics. Often, it is easier to
abandon those metrics altogether and use different ones.
Since the practice of incentivizing the work of individuals and teams is questionable,
as it often doesn’t lead to the anticipated and desired systemic improvement, orga-
nizations should question whether they need a reward system at all. We have not
yet found a metric that can be used as a source for performance appraisals that can’t
be misused and corrupted. As a result, we recommend getting rid of those incentive
systems and instead creating an environment where people want to excel.
A few Sprints later, during the Sprint Retrospective, the team discusses next steps
to improve its current way of working.
“To be honest, I was shocked that we have such a high defect rate,” one of the
developers says. “I was aware that after a release we receive a higher number of
bug reports from our users. But I didn’t think that it was so high; our users found
136
9780134862156_web.indb 136 06/10/20 8:04 PM

bugs in almost half of the features we delivered during the last Sprints. I think this
is the most important thing to work on from the next Sprint on, going forward.”
“Yes, I agree,” the Product Owner answers. “My measures on customer satisfac-
tion show that this unreliability significantly reduces our customers’ satisfaction
with our product.”
“I think we should invest more of our development capacity in automating tests,
especially end-to-end testing of features in the integrated system,” another devel-
oper suggests.
The first developer disagrees. “But this would take quite some time. Our management
thinks we are too slow as it is. I don’t think we should diminish our velocity further.”
The Scrum Master intercedes to help focus the discussion. “Do we know how much
time we spend on manual testing and fixing defects, and how much time it would
cost to automate more tests instead? Maybe those efforts are similar, and spending
time spent on test automation is a better use of our capacity. What do you think?”
The majority of the team agrees that this is worth a try. They agree to start mea-
suring the times it takes them to work on different types of task, such as developing
functionality, testing it manually, fixing defects, and automating acceptance tests.
The team wants to try this for a couple of Sprints and then decide how to proceed.
You Can’t I m prove Wh at You Ca n’t M e a su r e

Many Scrum Teams we teach or work with have a good understanding of
which areas of their work, tools, or processes they would like to improve.
They often see specific deficits that are worthwhile to remove, just like the
team in the preceding scenario. Their struggle starts when we ask how they
would know when an improvement actually occurred and how they can con-
nect the improvement with the actions they took.
Intuitions about improvements are a great starting point, but they are not enough
to guide sustained improvement. Each improvement idea is really a hypothesis
that needs to be experimentally validated or rejected. Doing so requires teams to
collect data in the area they want to improve both before and after the improve-
ment experiment. That comparison provides them with insights that inform their
continuous development, including their collaboration, tools, and processes.
137
9780134862156_web.indb 137 06/10/20 8:04 PM

Coming up with metrics that they can use to evaluate their improvement
experiments is challenging for most teams. It is easiest for them to start with
metrics that they can collect from data they already generate. When there is
no existing set of data they can use, they need to agree, as a team, on what
they want to achieve and why the data they want to collect will help them
achieve their goals. Only when everyone involved understands the reason
behind the data collection will they be motivated to gather it.
It is best to collect and analyze data automatically, based on work that is

already being done, so as not to create additional work. Doing so not only
reduces errors but also increases the chances of the data being collected and
used in the first place. Look at the various tools that you, your team, and
your organization are currently using in your work to see if you can collect
the data you need from those tools; you might find a hidden treasure.
Examples of these kinds of tools include the following:
• Issue tracking and work management tools (e.g., Jira or Azure DevOps)
•
• Code quality tools (e.g., SonarQube)
•
• Automated test results (e.g., unit or acceptance tests)
•
• Monitoring and product telemetry data
•
When data collection and analysis can’t be completely automated, be mindful
of the extra effort you are creating. Making it as effortless as possible helps to
make data collection and analysis sustainable.
The team has installed some dashboards at central points in its office to cre-
ate transparency about some of the metrics it cares about. Now people walking
through the building can see current build results, number of defects, number of
new defects, and usage and performance metrics. The team also plans to find more
valuable information and add it to the dashboards.
Today, the team members end an important Sprint, the result of which they want
to deliver into production tomorrow, so many of their stakeholders are present in
the Sprint Review, following the presentation and participating in the discussions.
138
9780134862156_web.indb 138 06/10/20 8:04 PM

“Do you have any questions about this feature or feedback that you would like to
share?” the Product Owner asks.
“I have a question regarding the delivery into production,” the CEO starts. “On
my way here, I passed a dashboard that showed the current defect rate at thirty
percent. As far as I remember from what you told me, this means that every third
feature we deliver to our customers has a defect. I am very worried about this
and would like to make sure we deliver high-quality products into production, not
products that are half-baked.”
“That is an important point,” the Product Owner replies. “You are right that cur-
rently we find defects in roughly thirty percent of the features we deliver to our
customers. I also agree that this rate is too high. We have been working on this
problem with high priority for the last few Sprints and will continue to do so. But
I also have to add that those defects are usually minor things that our customers
would like to have improved. Therefore, I would like to release into production
tomorrow. For us, it is the best way to learn from this feedback.”
Another developer chimes in. “I would like to add that the current thirty percent
defect rate is already an enormous improvement from the fifty percent that we
had three Sprints ago. This doesn’t mean we can stop improving, but we should be
encouraged by the improvement we have already achieved.”
M onitor I m prov e m e nt, N ot M e a su r e s

Imagine two Scrum Teams delivering a product to their customers. They both
regularly ask their customers how satisfied they are with the product and if
they would recommend it to their friends. The first team finds that 78 percent
of its customers are satisfied enough that they would recommend the product
to their friends. For the other team, 85 percent of the customers would recom-
mend the product to their friends. Which team is able to deliver better results?
For all of you who answered “the second team,” please take a moment and
think about what you don’t know from this context. The first question we
would ask in this situation is, What were the numbers on customer satisfac-
tion and recommendation last time and the times before? We are convinced
that a single measurement is just that: a measurement. To assess improvement,
we need to continuously measure and analyze the changes over time. What if
three months ago, the first team had 65 percent customer satisfaction, but the
second team had 89 percent? This would completely change the picture.
139
9780134862156_web.indb 139 06/10/20 8:04 PM

Shifting focus from single measurements to improvements enables you to reap

some important benefits. First, by breaking your path toward your goal into a
series of smaller steps, you can make measurable progress toward even far-off
and seemingly impossible goals. In the previous example, the goal is to increase
customer satisfaction and, potentially, the Net Promoter Score (NPS).8 A goal
such as “we want to achieve 90 percent customer satisfaction and an NPS of
9 in the next year” might be very challenging to achieve in a single step, which
may deter you from trying to improve. If you shift your focus to improvement,
starting with a customer satisfaction rate of 80 percent and an NPS of 7.5 and
achieving an increase to 85 percent and 8.5 in one year would be a huge win,
even though you have not yet achieved your ultimate goal.
This brings us to another benefit. The goal of achieving 90 percent customer

satisfaction and an NPS of 9 in the next year focuses on arbitrary numbers.
Teams and organizations might focus so much on the numbers that they try
only to achieve the numbers without really increasing customer satisfaction
(see the sidebar “Information Value Neutrality”). Teams might be tempted to
game the system if improvement does not develop as expected. For example,
they might promise small gifts to customers who give favorable answers in the
customer satisfaction surveys. Focusing on continuous improvement shifts
focus away from arbitrary goals and toward immediate improvements.
Examining improvement trends in measures also helps teams to identify new

opportunities for improvement by identifying the types of changes that have
the greatest impact and suggesting new improvement experiments that may
produce better results.
Finally, every improvement comes at a price. Initial improvements might cost

very little for big increases in performance, but subsequent improvements
often become progressively more expensive and complex. At some point in
time, you may find it better to focus on improving in a different value area or
even seek different goals to get a better return on your investment of time and
money. Monitoring improvement trends comparing different improvement
opportunities enables you to get the best results for your effort invested.
8. https://en.wikipedia.org/wiki/Net_Promoter
140
9780134862156_web.indb 140 06/10/20 8:04 PM

Summary
S u m m ary
Scrum provides teams with the opportunity to regularly inspect and adapt not
only the product they are building but also the means by which they build
and deliver that product. To seize this opportunity, teams must form goals,
devise improvement experiments, measure their results, and use the resulting
measures and trends to guide their improvements.
Deciding what to measure and how is a very important choice that Scrum
Teams need to make for themselves. Their decisions depend on their specific
context, their experience, and their goals. We chose the metrics and measure-
ments discussed in this chapter to illustrate our points; you will need to make
your own choices based on your own situation. Metrics and measurements
can help you find your way toward your goals, much like ship navigators use
maps, weather forecasts, route plans, and shipping traffic forecasts to safely
sail to their destination, adjusting their course, speed, and direction on the
basis of constantly arriving new information.
141
9780134862156_web.indb 141 06/10/20 8:04 PM

S crum and
Management 7
The Scrum Guide does not say anything about the role of management or
managers; it defines three roles: Scrum Master, Product Owner, and
Development Team. It also mentions stakeholders. Management is described
as something that people do, such as product management and Product
Backlog management. Manager as a role is undefined—in fact, it is not men-
tioned at all, which often causes confusion between Scrum Teams and manag-
ers. The easy (but wrong) conclusion is that Scrum does not need managers.
In this chapter we consider the important role that managers play in support-
ing Scrum Teams and helping them to grow. We look closely at the differences
between management, leadership, and servant leadership. We also look at how
managers’ incentives to exercise control over “their” organizations create con-
flicts of interest that can derail Scrum. At the end of this chapter, we also
look at the responsibility of management and discuss how management can
support an agile transformation and Scrum.
143
9780134862156_web.indb 143 06/10/20 8:04 PM

Chapter 7 Scrum and Management
The Role of M anag e me nt in S c ru m

The department head enters the team room. “Good morning. I wanted to check
on how things are going here.”
“We are doing all right, thanks,” one developer answers. “Some tests last night
failed, but we are already working on it.”
“But shouldn’t your burndown chart show more progress?”
“True, we are currently behind on our initial plan. We discussed this lag in our
Daily Scrum on Monday, and we have an idea on how to fix it.”
“I am not really convinced,” their boss says. “Do me a favor and keep me updated
on the progress. I think it is best if you check in with me daily after your Daily
Scrum. It is very important to continue to make progress according to plan.”
Tr a n s pa r e nc y I s N ot S u rv e ill a nc e
One of the main sources of misunderstandings between management and Scrum
Teams comes from a different understanding of transparency. Scrum Teams work
toward a Sprint Goal, which gives them the freedom to decide which tasks to
focus on while they learn about their current work. Traditional managers typically
focus on plans and tasks, and they measure the degree of completion and the time
and resources that remain. Standardized status reports compiled in regular inter-
vals help managers monitor this data. Traditional managers with a command-
and-control mindset often ask Scrum Teams to prepare these types of reports.
Scrum follows an empirical approach in which the Product Owner defines the
most valuable features to work on during the upcoming Sprints. During
Sprint Planning, the Scrum Team decides what goal it wants to achieve during
the Sprint and which Product Backlog items best support that goal. Sprint
Planning is a transparent and open event, and the Sprint Goal and Sprint
Backlog create the transparency needed for the Scrum Team and the sur-
rounding organization around what is currently being worked on.
We usually ask managers to join the initial Scrum training that their staff
receives. This helps them understand that Scrum creates transparency with its
144
9780134862156_web.indb 144 06/10/20 8:04 PM

The Role of Management in Scrum
artifacts and that the Scrum events provide opportunities to inspect and adapt
plans regularly. Transparency and regular feedback help management to align
the current situation with its plans on a higher level. They also help managers
recognize where teams face difficulties that have to be resolved, which we
think is the main job of management.
Transparency inverts the normal relationship between managers and teams:

top-down command and control is replaced by bottom-up feedback.
Managers “go and see”1 what is really happening in and with their teams.
The feedback they receive is not polished in a report—it shows the facts and
gives insights into the actual struggles a team faces, enabling deeper under-
standing and empathy throughout the organizational hierarchy and creating a
sense of “we” instead of “us and them.”
When an organization embraces transparency, it finds ways to support the

Scrum Team’s efforts to achieve its goals. Transparency removes the need for
status reports, which rarely present the full picture, by providing the means
for managers to find out whatever they want, whenever they want it. The time
that teams would have spent compiling reports is freed to add value to the
product. Scrum Masters and Product Owners should collaborate with man-
agement to understand what information their Scrum Teams need to make
transparent so that everyone can best do his or her job.
The chief security officer (CSO) meets one of the developers of the Scrum team
in the coffee kitchen.
“Tomorrow we have a presentation with this stakeholder I mentioned yesterday,”
the CSO starts.
“Yes, I remember that you asked me to implement a feature for you,” the devel-
oper replies.
“And is it done?” the CSO asks.
1. Genchi Genbutsu, a Japanese phrase that means “real location, real thing,” is an important principle of
the Toyota Production System. It is often referred to as “go and see.” https://en.wikipedia.org/wiki/
Genchi_Genbutsu
145
9780134862156_web.indb 145 06/10/20 8:04 PM

R e s pon sibilit y I s N ot Control

We often see these kinds of demands in our work with Scrum Teams:
Someone needs a feature for some reason, and this person wants it now and
doesn’t want to have to follow accepted protocols such as going through the
Product Owner. The usual result is a fair amount of poorly designed and
untested solutions that add to technical debt. But where does this behavior
come from?
Traditionally, managers are responsible for identifying what needs to be done,

deciding who does it, assigning the work, and then ensuring that the work has
been completed according to the given instructions. Employees are responsible
for following these instructions and producing high-quality work. The
employee trusts that the manager best knows how the work should be done.
This management style works well with simple tasks such as recording a
financial transaction in an accounting system, where there is a well-defined
procedure that must be followed for the work to be completed correctly. It
fails in complex or dynamic environments where teams are doing novel work
or solving novel problems, such as in software development or research,
because the teams constantly encounter new challenges that they need to
solve; it would be impossible for a manager (or anyone else) to understand
what needs to be done and how to do it.
The work of teams who work in a complex environment is highly intercon-

nected, putting great demands on team members’ ability to collaborate and
make decisions quickly based on what they are continuously learning. A tra-
ditional manager, disconnected from the team, lacks the insights of this learn-
ing and becomes a bottleneck who limits the productivity and performance of
the team.
In addition, knowledge workers can lose their motivation when they are asked
to simply follow orders, especially when those orders are inaccurate. They
know the work is complex and become frustrated when their experience and
expertise are ignored.
146
9780134862156_web.indb 146 06/10/20 8:04 PM

The Role of Management in Scrum
Studies have shown that people who strongly influence their fate have better
stress coping skills, feel greater satisfaction in their work, and are more goal-
oriented than people who have less control.2 For a Scrum Team, this means that
the team members decide how much work they plan to do in a Sprint, how they
do the work, and when the work is done. As a result, a Scrum Team is often
more committed, motivated, and focused than a traditionally managed team.
Scrum Teams and traditional managers can find themselves in conflict for a
variety of reasons:
• Managers want to have control about what will be done and when.
•
• Managers have a tough schedule and need information by a defined time.
•
• Managers want to have information as detailed and exact as possible.
•
• Managers have specific expectations regarding what reports should look
•
like and which metrics they need.
For an organization to achieve the benefits of agility, managers have to find a bal-
ance between asserting control and letting their Scrum Teams self-manage. To
do this, they need a basic understanding of Scrum and the agile way of working.
H ow C a n M a n age r s Le a r n a b ou t Ag il i t y a n d
S c r u m?
The Agile Leader Learning Path3 is a good starting point for understanding Scrum
from the leadership perspective. It presents topics that a manager should under-
stand to feel confident in Scrum:
1. Reading the Agile Manifesto and its principles helps the manager to under-
stand the fundamentals of the agile way of working.
2. Mastering the concepts of empiricism helps the manager understand how
Scrum is able to more effectively deliver results under conditions of uncer-
tainty than is a traditional plan-based approach.
2. For more information, see https://en.wikipedia.org/wiki/Self-determination_theory and

https://en.wikipedia.org/wiki/Locus_of_control.
3. https://www.scrum.org/pathway/agile-leader-learning-path
147
9780134862156_web.indb 147 06/10/20 8:04 PM

3. Embracing Scrum values helps the manager understand how Scrum teams
work and collaborate together.
4. Learning about Scrum roles helps the manager to understand who is respon-
sible or accountable for what, which helps them avoid misunderstandings.
5. Learning about how teams can use self-organization to get work done helps
the manager to understand what he or she can do to help teams perform
better.
As managers progress along this path, they learn that transparency is a more effec-
tive means than top-down control for ensuring responsibility. By empowering and
supporting their teams, they activate and engage the entire team to deliver better
results. A self-organized team is like a fulcrum that multiplies the force that an
organization can apply to solving problems and delivering value. In a traditional or-
ganization, managers have to supply much of the energy needed to focus teams on
reaching goals; when teams are self-organized and seeking goals, managers achieve
more by helping them overcome obstacles.
H ow to E nable S e lf - organiz ation

It’s the Scrum Team’s fifth Sprint, and the team is increasingly self-organizing, but
there are some things it would like to improve that are outside its control.
In the last two Sprint Retrospectives, the team members identified automating the
build, test, and deployment process as something that they really want to do to im-
prove their ability to deliver value. Unfortunately, they’ve run into organizational
roadblocks. The Scrum Master goes to the team’s manager for help.
“Can I bother you for a moment? We’ve been trying to get our delivery pipeline
automated so that we can deliver more effectively, but we’re being blocked by
other teams.”
“How so?”
“The Process and Tools team is in the middle of product evaluation and negotiat-
ing with vendors for a companywide license of pipeline automation tools. And Ops
won’t give us control of creating test environments; we have to fill out a ticket
148
9780134862156_web.indb 148 06/10/20 8:04 PM

How to Enable Self-organization
before they will provision what we need. We need control of our own tools and
test environments now! It’s hard for us to make progress when we’re always wait-
ing on other teams to do things for us.”
“I thought you were self-managing now,” the manager said. “This is your problem—
you need to talk to those other teams and work something out with them. You
can’t just expect to come running to me anytime you run into a problem. You’ll
have to make do as best you can.”
L e a ding I s N ot D ir ecting
Leadership, in contrast to managership, is about guiding other people, teams,
or organizations in situations in which the leader has influence but not direct
control. Where managers attempt to control, leaders try to influence by set-
ting clear goals and then helping to remove the barriers to achieve those goals.
Scrum needs more leadership and less management.
Servant leadership takes the leader’s role further by shifting the leader’s focus
from guiding people to achieve some result, to setting clear goals and then
helping people to develop and perform their best to achieve those goals. The
role of the leader is inverted from being served by people to acting in service
of people. Servant leadership helps organizations to improve their ability to
achieve their goals by increasing the engagement, commitment, and motiva-
tion of employees to deliver valuable business results. Some of the top-ranked
companies practice this leadership style, and studies4 have shown that they are
ranked high because of their leadership style.
Leaders also focus on the “guardrails” of their business and on the needs and
limitations of the other teams. When they define clear rules for what teams
may decide by themselves and what needs to be synchronized and agreed
upon with other teams, they create a safe space where self-organization can
grow. To be self-organized does not mean that you do not have to follow any
rules. But existing rules should give you enough space to make decisions on
your own and with your team.
4. For more information, see Sen Sendjaya and James C. Sarros, “Servant Leadership: Its Origin,
Development, and Application in Organizations,” Journal of Leadership & Organizational Studies
9(2): 57–64, 2009.
149
9780134862156_web.indb 149 06/10/20 8:04 PM

Sometimes teams need help, and in fairly direct ways. In the preceding scenario,
the team is self-organizing but only within the scope of its own work. Its ability
to improve is limited by the responsibility structure of the organization: the team
needs things from other teams, and those teams are not being responsive. A ser-
vant leader, in this situation, will have to reach out to those other parts of the
organization to try to remove the impediment and will have to use the full range
of his or her organizational skills to negotiate a better result—negotiating, trad-
ing political favors, and perhaps even calling in political favors to get things done.
S e lf - orga niz ation I s N ot A bs e nc e of M a n ag e m e nt

In the previous example, the manager illustrates another common misconcep-
tion: that management has no role when a team self-organizes. Self-organizing
teams need managers to make decisions and take actions, just not on the things
that are within the purview of the team. This means that managers need to help
teams negotiate with other parts of the organization, they need to fight for
attention and resources for the team, and they need to make decisions to move
ahead when different parts of the organization are stuck in old ways of working.
In this example, the Scrum Master comes to the manager for help because the
team can’t take action on its own; it is blocked from doing so by other parts of
the organization that own the decisions for a particular set of issues, in this case,
decisions about automated build, test, environment provisioning, and deployment
tools. Other common areas for conflict include team staffing issues, vendor man-
agement, contracting, legal, and security issues. Conflicts can also arise because
of application or component ownership, technology, or architectural issues.
Whatever the cause of the conflict, teams can’t always resolve the issues on
their own. They may lack the organizational knowledge or the political skills
or capital to negotiate an agreement. It’s not always about rank and author-
ity; managers are placed in their roles because they are skilled and experi-
enced at working across organizational boundaries to achieve mutual benefit.
The problems that they are skilled in solving don’t disappear because their
teams now self-organize. In fact, in many cases, the greater transparency that
self-organization exposes creates even more situations that demand skilled
negotiators to resolve. Managers are uniquely qualified to help teams over-
come these problems.
150
9780134862156_web.indb 150 06/10/20 8:04 PM

How to Enable Self-organization
Tr a n s i t io ning f r o m M a n age r to S e r va n t Le a d e r
In many organizations, a manager’s control authority is legitimized by granting the
manager a specific position, which in turn confers status; loss of legitimation and
control therefore results in a loss of status. An organization that embraces servant
leadership and self-managing teams needs to find other ways to legitimize leadership
and create an environment where managers can be servant leaders without losing
their status or position. This starts by the way an employee develops into a manager,
and it ends at the bonus system that forces managers to think in raw numbers.
An organization needs to find a way to handle challenges such as these:
• Providing people with a career path and growth opportunities
•
• Defining and managing career levels
•
• Establishing job goals
•
• Defining and managing compensation
•
• Defining reporting relationships
•
In order to transition to a servant-leader model, traditional managers need to let go of
their old practices and learn a new approach to guiding the organization toward goals.
A traditional manager believes that people are aimless and nothing will get done unless
someone tells them what to do. A servant leader believes that people want to do a
good job and that people closest to the work are best suited to decide how to do it.
S e lf - orga nizing I s N ot E a s y
It takes more than just saying a team is self-organizing for it to become truly
effective at directing its own work, and even then, a self-organizing team
needs guidance and support from time to time. It needs help to grow and to
overcome obstacles, and managers are uniquely positioned to provide this
help when they take on the role of a servant leader. Teams who are new to
self-organization do not yet know what self-organization really means or how
to do it. They need someone to be their partner on their learning journey, and
that person is their manager.
The challenge for managers is to gradually let go of responsibility at the right

time, when the team is ready to take it on. If they push a team to take on too
151
9780134862156_web.indb 151 06/10/20 8:04 PM

much responsibility too fast, the team feels abandoned and confused, but if they
hold on to responsibility too long, the team will feel frustrated and thwarted.
Letting go is a challenge for managers, too. When they let go, they can feel
that they are losing power and status. What they gain, if they do it right, is
greater influence. An effective servant leader is a catalyst that helps the orga-
nization deliver value by removing impediments that prevent teams from per-
forming to their full potential. Their contribution is subtle but essential in
achieving positive results.
Helping teams grow and take on more responsibility frees the leader to do
something new: help to optimize the organization for change. When teams
are able to direct their own work, leaders are freed from the day-to-day run-
ning of the company to look further forward, seeking new goals and helping
to develop the organization’s ability to meet new challenges. We further
explore this aspect of leadership in Chapter 8, “The Agile Organization.”
S u m m ary
Although management is not a Scrum role, it plays an important role in suc-
cessfully implementing Scrum inside an organization. Management and
Scrum need each other; by mutually supporting each other, they achieve more
than either could individually. But this new way of working is unfamiliar and
challenging for both because they lack models to guide how they need to
work together. In addition to mastering empiricism in delivering valuable
products, teams and their managers need to determine how they will work
together to achieve positive results.
Many conflicts between management and Scrum Teams originate from man-
agers’ discomfort in letting go of responsibility, fearing loss of position and
status. But in letting go of oversight of the day-to-day work and letting teams
take this on, managers become true leaders who free themselves from minu-
tiae to create opportunities to make greater strategic contributions. In doing
so, they shift from supervising to guiding and growing the organization to
improve its competitiveness.
152
9780134862156_web.indb 152 06/10/20 8:04 PM

The Agile
O rganiz ation 8
Just as the Scrum Guide does not say anything about the role of management
or managers, it also does not say anything about the structure of the organi-
zation that is necessary to support Scrum. In truth, many different kinds of
organizational structures can be adapted to work, so long as they are aligned
to delivering value to customers and removing anything that gets in the way.
In this chapter, we consider the importance of factors such as organizational

structure, processes, and culture in helping the Scrum Team to deliver value to
customers, and the role that managers play in clearing obstacles that the orga-
nization imposes on teams. We also explore how the concept of transparency
can replace traditional governance processes, but also challenge organizations
that are accustomed to controlling access to information as a way to maintain
managerial control.
153
9780134862156_web.indb 153 06/10/20 8:04 PM

Chapter 8 The Agile Organization
O rga niz ational Structu r e s Can E ithe r

H e lp or H inde r S c rum
One of the developers comes back from his yearly appraisal interview.
“That was ridiculous. My department head would like to know what exactly I am
planning to work on in the upcoming year so that he can create targets that I will
receive my bonus for. How can that work when we often don’t know what we will
work on three months from now?” The developer is very frustrated.
A colleague tries to calm him. “I had the same thing last week. I don’t think every-
body understands how deep the change with Scrum needs to go.”
N e w Wor k , O ld E n vironme nt
Yes, this still happens. Many companies fail to understand how their employees’
work will really change; they think that Scrum means changing role names and
adding those five meetings to the team’s agenda. This is not enough.
Gaining the benefits of Scrum requires change in the way the rest of the organi-
zation, beyond the Scrum Team, works. Scrum will not give the full benefits until
the organization changes. Let’s consider a few examples of areas where the orga-
nization must also become more agile in order to reap the benefits of Scrum.
The preceding scenario illustrates one area: leadership. Managers need to lead
their employees differently. Meeting once a year for an appraisal interview,
agreeing on one or two goals that an employee will work on to get a bonus,
won’t motivate the employee or help improve his or her skills or work; actu-
ally, as the developer’s reaction illustrates, applying traditional management
approaches can actually be demotivating.
Motivation and continuous improvement are built into Scrum. Working on a

self-organized team, on complex problems, and receiving frequent feedback
about the value an individual creates is a great motivator. Retrospectives and
154
9780134862156_web.indb 154 06/10/20 8:04 PM

Organizational Structures Can Either Help or Hinder Scrum
the work in a cross-functional team continuously improve an individual’s

skills, which in turn improves the wider organization.
The same is true for long-term planning. In an agile environment where change
is the norm, organizations can’t expect to create a detailed plan for a year or
more. Organizations need to be responsive to change just as their Scrum Teams
are. Instead of detailed yearly plans, they need clear goals and only a rough plan
of what they will do to reach those goals. Each Sprint will provide a detailed
plan for the next steps toward those goals, and organizations will be able to mea-
sure progress against their goals, something that was often impossible before.
Organizations also often need to change their approach to decision-making.

Organizations with many hierarchical layers are often comparatively slow to
make decisions in contrast to companies of comparable size with a flatter hier-
archy. The reason is that each layer has to consolidate and prepare information
and data for the layers above, then wait for decisions to be handed back down.
Decisions should be made at the point nearest to the work that faces the con-
sequences of it. This means that, in an agile environment with self-organizing
teams, most decisions are made by the teams themselves. Bigger decisions are
often prepared and made by representatives of teams, independent of upper
management. Management and leadership in an organization create and
maintain the space where this self-organization can take place.
Along with the way they make decisions, organizations also often need to
change their structure, especially when they are organized into functional
departments, or “silos.” When members of cross-functional and self-
organized teams are organized in functional silos, such as when all developers
work for a development manager and all testers work for a QA manager, they
can feel conflicted about who they should take direction from. What should
they do if their manager tells them to work on a “special project,” but their
Scrum Team needs their help to reach the Sprint Goal?
Removing these conflicts means changing the organizational structure. There

is no simple recommendation on how to do this, or what to do, but the typi-
cal solutions often involve creating networks of individuals and teams.1
1. Maybe you also want to look at Sociocracy (see https://sociocracy30.org) or Holacracy [Robertson15].
155
M08_Gotz_C08_p153-p166.indd 155 06/10/20 8:55 PM

The CEO is speaking at an all-hands meeting: “We have seen our Scrum Teams
do great things, and we are convinced that this way of working can help other
teams. We’re committed, as a management team, to helping Scrum Teams grow
and thrive.”
One developer says to another, quietly so no one else can hear, “That’s all great,
but the reality is that my manager has told me to focus on improving and growing
my development skills if I want to get promoted to the next level. She says that
increasing my testing skills, which will help my team to deliver more effectively, is
a nice thing to do, but it’s not going to help me get promoted in her organization.”
Fu nction a l O rganiz ation s Ca n B lock Te a m G row th

Functional organizations are founded on the belief that increasing specialist
skills are the best way to grow organizational capability to deliver value. They
see cross-functional skill building as, at best, irrelevant and, at worst, a dan-
gerous distraction from time and effort that would be better spent building
deeper technical skills in a specialty area. Scrum is not antagonistic to special-
ized skills, but it values team member flexibility in deciding what skills they
need.
In a functional organization, employees are managed in groups based on spe-

cific skills and knowledge. Each functional unit handles one aspect of the
product or service provided, including a special group (the project/program
management office, or PMO) that does the work needed to coordinate these
different groups to produce a product or service. Functional organizations
believe that managing employees with similar skills improves the depth of
those skills by promoting communication and knowledge transfer. By reward-
ing depth of skills, it also limits the versatility of the kinds of work that each
employee can perform and reduces the flexibility of teams.
Functional organization leads to organizational blind spots when people with

one set of specialized skills do not see the need to share information with other
specialized skills. They do not understand the work upstream and downstream
156
9780134862156_web.indb 156 06/10/20 8:04 PM

Organizational Structures Can Either Help or Hinder Scrum
of them and consequently miss opportunities to share information that others

might need. Since everyone is focusing on their own functional specialty, it falls
to the project manager to ensure that everyone is collaborating across func-
tional areas to create customer value, but this is too large a responsibility for
one person to shoulder, especially when he or she often lacks the deep techni-
cal skills needed to understand all the unmet needs to collaborate.
Functional organizations reduce their own ability to achieve their goals by

increasing wait time and hand-offs, reducing accountability for results, and
diluting customer focus. They reduce the potential of their employees by
either encouraging them to become too narrowly skilled to work cross-
functionally or by discouraging them from building skills that would increase
their team’s ability to deliver value. By focusing narrowly on building special-
ized skills, the functional organization fails to anticipate, develop, and evolve
new skills that it would learn about only by encouraging people to build
whatever skills they need to best deliver value to customers.2
Fu nction a l O rga niz ation s Provide Ca r e e r Path s

B ut at a Cost
Functional organizations are hierarchical, an organizational structure in
which people are promoted on the basis of their demonstrated technical skills
within practitioner ranks. Groups of practitioners have managers, and these
managers have managers, and so on. Large organizations may have many lev-
els of managers. These levels provide promotional opportunities and their
accompanying increases in earnings and status.
These levels can increase the complexity of collaboration when managers

higher in the hierarchy must approve decisions that could otherwise be made
by a cross-functional team. Empowering teams to make decisions, as we
described earlier in this book, improves team morale and the ability of teams
to deliver valuable product increments to customers, but this empowerment
can also undermine the status of managers who no longer need to be involved
2. You can find out more details about silos and how to break them in Silos, Politics and Turf Wars: A
Leadership Fable about Destroying the Barriers That Turn Colleagues into Competitors by Patrick
Lencioni (San Francisco, CA: Jossey-Bass, 2013).
157
9780134862156_web.indb 157 06/10/20 8:04 PM

in decisions. This loss of status often leads to growing resistance, sometimes

not even conscious, among managers toward Scrum, as they feel their status
and authority undermined.
Removing the hierarchies also undermines ability to reward individuals by

promotion. This is true not only for managers—it can also affect Scrum Team
members. While being a member of a highly effective Scrum Team is very
rewarding, team members may wonder where it is leading. If their only
opportunities to increase their compensation or professional recognition
come from aligning with a functional department, even some of the happiest
Scrum Team members will eventually give up and go back to a functionally
aligned way of working.
Finally, not everyone is good at self-directing and finding new goals by them-
selves; they need some help to understand what might be possible for them
and how they might grow their skills to achieve these goals.
A common alternative to a purely functional organization is a matrix organi-

zation, which solves some problems but comes with its own challenges. See
the sidebar about matrix organizations for more information.
M a t r ix O r g a niz a t io n s Do n’t S o l ve Fu n c t io n a l
O r g a niz a t io n Pro b l e m s
To encourage cross-functional collaboration, many organizations have adopted
a matrix organization structure in which teams are formed by bringing together
members of various functional areas. In this approach, team members take their
day-to-day guidance from their teams, but they are aligned with a functional area
for their long-term career path; team members, in effect, have more than one boss.
In many organizations, employees are members of more than one team, especially
when their skills are in high demand by many different teams. In theory, this results
in the people with these scarce skills being spread across many different teams and
projects, to the fullest possible utilization.
In practice, this structure often leads to teams never having the right skills when
they need them; they are always waiting for someone who is off helping some other
team. If they were allowed to self-organize, they might develop their own skills, but
they are prevented from doing so by functional specialization rules.
158
9780134862156_web.indb 158 06/10/20 8:04 PM

Complex Organizations Need Radical Simplicity
A matrixed organization is also very complicated to manage. To ensure that people

are where they are needed, when they are needed, and to try to minimize con-
flicts, project and program managers track dependencies and create schedules,
which now have to span teams and products. To support this, teams must supply
reports and detailed work plans that consume ever-growing amounts of time while
never really being sufficient to manage complexity. As a result, the supposed func-
tional organization efficiency benefits are never realized. These organizations often
struggle to deliver working product increments in short intervals.
Com ple x O rga niz ation s N e e d R a dic al S implicit y

The Product Owner returns from a meeting with stakeholders. “Our success is
catching up with us. People are hearing what we’re doing, and now everyone has
an opinion on how we should be engaging with them. I’m getting very frustrated.”
One of the developers chimes in, “Tell me about it! We’ve now got the Enterprise
Architecture Team wanting to review what we are doing to make sure we’re con-
sistent with their decisions, and they want to participate in Sprint Reviews to make
sure we’re following the rules.”
Another developer laughs, “Don’t they know the Sprint Review isn’t an approval
meeting? But, seriously, the micromanagement-by-committee tendencies in this
organization are starting to become a problem for us as our work becomes more
visible. This has to stop.”
S c ru m Ca n H e lp E n a ble R a dic a l S im plicit y

There is a belief that large, complex organizations need large, complex orga-
nizational structures and large, complex processes. The opposite is true; large
complex organizational structures fragment the focus and mission of the
organization, resulting in every silo having a slightly different mission and
focus. As consultants, we have spent time in large organizations that felt like
lots of little organizations, each with its own culture and values aligned
around promoting its own interests rather than serving customers.
159
9780134862156_web.indb 159 06/10/20 8:04 PM

Customer-focused Scrum Teams embody radical simplicity. They have only

three roles, all with a singular focus on delivering value. They separate roles
from skills, and team members can develop whatever skills they need to better
help their teams and thereby their customers. They don’t need complex pro-
cesses because they decide their own way of working within broad boundaries
established by the organization. Because Scrum Teams plan in short intervals,
large-scale planning and oversight functions are not needed. Rather than
managers, who are often distanced from the daily work, directing the careers
of their employees, team members gain advice and insight from their peers
through communities of practice, and these same peers provide mentoring
and help team members to build skills.
This is not to say that everything that an organization does will be done by
people organized into Scrum Teams, although we have seen Scrum applied to
non–product development functions such as human resources and marketing,
and we have talked to peers with similar experiences in other departments.
Even Scrum Teams sometimes need help from people with deep skills in a
particular area. In these cases, specialists can join the Scrum Team for a
period to transfer skills or to pitch in as needed. It makes sense for those spe-
cialists to be organized in their own suborganization, but their priority is to
serve the Scrum Teams.
Organizations that have Scrum Teams typically have two kinds of organiza-
tional structures: Scrum Teams, which are their primary mechanism for deliv-
ering valuable capabilities to customers, and support staff, which are
organized functionally. The principle for uniting these two is to place the
work that the Scrum Teams do, and therefore the work that the organization
does for customers, at the center, and organize the support staff around the
Scrum Teams in such a way that the Scrum Teams get the help and support
they need, when they need it, without waiting, queueing, or having to submit
formal requests. This helps the organization to be most effective at respond-
ing to customer needs.
160
M08_Gotz_C08_p153-p166.indd 160 06/10/20 8:55 PM

The manager comes into the Scrum Team’s room, clearly agitated. “I need you to
stop publishing the feature usage data for your releases. Several stakeholders have
seen your dashboards and noticed that the features that they fought so hard to get
into the product are hardly being used. They feel it’s making them look bad, like
they don’t know what they are talking about.”
“Maybe they don’t know what they are talking about,” one of the developers inter-
jects. “We’ve all had a lot of wrong ideas about what customers really need, and
the only way we’ve learned is to measure, and then inspect and adapt.”
“I understand that, but it’s creating a political problem that’s going to come back
to bite us.”
R a dic a l S im plicit y R equir e s R a dic a l Tr a n s pa r e nc y

Traditional organizations are built around selective release of information;
control over information is a kind of power, and deciding what gets shared
and how it is shared is one of the main responsibilities of managers. But this
selective sharing of information means that no one has a complete under-
standing of the situation, and everyone is making flawed decisions based on
filtered and biased (usually unconsciously biased) information.
When people communicate openly, they become aware of different perspec-

tives, which can lead to new ideas. Innovations often result from collaboration
between people with different backgrounds, skillsets, or points of view. When
their view is filtered or homogenized, people tend to merely reinforce existing
ideas and fail to develop new ones.
Organizations that have historically been very hierarchical can find transpar-
ency threatening, such as in the case of a manager who has been expected to
know what is going on in his area of authority feels exposed when he is no
longer always the first to know about new events. Managers may also feel that
certain information makes them “look bad,” as in the situation described pre-
viously. Denying data does not change the situation—it only makes it impos-
sible to respond to it.
161
9780134862156_web.indb 161 06/10/20 8:04 PM

One of our former managers had an expression: “Facts are friendly.” Diluting
or distorting them to make a situation look better than it is might seem to
help, in the short run, but it never ends well. The sooner an organization
responds to new information, the better it is able to perform.
Conditioning an organization accustomed to always having to present infor-

mation in a positive light to embrace radical transparency takes time and
trust. It means viewing information dispassionately, as it is, without spin. But
until an organization can view the world as it is, rather than seeing the world
as it wished it was, it will never really embrace empiricism, and it will never
really reap its benefits.
The Product Owner comes into the manager’s office, obviously frustrated. “I need
to talk to you about the executive status reporting meeting. I’m wasting valuable
time preparing status updates; marking risks as red, yellow, or green; and reporting
which features we’ve completed. It’s a waste of time; the red-yellow-green status
stuff is totally subjective, and the progress information is available on our dash-
board anytime the executives want to see it. How can I get out of going?”
“I wish I could get you out of attending those meetings, but the executives say that
the status meetings are the best way for them to stay informed.”
“That’s not really true; most of the time, someone important is missing, and they don’t
need to be spoon-fed information in a presentation. I’ll bet if they got used to what we
provide, they’d find their questions answered in a fraction of the time they spend now.”
R e pl ac e R e porting C h ain s a n d G ov e r n a nc e
Proc e ss e s with Tr a n s pa r e nc y
The silos in traditional organizations impede the free flow of information,
forcing the organization to create complex reporting mechanisms to ensure
that people have the information that they need to make decisions.
Unfortunately, this information tends to be selective and distorted by interpre-
tation and aggregation, so people rarely get the information they really need.
Replacing this complexity with transparency ensures that people can get the
information they need, when they need it, unfiltered and undistorted.
162
9780134862156_web.indb 162 06/10/20 8:04 PM

Scrum provides simple and easy-to-use mechanisms for sharing information.

Anyone interested should be able to see the team’s priorities, to understand
what the team is working on, and to know what the team expects to achieve
by the end of the Sprint. They should be able to understand how decisions are
made, and by whom. All of the elements required to achieve effective gover-
nance are present without anyone having to implement additional processes;
in fact, such processes are often less governable and less transparent than
those already provided by Scrum.
The problem is that traditional organizational practices are rarely transparent

and need extra processes to make them governable. To subject a Scrum Team
to the same processes merely creates extra work. When organizations under-
stand and embrace transparency, they find they can spend more time on deliv-
ering value to customers by reducing governance overhead.
The Product Owner is frustrated. “I’m spending too much time updating all the dif-
ferent stakeholders we have. Everyone is just interested in how what we are doing
affects their organizational silo, and no one seems to care about the customer.”
“What do you mean?”
“HR wants to know about our future hiring needs. Development wants to under-
stand how our Sprint Plans are incorporating the enterprise architecture they have
developed. Customer Support just cares about adding transaction logging. Com-
pliance wants to make sure we are filling out their compliance reports. But when
I try to talk about how we are improving customer value, they aren’t interested.
They only seem to care about their own narrow concerns, not the customer’s.”
B reak Down S ilos and Align around Customer Value

Earlier in this chapter, we discussed a number of scenarios related to siloed
functional organizations, and we observed that functionally structured orga-
nizations need an additional project and program management organization
to coordinate between the silos. They also typically need additional layers of
management above the silos to guide the silos in their work.
163
9780134862156_web.indb 163 06/10/20 8:04 PM

Silos complicate goals as well. Complex organizational goals need to be

mapped onto silos, which makes them even harder to understand because
each silo focuses on only one aspect of the goal. Will the goal be achieved if
all the silo goals are achieved? Maybe, but as often as not, nobody knows.
Organizations can learn a lot by mirroring the Scrum Team’s singular focus
on the customer. Expressing goals in terms of measurable improvements in
customer well-being or satisfaction is very concrete. This makes it easy to
understand when the Scrum Team achieves that goal; try doing that with the
average corporate goal, which is usually vague and unmeasurable. Organizing
around customers improves focus and flexibility. Risks of inconsistency across
different customer-oriented groups or teams can be easily reduced by forming
communities of practice to share learnings and by reorienting common
shared functions (e.g., human resources) to support customer-facing teams
when they need assistance.
Siloed organizations have lost contact with the customer in pursuit of stan-
dardization of specialized expertise. Returning the customer to the center of
the organization’s focus and letting communities of practice take on the tasks
of knowledge sharing and professional mentoring help the organization to be
more responsive and competitive.
S u m m ary
Scrum Teams always exist in an organizational context that both enables and
constrains them. The way the organization is organized can either make their
lives easier or make them more difficult. Functional organizations, whether
matrix-managed or not, can make Scrum Teams less effective by overspecial-
izing skills or by actually discouraging team members from learning the new
skills they need to help their teams. Functional organizations can limit learn-
ing that might lead to new career paths by failing to adapt to changing cir-
cumstances.
The post-traditional organization looks much flatter. It is centered around

teams, or groups of teams, that self-organize to deliver value to customers.
164
9780134862156_web.indb 164 06/10/20 8:04 PM

Summary
The remaining support functions focus on enabling the cross-functional

customer-facing teams to focus on delivering value. The organization itself
embraces empiricism and transparency to learn and grow over time to
improve its ability to deliver value.
These changes don’t happen overnight, nor in weeks, nor even in months.
Even the most dedicated organizations take years to reshape themselves,
because the real changes that they need to make are not structural but cul-
tural, and cultural change takes a long, long time. But with persistence and
dedication, cultures can and do change.
165
9780134862156_web.indb 165 06/10/20 8:04 PM

Continuous
I mprovement N ever
Stops 9
Many organizations treat the introduction of Scrum and complementary
practices as a project with a start and an end. They hope that they can
“implement” Scrum and, once it is implemented, deliver value faster, more
reliably, and in higher quality.
These organizations don’t understand that Scrum is not a tool that can be
installed and then used; Scrum’s intent is to create a system and culture of
continuous improvement that enables the organization to continuously change
and adapt on the basis of feedback. The important aspect of continuous
improvement is that it happens continuously. There is no end to improvement.
Just as sports teams continuously try to become better, Scrum Teams continu-
ously try to improve their environment, tools, and practices. Just as sports teams
and their capabilities develop in an ever-changing environment, Scrum Teams
live and work in an environment that changes around them continuously, and
therefore they continuously adapt their skills and practices to these changes.
This change makes yesterday’s improvement tomorrow’s need for improvement.
When we look back on more than 25 years of Scrum, many of the things that
Scrum practitioners did to achieve success in the past no longer help them; the
world changes continuously, and so Scrum Teams must continually discover
167
9780134862156_web.indb 167 06/10/20 8:04 PM

Chapter 9 Continuous Improvement Never Stops
for themselves what will help them today. For this reason, Scrum does not
prescribe practices but instead helps teams to learn how to collaborate and
self-manage so that they learn to find their own way. Finding your own path,
as a team, seeing how you have learned and improved, is a deeply humbling
but highly satisfying experience.
H ow to K e e p I m prov e me nt Continuous
“Great. I wasted two days on this new idea we had for our mobile app. We tried it
with some of our customers this morning, and nobody liked it.”
One member of the Development Team is disappointed. He presented a clickable
prototype for a feature idea the Product Owner had and wants to validate before
it is implemented.
“The worst thing is that I think the idea is great and have had such high hopes for it.”
“But does that mean the idea for this feature is bad or just that the current imple-
mentation in the prototype has to be improved?” his colleague asks with interest.
“In my opinion, the idea is promising, and I wouldn’t like to give up so quickly.”
“That’s right,” the Product Owner agrees. “We should refine the idea and try
another version of the prototype. Some of the test users have given us very inter-
esting feedback that I want to take into account for the next version. I am sure we
will be able to improve it a lot.”
F. A . I . L .: Fir st At te m p t in L e a r ning
If you fail, never give up because F.A.I.L. means “First Attempt In Learning”.
—A. P. J. Abdul Kalam, former president of India
Most people have an aversion to failure. They see failure as an embarrassment

and seek to avoid it. But innovation means confronting the unknown, and the
only way we ever really learn is to try something and have it not work out as
we expected, because that unexpected result forces us to look at the problem
in new ways. “Failure” is really just a gateway to learning. In a complex
168
M09_Gotz_C09_p167-p182.indd 168 06/10/20 8:58 PM

How to Keep Improvement Continuous
environment, the right answer and correct solution can’t be predicted; it has
to be found by testing hypotheses in small experiments, inspecting the results,
and adapting according to feedback. Sounds familiar, doesn’t it?
Every experiment tries to fill a gap in our knowledge by testing whether some-
thing we believe to be true is actually correct. Whether that test passes or
fails, we have learned something, and we often learn more when our experi-
ments upend our beliefs than when they confirm them. Since time is of the
essence, we need to quickly understand when we are making incorrect
assumptions, lest we spend too much time and effort pursuing a wrong path.
Failure does not mean to deliver a solution in poor quality. This is failure that
can and should be avoided. An experiment that fails our expectations is a
welcome opportunity to learn, whereas failing by not meeting quality expec-
tations is unnecessary and unwelcome.
Traditional organizations often try to avoid failure, even to the point of pun-
ishing it. The culture of distrust this mindset produces can lead to two unde-
sirable outcomes:
• People hide failure.

•
• People avoid failure by not taking any risks.
•
When failure is hidden, the first pillar of Scrum crumbles: transparency. A
Scrum Team needs transparency in order to formulate new hypotheses and to
create and execute new experiments. Hiding failure can take a lot of effort
that would be better spent learning from the failure and improving the status
quo. When people try to hide failure, blame others, or invent excuses, they
miss valuable opportunities to learn.
Avoiding error is similarly problematic. An experiment needs to be unbiased

regarding the result in order to correctly validate an assumption. If an experi-
ment is set up to prove a specific hypothesis, chances are high that the result
will be as expected, but it doesn’t reflect reality—it reflects your assumptions
(see the sidebar “Information Value Neutrality” in Chapter 6). This is the rea-
son clinical experiments are executed as double-blind experiments where
169
M09_Gotz_C09_p167-p182.indd 169 06/10/20 8:58 PM

neither the executing scientist nor the subject knows who receives a placebo
and who receives the real drug to be tested.
If your organization is risk-averse and tries to avoid failure, it can help to

start with small experiments and show the benefit of learning early and often.
It also helps to avoid language that associates failure with mistakes or errors
and instead talk about assumptions that have been invalidated. The goal is
not to hide failure but to reframe it into something that helps us improve our
results, tools, and processes.
“I don’t think our retrospectives are really valuable anymore,” a developer says to
her colleague on their way back from the Sprint Retrospective to the team room.
“We seem to talk about only small issues and improvements. I think our Scrum
practice has become quite good.”
“I think you are right,” her colleague answers. “We shouldn’t waste our time with
regular Sprint Retrospectives; we can always schedule a retrospective when we
see some need for improvement.”
“Exactly. This would give us more time to work on the product. Let’s bring this up
as a suggestion for improvement in the next retrospective.”
We H ave I m prove d Eve ry thing We Ca n A lr e a dy

Why should Scrum Teams have a Sprint Retrospective when there is nothing
left to improve? Let’s reframe this in a different context: Why should a Rugby
team continue to have training sessions when it is on top of its league? This
example shows a common misunderstanding that Scrum Teams have: Many
teams think that there will come a point in time when they have nothing rele-
vant left to improve.
The best teams continuously find areas in which they can improve their tools,
processes, and ways of working. If they don’t, they will decline and fall back
behind where they started from.
170
9780134862156_web.indb 170 06/10/20 8:04 PM

How to Keep Improvement Continuous
Now, here, you see, it takes all the running you can do, to keep in the same
place. If you want to get somewhere else, you must run at least twice as
fast as that!
—Lewis Carroll, Through the Looking-Glass and What Alice Found There
This quote doesn’t perfectly fit the context, as in Carroll’s book, the rules are
somewhat arbitrary, whereas in the real world, the need to improve is usually
driven by competition. The conclusion fits, though: Stagnation equals regres-
sion; if you don’t improve, you decline.
Teams using the Scrum events to regularly inspect and adapt typically
improve significantly when they start with Scrum, just as an out-of-shape
person who starts to work out regularly will have big successes at the begin-
ning. Over time, every improvement becomes more difficult, and the incre-
mental results seem to diminish. It is also harder to find opportunities to
improve as the improvements become less obvious. This can cause teams and
individuals to lose their motivation, so they need to increase their focus to
continue improving.
Since the context in which Scrum Teams work will change around them, they
need to continually adapt and adjust their practices, tools, strategies, and tac-
tics to be effective. Practices that helped them in the past sometimes lose their
relevance and have to be replaced. If Scrum Teams don’t realize this, they may
continue using old practices even after those practices have lost their efficacy, to
the point that sometimes they can become impediments to further progress.
We have never witnessed a Scrum Team that couldn’t improve in some way.
When teams start with Scrum, their improvements are often fairly simple
changes to their processes, collaboration techniques, or communication patterns
that produce dramatic results. As they gain experience, their improvements
become smaller and more incremental, often fine-tuning specific aspects of their
collaboration, communication, or tools to improve workflow, reduce risk, or
increase the effectiveness of how they work together. Just as for a sports team,
these small and sometimes barely measurable improvements collectively make the
difference in performance between an amateur club and a professional team.
171
M09_Gotz_C09_p167-p182.indd 171 06/10/20 8:59 PM

The CEO has invited the Scrum Master to a meeting to discuss growing Scrum in
the organization.
“I am really pleased with how well the Scrum Team has developed over the past
months,” the CEO says. “I think that a lot of this development can be attributed
to your work as Scrum Master. Thank you very much for that.”
“Thank you, I appreciate your kind words. And while I am always trying to support
the Development Team and Product Owner to improve as a Scrum Team, they
earn the credit for every improvement they made in their respective roles.”
“Interesting that you say that, as I have been wondering about something related.
We are considering hiring more developers to cope with increasing requests by
customers for new features. If we create a new Scrum Team with these new hires,
would you be willing to also be their Scrum Master?”
The Scrum Master hadn’t expected this and is silent for a few seconds, then smiles.
“Thank you for your trust in me and my abilities. It would be great to work with a
new team and help them learn about and practice Scrum. It would also be great to
be able to answer our customers’ requests quicker. But who would take over for
me as the current team’s Scrum Master?”
“Well, can’t they take care of themselves? Perhaps they need some transition
time, but since you have said yourself that they have improved a lot over the past
months, shouldn’t they be able to walk alone from here?”
D oe s a S c ru m M a ste r B ecome O bsolete ?

The simple answer to this question is no. The Scrum Master supports the
Scrum Team and the surrounding organization to help them continuously
improve. Just as a coach helps a sports team to become better at what it does,
a Scrum Master helps the Scrum Team. The better a Scrum Team gets, the
better the Scrum Master needs to be in order to be able to help the team to
improve further.
What would happen if a professional sports team fired its trainers and let the
team create and execute its own training plan? Would the team be able to keep
its current status of success? No; a coach for a sports team offers an outside
172
9780134862156_web.indb 172 06/10/20 8:04 PM

Retrospectives as the Driver for Improvement
perspective and can make transparent deficiencies that are invisible to the team
members. In the same way, a Scrum Master makes transparent opportunities
for improvement that the Scrum Team and the surrounding organization
aren’t aware of. When this outside perspective is removed, an important part
of improvement will be neglected.
Our experience as Scrum Masters has shown us that our work changes as
Scrum Teams gain experience; they have different questions, and we spend
less time helping them understand rules, roles, and practices and more time
helping them to hone skills and improve their workflow. An experienced
team’s Scrum Master acts more as a coach, asking the right questions and let-
ting the Scrum Team figure out the answers. The conversations between
Scrum Masters and their experienced Scrum Teams shift from mechanical dis-
cussions on how to apply Scrum or a specific practice toward questions of
mindset and culture.
This makes the work of Scrum Masters more interesting, but also more chal-
lenging. It creates opportunities for them to grow in their role, adding experi-
ence and nuance to their role. This journey is both interesting and fulfilling,
and it has no end; that’s why it’s called continuous improvement.
R etros pectiv e s a s the D rive r for I mprove me nt

“Okay, please think back to what happened during the last Sprint.”
The Scrum Master lets the rest of the team think for a moment. The team mem-
bers have just started their Sprint Retrospective, and the Scrum Master wants it
to start on a positive note.
“Got it? Then please, one after another, tell us, in one sentence, your highlight of
this Sprint. Who wants to start?”
173
9780134862156_web.indb 173 06/10/20 8:04 PM

R ein forcing th e Positive

Scrum Teams typically focus the Sprint Retrospective on what they can
improve. And this makes sense, as they try to improve their tools, processes,
and practices. But if they focus solely on their problems, they can make them
larger and more difficult to solve.
We like to start retrospectives by having the Scrum Team focus on what it is

doing well. This helps to create a more optimistic and constructive atmo-
sphere, and it helps the team to identify those things it wants to amplify.
This shift in focus enables the team members to see what they were already
able to achieve in the past, which is a great starting point for further ways to
improve. By concentrating on solutions they have found in the past, they usu-
ally find more and better solutions for their current problems; it helps them to
focus on solutions and not simply on the problem.
The Scrum Team has identified more than twenty aspects in their Sprint Retro-
spective that should be improved, so the Scrum Master wants to limit the list of
improvements to the most important ones.
“Well, that is a great collection of things we could improve. Now I would like
everyone to take three minutes to have a look at them and select a maximum of
three things you personally would like to see implemented during the next Sprint
and mark them with a small dot.”
After the team has voted, the Scrum Master asks, “Did you select the items you
would like to work on during the next Sprint? Let’s quickly sort the proposals
based on the votes they got to increase clarity. Then we can discuss what exactly
we will improve in the next Sprint and how.”
Focus on a S ing le I m prove me nt

Most Scrum Teams find much that they would like to improve during their
Sprint Retrospective, when the memories of the Sprint are still fresh in their
174
9780134862156_web.indb 174 06/10/20 8:04 PM

Retrospectives as the Driver for Improvement
minds and they can still feel the pain of working ineffectively. They have to
resist the temptation to take on too many improvements, as it will dilute their
focus; if they try to improve ten different things, they will likely improve
nothing in the end. If, on the other hand, they select one thing to improve and
concentrate on improving it, they usually make progress.
Does it have to be just one thing? Not always. Scrum Teams can (and should)
be free to work on more than one improvement at a time if they really think the
improvements are important; they just shouldn’t take on too many. How many
is too many? Only the Scrum Team can answer this question; if it doesn’t know
how many improvements it can work on in parallel, the team should try as
many as the members feel comfortable with and see what happens. By the end
of the next Sprint, they will have a better idea of how many areas of improve-
ment they can concentrate on at once. Really improving one small aspect every
Sprint has much more overall effect than planning many different and often big
improvements that aren’t followed up and finished in the end.
During their Sprint Retrospective, the members of the Scrum Team reflect on how
far they have come on their journey but also on how far they have to go.
“You know, it occurs to me that a year ago, we could not have done what we did in
this last Sprint. We ran into some organizational impediments that required us to
get the attention of senior management to clear. And they did it; they understood
how important it was, and they cut through existing procedures to get us what
we needed. We used to complain about that stuff all the time, but nothing ever
happened. And now it did.”
“You’re right. When we’re focused on day-to-day work, it’s hard to see how far
we’ve come, but looking back, I can see that what we once thought was impossible
is commonplace.”
175
9780134862156_web.indb 175 06/10/20 8:04 PM

S hift th e O rganiz ation’s C u ltu r e ove r Time to

I m prov e Focus
Culture is an umbrella term which encompasses the social behavior and
norms found in human societies, as well as the knowledge, beliefs, arts,
laws, customs, capabilities, and habits of the individuals in these groups.
—Edward Tylor, Primitive Culture, Vol. 1
We often hear from organizations that “Scrum won’t work for us; our culture
won’t accept it.” And in the short run, what they say is true. On a day-to-day
basis, culture seems fixed and unchangeable, and yet, slowly, day by day, the cul-
ture of any organization is changing all the time. It is shaped by the myriad
small actions of everyone in the organization. It is shaped by the countless deci-
sions that people in the organization make. It is shaped by the leaders, both for-
mal and informal, in the organization as they shift norms and set examples.
Culture is not something that anyone dictates; it emerges. Executives can

influence the culture, but to their great frustration, they cannot dictate it or
control it. Culture is, ultimately, a by-product of natural self-organization of
the people in the organization. It is influenced by organizational goals, but
even more so by the decisions that managers make in hiring and the decisions
that team members make about how they will work together.
Over the long run, culture is fluid, but at a rate that is hard to see on a daily basis.
Culture is the thing that, we think, separates the winning organizations from the
also-rans. And the most important characteristic of a winning culture is one that
embraces the Scrum Values: commitment, courage, focus, openness, and respect.
Will S c ru m Ev e r B e Complete ?
The team has worked with Scrum for nearly eighteen months. The team mem-
bers have learned a lot and improved continuously. Not everything they tried has
been successful but, all in all, they are very happy with what they achieved. Every
year, the whole company celebrates at a big party where the CEO talks about the
176
9780134862156_web.indb 176 06/10/20 8:04 PM

Will Scrum Ever Be Complete?
progress the company made in the last year and its goals for the coming year. This
year, he takes a minute to talk about the growth and successes of the Scrum Team.
“Looking over the last year, I think we can all agree that the team has come a long
way. They have continuously questioned themselves and tried to find ways to im-
prove both our product and the ways they develop and sustain it. I am very proud
of what they achieved and want to thank them wholeheartedly. I am confident that
they will be able to use what they have learned and continue on their path of con-
tinuous improvement. Since we as a company have now successfully implemented
Scrum, I expect us to be able to use parts of it in other areas of our company.”
Wh e n A r e We D one I m ple me nting S c ru m ?

Some things can’t be “implemented” and are never “Done.” Examples include
playing musical instruments, doing sports, and practicing yoga or meditation.
With those things, you continually try to become better at what you are doing
and strive to improve yourself and your practice. Sometimes you reach a pla-
teau where it seems that no further progress is possible, but this can pass and
lead to further progress.
The same is true for Scrum: It is not implemented and then used—it is prac-
ticed. Teams and organizations shouldn’t expect that they will have a period
during which they are “adopting” or “implementing” Scrum, after which they
will just apply what they have learned. They should expect that practicing
Scrum is a continual learning journey, one in which teams will, we hope, contin-
ually improve, but there will never be a time when they are done learning.
When organizations fail to recognize this, they also fail to allow for continued
experimentation and learning, at least not to the extent they expected and
allowed when they were introduced to Scrum. This often causes Scrum Teams to
experience setbacks, as they lose focus on continuously improving and instead
just focus on working on the product. Continuously improving the product and
continuously improving the team’s way of working can’t be separated.
Sometimes Scrum Teams who assume they have successfully implemented

Scrum aren’t as aware of their own misunderstandings and so become blind
177
9780134862156_web.indb 177 06/10/20 8:04 PM

to opportunities for improvement; they cease to question their practices,

tools, and processes because they think they have already mastered them.
The practice of Scrum is a never-ending journey: You start by learning and

using the elements of the framework, then learn how to improve using them,
and build up mastery and excellence in different areas. On every part of the
journey, you learn something new and find challenging places of interest; you
even revisit some of them and see them from a different perspective. And
there is always a new sight to find and a new interesting place to visit. The
goal is to ultimately increase the value by delivering better results to the
Scrum Team’s stakeholders. Improvement is not an end in itself.
Many cultures have found metaphors and images that describe such a path of
mastery. In the western world, we are used to the terms apprentice, journey-
man, and master. In Japan, it is the concept of Shu Ha Ri that describes
something similar (see sidebar for more information). All those paths have
levels of expertise that have to be achieved, but there is no end state to the
personal or professional development.
S hu H a R i
Shu Ha Ri is a concept that comes from Japanese martial arts and refers to three
levels of learning a student has to go through from apprenticeship to mastery.
These levels are called Shu, Ha, and Ri.
Shu is the first level of learning. It means to sustain or to obey. You learn by imi-
tating or following given rules. Only one who learns the rules is able to later alter
them without losing the concepts or missing important insights.
Ha is the second level of learning and means to break up, getting free, or digress.
Students may vary given rules and adopt them to their concrete situation. This
goes beyond following rules; students need to know the background and mechan-
ics behind them.
Ri is the third and highest level of learning and understanding. It translates to leave
or cut off and means to leave known paths. Experiences with and mastery of the
rules is the prerequisite to reach this level.
178
9780134862156_web.indb 178 06/10/20 8:04 PM

In six weeks, a major release will be deployed that contains most of the currently
planned features for the product. The Development Team has invited the Product
Owner to discuss the changes it would like to pursue following this release.
“Once we deliver the release, the Product Backlog will be nearly empty,” one de-
veloper starts. “What remains are only smaller features and small improvements
to existing features. If that’s the case, we’ll probably want to change our team’s
composition and maybe even our way of working, so we wanted to talk about this
early enough to anticipate the changes.”
The Product Owner agrees. “Yes, that’s correct. Our upcoming release will be a
major improvement for our customers. After we deliver it, we will keep improving
our product, but on a much smaller scale. I had expected that the Development
Team would continue to work on those features and be responsible for sustaining
and supporting the product.”
“Since that’s the case,” another developers steps in, “we have to think about how
the team needs to change to support the change in responsibilities. For example,
we probably have too many software developers but not enough staff to run the
systems and handle support calls.”
The Product Owner nods in understanding. “Good point; let’s discuss what we
need. It looks like you already have given this some thought, so why don’t you start?”
H ow to U s e S c ru m O nc e the Product I s L ive

A product will go through various stages over its lifetime. In the early stages,
most of the effort that goes into a product is directed at creating it and mak-
ing it ready for customers to use. Later, the product has to be supported and
sustained effectively and efficiently. At the end of its life, it needs to be retired,
and customers may need help migrating to other products.
A Scrum Team can, and should, take care of a product over its complete life-
cycle. This strengthens accountability and increases quality, as the people
building the product are also responsible for running it. Yet the knowledge
and skills to develop a product are often different from those needed to sus-
tain and support it.
179
9780134862156_web.indb 179 06/10/20 8:04 PM

In response, Development Teams may also need to change, but in a gradual

and thoughtful way, so as not to add stress and turbulence to the team’s work.
Anticipating change by making the shift in skills transparent helps the team
think about how its composition and skill needs might need to change. The
team in the preceding example could add one or two colleagues with product
support skills to help the team learn more about what it will need to do and
to help the new team members learn how to become members of the Scrum
Team. This helps the team adapt to a new mission with less stress and less
risk and to adjust more gradually to the new team dynamics.
A Development Team that has remained relatively stable in its composition

over time may not need to change team membership. Some teams we have
worked with have been able to improve the cross-functional skills of team
members so that they were able to cover the whole range of product develop-
ment and support responsibilities. This can’t happen overnight and is enough
work for many months or even years, but it creates a strongly bonded team
that can cope with almost every problem that is thrown at them.
“Do you think it makes sense to invite a Scrum coach for a Sprint or two to review
our current way of working? Maybe we could get a few tips that help us to further
improve our Scrum, especially now that we would like to use it with more and
more teams.”
The CEO and the Product Owner are having lunch together, and the CEO seems
to have been infected with the idea of continuous improvement.
“I am not sure that this will help,” the Product Owner answers. “We might get a
few insights that would take us a while to get on our own, but I wouldn’t want to
spend a lot of money on that. What about inviting someone to accompany and ob-
serve our Sprint Review, Sprint Retrospective, and Sprint Planning and getting feed-
back on those? This expert could also offer some smaller sessions on topics that
the team would like to learn more about. That way, we could combine an outside
review with learning topics we are interested in. What do you think about that?”
“That’s a good idea. Do you have someone in mind whom we could ask?”
180
9780134862156_web.indb 180 06/10/20 8:04 PM

S c ru m D oe s n’t N e e d O ut side E x pe rti s e

We have worked as outside experts for Scrum Teams for most of our careers.
Therefore, we know what benefit outside expertise can bring; but we also
know that it is often not necessary.
Scrum Teams that approach continuous improvement seriously will find their
own way, without outside help. They will work from one small improvement
to the next, and even though they will find some dead ends, they will find
their way out again because they are the experts for their own context.
No outside Scrum expert knows an organization as well as the people work-

ing there. Outside experts can still be valuable because they can see dysfunc-
tions and problems that people inside the system have accepted as normal,
but to improve a system, you have to know and understand it.
As a result, we see outside help as a possible catalyst but not a solution.

Outside experts are often able to ask a powerful question that helps the team
start a thought process that can lead to profound insights and change, but
they can’t typically come up with this insight and change by themselves, as
they lack contextual knowledge and experience. When we work with Scrum
Teams as outside experts, we use this dynamic to our advantage. Our custom-
ers can’t lean back, relax, and wait for wisdom to pour out of our mouths.
At the same time, we have to approach the teams and their context with a
beginner’s mind and remember that we don’t have the solutions—we can only
ask stimulating questions.
The idea of the Product Owner in the preceding scenario is a good one: If
you invite an outside expert to help you improve your Scrum, then why not
ask that expert all the questions that the team is currently interested in? These
can be questions about practices and tools as well as about concrete chal-
lenges and how other organizations and teams tackle them. Collect these
questions in advance and send them to the expert so that he or she can pre-
pare for the sessions.
181
9780134862156_web.indb 181 06/10/20 8:04 PM

When our customers ask us if they should get outside feedback, we always
recommend that they do. It usually doesn’t take us much time to gain enough
insight into a team and its way of working in order to help it improve. The
points where we like to engage depend on the team’s questions. If the team
members are interested in improving their Scrum in general, it’s most valuable
for us to participate in a Sprint change and maybe a Daily Scrum. If a
Development Team wants to improve its way of working, we can best help by
spending time with the team while it works on the product. If a Product
Owner would like to improve his or her work with stakeholders and the
Product Backlog, we like to work with both the Product Owner and the stake-
holders to find ways to improve the environment the Scrum Team operates in.
And if the surrounding organization would like to be able to better support
the Scrum Teams, we try to work with it directly, explaining about Scrum and
implementing changes to the environment so that improvement can happen
continuously.
S u m m ary
The most rewarding thing for us about working with teams using Scrum to
solve complex adaptive problems is that we’re never bored. The problems and
their solutions, the teams and their organizations, the business domains in
which those organizations work, and the technologies the teams use to solve
problems all change continuously, and we have to change with them.
We could not have imagined the changes we have witnessed during the last
decade, nor can we foresee the changes that will happen during the next ten
years, but we know that the values and principles of Scrum and the frame-
work it offers help us overcome whatever life can throw at us. We look for-
ward to being part of this journey with different organizations and teams,
learning new things every day and questioning our approaches frequently in
order to find better ones.
We hope you will be able to feel the same curiosity and are as eager as we are
to see what the future brings. We also hope that this book can be a compan-
ion to help you avoid mistakes that others have already made and therefore
help you progress quickly and with minimal risk.
182
9780134862156_web.indb 182 06/10/20 8:04 PM

B ibliogr aphy
[Beck04] Kent Beck & Cynthia Andres. Extreme Programming Explained:

Embrace Change, 2nd ed. Boston, MA: Addison-Wesley, 2004.
[Duarte15] Vasco Duarte. No Estimates: How to Measure Project Progress
without Estimating. Stans, Switzerland: Oikosofy Series, 2015.
[Dunning05] David Dunning. Self-insight: Roadblocks and Detours on the
Path to Knowing Thyself. New York, NY: Psychology Press, 2005.
[Fowler18] Martin Fowler. Refactoring: Improving the Design of Existing
Code, 2nd ed. Boston, MA: Addison Wesley, 2018.
[Gojko11] Gojko Adzic. Specification by Example: How Successful Teams
Deliver the Right Software. Shelter Island, NY: Manning Publications,
2011.
[Gojko12] Gojko Adzic. Impact Mapping: Making a Big Impact with
Software Products and Projects. Woking, England: Provoking Thoughts,
2012.
[Goldratt04] Eliyahu M. Goldratt & Jeff Cox. The Goal: A Process of
Ongoing Improvement, 3rd ed. rev. Hants, England: Gower Publishing,
2004.
183
9780134862156_web.indb 183 06/10/20 8:04 PM

Bibliography
[Kerth01] Norman L. Kerth. Project Retrospectives: A Handbook for Team

Retrospectives. New York, NY: Dorset House, 2001.
[Kim16] Gene Kim, Jez Humble, Patrick Debois, & John Willis. The DevOps
Handbook: How to Create World-Class Agility, Reliability, and Security
in Technology Organizations. Portland, OR: IT Revolution PR, 2016.
[McGregor05] Douglas McGregor. The Human Side of Enterprise. New
York, NY: McGraw-Hill, 2005.
[Patton14] Jeff Patton & Peter Economy. User Story Mapping: Discover the
Whole Story, Build the Right Product. Sebastopol, CA: O’Reilly, 2014.
[Pink11] Daniel H. Pink. Drive: The Surprising Truth about What Motivates
Us. New York, NY: Riverhead Books, 2011.
[Robertson15] Brian J. Robertson. Holacracy: The New Management System
for a Rapidly Changing World (English ed.). New York, NY: Henry Holt
& Co., 2015.
[Rosenberg15] Marshall B. Rosenberg. Nonviolent Communication:
A Language of Life. Encinitas, CA: Puddledancer Press, 2015.
[Vacanti15] Daniel Vacanti. Actionable Agile Metrics for Predictability: An
Introduction [eBook]. ActionableAgile Press, 2015.
[Vacanti18] Daniel Vacanti. When Will It Be Done? Lean-Agile Forecasting to
Answer Your Customers’ Most Important Question [eBook].
ActionableAgile Press, 2018.
[Vigenschow19] Uwe Vigenschow, Bj rn Schneider, & Ines Meyrose. Soft
ö
Skills für Softwareentwickler, 4th ed. Heidelberg, Germany: Verlag, 2019.
184
9780134862156_web.indb 184 06/10/20 8:04 PM

I nde x
A C
Ability to Innovate (A2I), 70, 128 career paths in functional
abstraction levels in Product organizations, 157–158
Backlogs, 62–64 collaboration
Agile Leader Learning Path, 147–148 in cross–functional teams, 71–73
Allspaw, John, 75 importance of, 4–5
architecture pretzel metaphor, 58–60 in Product Backlog
automated testing, 76–77 management, 6
automation in DevOps, 88, 90 between Product Owners and
autonomy, 37 Development Teams, 8–9, 12–13
availability of Product commitment, 32, 39–40
Owners, 8–9, 51–52 competence, 28
completion of Scrum, 176–178
B complex organizations, radical
backlogs. See Product Backlogs; simplicity in, 159–160
Sprint Backlogs complexity metrics in
“big picture” items in Product estimations, 65–66
Backlogs, 13–15 compromise, consensus
blameless postmortems, 75 versus, 110–111
boundaries, 37 concurrent software development, 7
burndown charts, 20–21 conflicts
business, IT versus, 4–5 decision–making authority
in, 103–105
185
9780134862156_web.indb 185 06/10/20 8:04 PM

Index
de–escalation strategies, 109–111 in Sprint Retrospectives, 33

department versus team loyalty, continuous integration, 92–93
112–114 control, responsibility versus, 145–148
disagreements versus, 102–103 conversations, fostering in Product
escalation of, 107–109 Backlogs, 12–13
internal solutions, 106–107 courage, 32–33
intervention by Scrum Master, 31 cross–functional teams, 4
management and Scrum collaboration in, 71–73
Teams, 147 importance of, 34–36
management’s role in resolving, in matrix organizations, 158–159
148–150 self–organization in, 73–75
micromanagement of Scrum speed of delivery, 122–123
Team, 114–116 culture. See organizational culture
outside intervention, 116–118 Current Value (CV), 70, 128
sealing Sprints, 38 customer satisfaction gap, 128
stages of, 108–109 customers
types of, 118–119 aligning goals toward, 163–164
uncovering, 111–112 measuring satisfaction, 127
consensus decision–making, 109–111 cycle times, 68–69, 128
continuous change
learning from failure, 87 D
refactoring code, 77–80 Daily Scrums, frequency of, 53–54
when to fix problems, 80–81 decision–making
continuous deployment, 92–94 authority for, 103–105
continuous improvement, 96, last responsible moment, 7–8
167–182 in organizational structure, 155
completion of Scrum, 176–178 de–escalation strategies for
incremental improvements, conflict, 109–111
170–171 defect rate, 133–134
learning from failure, 168–170 defect rends, 128
number of improvements, department loyalty, team loyalty
174–175 versus, 112–114
organizational culture shift, Development Teams. See also
175–176 self–organization
outside expertise, 180–182 collaboration with Product
positive reinforcement, 173–174 Owners, 8–9, 12–13
product support after release, commitment to goals, 5–6
179–180 disconnect with stakeholders, 39
Scrum Masters’ role in, 172–173 product support after release,
Shu Ha Ri (levels of mastery), 178 179–180
186
9780134862156_web.indb 186 06/10/20 8:04 PM

Index
pulled work, 50–51 emerging structure, 58–60

refactoring code, 77–80 empiricism, 45
responsibilities of, 47, 104–105 employee satisfaction, 128
strategic problem–solving in error culture, 90
documentation, 61–62 escalation of conflicts, 107–109
emerging structure, 58–60 estimations, 64–67
outside expertise, 56–58 events, 42
updating Sprint Backlogs, 17–18 Evidence–Based Management
DevOps, 85–99 (EBM), 70, 128
scope of term, 89–90 experiment loop, 129–132
Scrum and, 91–99
F
complementarity of, 94–96
factual conflicts, 118
continuous deployment, 92–94
failure, learning from, 87, 168–170
workflow improvements, 97–99
feedback
Three Ways of
importance of, 5
complementarity of Scrum and
DevOps, 95–96 in Sprint Reviews, 42–44
defined, 87–88 feedback loops, 87, 96
workflow improvements, 97–99 “fist of five” method, 110
tools and, 88–89 fixing problems, big versus small
problems, 80–81
value streams in, 90
flaccid Scrum. See mechanical
The DevOps Handbook: How to
(zombie) Scrum
Create World–Class Agility,
Reliability, and Security in flow. See workflow, optimizing
Technology Organizations focus, 32
(Kim), 87 forecasting, 39–40
disagreements, conflicts versus, Fowler, Martin, 78–79
102–103 frequency of Daily Scrums, 53–54
documentation, importance functional organizations, 155–158,
of, 61–62 163–164
“Done” increments
G
documentation and, 62
Glasl, Friedrich, 108
as releasable, 22–23
goal conflicts, 118
Drive (Pink), 37
goals
Duarte, Vasco, 67
aligning toward customers,
Dunning–Kruger effect, 28
163–164
E business versus IT, 4–5
EBM (Evidence–Based commitment to, 5–6
Management), 70, 128 incentives for, 134–136
187
9780134862156_web.indb 187 06/10/20 8:04 PM

Index
metrics and, 126–127 Agile Leader Learning Path,

as precondition, 23–24 147–148
governance career paths in functional
principles versus rules, 81–83 organizations, 157–158
replacing with transparency, leadership versus, 148–150
162–163 role in self–organizing teams,
148–152
H Scrum Teams and
hypotheses, 11 responsibility versus control,
hypothesis–driven Product Backlogs, 145–148
10–12 transparency, 144–145
transitioning to servant leadership,
I 151
impact mapping, 63 market share, 128
improvement, monitoring, 138–140. mastery, levels of, 178
See also continuous improvement
matrix organizations, 158–159
incentives, 134–136
measuring success, 23–24, 69–71,
individual/team development, 134–136 121–140
information value neutrality, 135–136 areas of value, 128–129
innovation rate, 128 burndown charts, 20–21
internal conflicts, 111–112 collecting metrics automatically,
internal solutions to conflict, 106–107 136–138
interpersonal conflicts, 118 experiment loop, 129–132
IT, business versus, 4–5 improvement monitoring, 138–140
performance incentives, 134–136
K
speed of delivery, 122–124
Kanban, 67–69
Kerth, Norman, 83 value delivery, 124–127
velocity versus performance,
Key Value Areas (KVAs), 70–71
132–133
Kim, Gene, 87
mechanical (zombie) Scrum, 27, 28
L meetings, frequency of, 40–42
last responsible moment, 7–8 metrics, 23–24, 69–71
leadership, management versus, collecting automatically, 136–138
148–150 defect rate, 133–134
The Lean Startup (Ries), 24 improvement monitoring, 138–140
value areas for, 128–129
M for value delivery, 124–127
management micromanagement of Scrum Teams,
adapting to Scrum, 154–155 114–116
mob programming, 72–73
188
9780134862156_web.indb 188 06/10/20 8:04 PM

Index
N phase–driven approach, 76
Net Promoter Score (NPS), 140 Pink, Daniel, 37
No Estimates: How to Measure positive reinforcement, 173–174
Project Progress without postmortems, 75
Estimating (Duarte), 67 principles, rules versus, 81–83
#NoEstimates, 67 problem–solving, big versus small
nonviolent communication (NV) in problems, 80–81. See also
conflict management, 109 strategic problem–solving
Product Backlogs
O
abstraction levels in, 62–64
openness, 32–33
“big picture” items in, 13–15
optimizing workflow, 67–69
collaborative management of, 6
with DevOps, 97–99
conversation fostering in, 12–13
for speed of delivery, 122–123
estimations, 64–67
organizational culture
as hypothesis–driven, 10–12
in DevOps, 90
ordering, 33–34
initial implementation of Scrum,
pulled work, 50
29–30
structuring, 48–49
learning from failure, 87
User Stories and, 9
shifts in, 175–176
value creation in, 15
transparency and, 161–163
product cost ratio, 128
organizational structure
Product Increments
adapting to Scrum, 154–155
in continuous deployment, 92–94
for cross–functional teams, 34–36
releasable, 22–23
customer focus in, 163–164
Product Owners
functional organizations, 155–158
availability of, 8–9, 51–52
matrix organizations, 158–159
“big picture” vision, 13–15
radical simplicity in, 159–160
collaboration with Development
outcome–based metrics, 70
Team, 8–9, 12–13
output–based metrics, 70
collaborative Product Backlog
outside expertise for Scrum Teams, management, 6
56–58, 180–182
in continuous deployment, 94
outside intervention in conflicts,
ordering Product Backlogs, 33–34
116–118
responsibilities of, 47, 104–105
P in Sprint Reviews, 42–44
pair programming, 72–73 structuring Product Backlog,
performance 48–49
incentives for, 134–136 product support, 179–180
velocity versus, 132–133 product vision, 24, 33–34, 126–127
189
9780134862156_web.indb 189 06/10/20 8:04 PM

Index
project managers, 46–48 Product Backlog size, 48–49

Project Retrospectives: A Handbook pulled work, 50–51
for Team Retrospectives Scrum Master as project
(Kerth), 83 manager, 46–48
pulled work, 50–51 unavailable Product Owner,
51–52
Q common misunderstandings
quality, technical debt, 123–124 commitment versus forecasting,
39–40
R
meeting frequency, 40–42
radical simplicity, 159–160
rigid adherence to Scrum rules,
reducing waste, 123
44–45
refactoring code, 77–80
sealing Sprints, 38–39
Refactoring: Improving the Design
stakeholders in Sprint Reviews,
of Existing Code (Fowler), 78–79
42–44
releasable Product Increments, 22–23
completion of, 176–178
release frequency, 128
DevOps and, 91–99
reporting chains, replacing with
complementarity of, 94–96
transparency, 162–163
continuous deployment, 92–94
requirements, 11
workflow improvements, 97–99
resolution strategies for conflict,
initial implementation, 29–30
109–111
values of, 31–33
respect, 33
Scrum Framework, Kanban versus, 69
responsibility, control versus, 145–148
Scrum Guide
restructuring, 78–80
attributes of Scrum Teams, 3
revenue per employee, 128
continuous deployment and, 93
Ries, Eric, 24
defined, 55
role conflicts, 118
Sprint Backlog purpose, 16
Roman voting, 111
time–boxes, 41–42
rules
transparency, 10
principles versus, 81–83
Scrum Masters
rigid adherence to, 44–45
conflict intervention, 31
S continuous improvement role,
Schwaber, Ken, 70 172–173
scope of Sprints, 7 department versus team loyalty,
Scrum 112–114
adapting organizational structure outside intervention for conflicts,
to, 154–155 116–118
avoidable errors responsibilities of, 46–48, 104–105
Daily Scrum frequency, 53–54 updating Sprint Backlogs, 17–18
190
9780134862156_web.indb 190 06/10/20 8:04 PM

Index
Scrum Teams. See also cross– Sprint Backlogs

functional teams pulled work, 50
altering structure of, 117–118 purpose of, 16–17
attributes of, 3–4 as stale, 21–22
department versus team loyalty, as status reports, 19–20
112–114 updating, 17–18
management and visibility of, 18
responsibility versus control, Sprint Burndowns, 20–21
145–148 Sprint Goals, 2–3, 16–17
transparency, 144–145 Sprint Planning, 2–3, 7
members of, 1 Sprint Retrospectives
micromanagement of, 114–116 blameless postmortems, 75
product support after release, continuous improvement in, 33
179–180 evaluating tools, 88–89
radical simplicity in, 159–160 incremental improvements in,
responsibilities of, 47 170–171
strategic problem–solving in number of improvements, 174–175
documentation, 61–62 positive reinforcement in, 173–174
emerging structure, 58–60 workflow improvements, 98
outside expertise, 56–58 Sprint Reviews
transparency in, 10 purpose of, 94
Scrum.org, 70 stakeholders in, 42–44
sealing Sprints, 38–39 Sprints, 2–3
self–organization, 3 scope of, 7
in cross–functional teams, 73–75 sealing, 38–39
difficulty of, 151–152 stakeholders
importance of, 115–116 disconnect with Development
management versus leadership, Team, 39
148–150 in Sprint Reviews, 42–44
problems in, 36–37 stale Sprint Backlogs, 21–22
servant leadership status reports, Sprint Backlogs as,
defined, 149 19–20
transitioning to, 151 Story Points, 9
Shu Ha Ri (levels of mastery), 178 strategic problem–solving
silos, 39. See also functional documentation, 61–62
organizations emerging structure, 58–60
size metrics in estimations, 66 outside expertise, 56–58
solution–oriented conflict success, measuring, 23–24, 69–71,
management, 109 121–140
speed of delivery, 122–124 areas of value, 128–129
191
9780134862156_web.indb 191 06/10/20 8:04 PM

Index
burndown charts, 20–21 organizational culture and, 161–163

collecting metrics automatically, as precondition, 23
136–138
experiment loop, 129–132 U
improvement monitoring, 138–140 uncovering conflicts, 111–112
performance incentives, 134–136 Unrealized Value (UV), 70, 128
speed of delivery, 122–124 updating Sprint Backlogs, 17–18
value delivery, 124–127 usage index, 125
velocity versus performance, User Stories, 9
132–133 user story mapping, 63–64
system conflicts, 119
V
systems theory in conflict
Vacanti, Daniel, 69
management, 109
value
systems thinking, 87, 95
areas of, 128–129
T in Daily Scrums, 53–54
T2M (Time to Market), 70, 122, 128 experiment loop and, 129–132
team loyalty, department loyalty information value neutrality,
versus, 112–114 135–136
technical debt, 123–124, 128 measuring, 124–127
telemetry, 125 in Product Backlog items, 15
test–first approach, 75–77 product vision and, 33–34
testing value conflicts, 118
speed of delivery and, 122–123 value streams in DevOps, 90
test–first approach, 75–77 values of Scrum, 31–33
Three Ways of DevOps value–stream mapping, 123
complementarity of Scrum and vanity metrics, 24
DevOps, 95–96 velocity, 69–70
defined, 87–88 performance versus, 132–133
workflow improvements, 97–99 visibility of Sprint Backlogs, 18
throughput, 68–69
Time to Market (T2M), 70, 122, 128 W
time–boxes, 41–42 waste, reducing, 123
tools, DevOps and, 88–89 work in progress limit, 68
transparency work item age, 68–69
creating, 10 workflow, optimizing, 67–69
forecasting and, 39–40 with DevOps, 97–99
learning from failure, 169 for speed of delivery, 122–123
management and Scrum Teams, Z
144–145
zombie (mechanical) Scrum, 27, 28
meeting frequency and, 41
192
9780134862156_web.indb 192 06/10/20 8:04 PM

Agile Development
Books, eBooks & Video
Whether are you a programmer, developer, or project manager

InformIT has the most comprehensive collection of agile books,
eBooks, and video training from the top thought leaders.
• Introductions & General Scrum Guides

• Culture, Leadership & Teams
• Development Practices
• Enterprise
• Product & Project Management
• Testing
• Requirements
• Video Short Courses
Visit informit.com/agilecenter to read sample chapters, shop,

and watch video lessons from featured products.
Addison-Wesley • Adobe Press • Cisco Press • Microsoft Press • Pearson IT Certification • Que • Sams • Peachpit Press
Agile_ad_7x9125_CMYK.indd 1 6/11/2019 2:01:57 PM
Z02_Gotz_Index_p185-p198.indd 197 06/10/20 9:12 PM

Photo by izusek/gettyimages
Register Your Product at informit.com/register

Access additional benefits and save 35% on your next purchase
• Automatically receive a coupon for 35% off your next purchase, valid
for 30 days. Look for your code in your InformIT cart or the Manage
Codes section of your account page.
• Download available product updates.
• Access bonus material if available.*
• Check the box to hear from us and receive exclusive offers on new
editions and related products.
*
Registration benefits vary by product. Benefits will be listed on your account page under
Registered Products.
InformIT.com—The Trusted Technology Learning Source

InformIT is the online home of information technology brands at Pearson, the world’s
foremost education company. At InformIT.com, you can:
• Shop our books, eBooks, software, and video training
• Take advantage of our special offers and promotions (informit.com/promotions)
• Sign up for special offers and content newsletter (informit.com/newsletters)
• Access thousands of free chapters and video lessons
Connect with InformIT—Visit informit.com/community
Addison-Wesley • Adobe Press • Cisco Press • Microsoft Press • Pearson IT Certification • Que • Sams • Peachpit Press
9780134862156_web.indb 198 06/10/20 8:04 PM

Professional Scrum Team, The (The Professional... (Z-Library)

Uploaded by

Copyright:

Available Formats

Professional Scrum Team, The (The Professional... (Z-Library)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Professional Scrum Team, The (The Professional... (Z-Library)

Uploaded by

Copyright:

Available Formats

The Professional

9780134862156_web.indb 1 06/10/20 8:04 PM

Visit informit.com/scrumorg for a complete list of available publications.

T he Professional Scrum Series from Pearson Addison-Wesley and

All Scrum.org proceeds from the series go to Year Up, an organization

Make sure to connect with us!

ScrumOrg_Series_page_7x9_125.indd 1 8/12/2019 8:31:13 AM

9780134862156_web.indb 2 06/10/20 8:04 PM

Boston • Columbus • New York • San Francisco • Amsterdam • Cape Town

9780134862156_web.indb 3 06/10/20 8:04 PM

9780134862156_web.indb 4 06/10/20 8:04 PM

Chapter 1 Being an Effective Scrum Team 1

9780134862156_web.indb 5 06/10/20 8:04 PM

Work Burndown Is Rarely Perfect 20

Chapter 2 Common Problems 27

Chapter 3 Scrum Is Not Enough 55

9780134862156_web.indb 6 06/10/20 8:04 PM

How to Measure Success 70

Chapter 4 Releasable Is Less Than Released 85

Chapter 5 Resolving Conflict 101

9780134862156_web.indb 7 06/10/20 8:04 PM

Chapter 6 Measure Success 121

Chapter 7 Scrum and Management 143

Chapter 8 The Agile Organization 153

9780134862156_web.indb 8 06/10/20 8:04 PM

Chapter 9 Continuous Improvement Never Stops 167

9780134862156_web.indb 9 06/10/20 8:04 PM

9780134862156_web.indb 11 06/10/20 8:04 PM

Fundamental to this journey are the following:

• Empirical process: An approach that is rooted in learning by doing and

9780134862156_web.indb 12 06/10/20 8:04 PM

In this context, professionalism means building on this foundation in the

• Discipline, in learning from delivering valuable product increments about

9780134862156_web.indb 13 06/10/20 8:04 PM

The world we live in is full of complex problems. Solving complex issues

Good Luck on the Journey.

9780134862156_web.indb 14 06/10/20 8:04 PM

Pu r pos e of Thi s B ook

9780134862156_web.indb 15 06/10/20 8:04 PM

holistic challenge, not one specific to one aspect of the framework or of a

We don’t intend for this book to be an introduction to Scrum; if you don’t

Who S hou ld R e a d This B ook

9780134862156_web.indb 16 06/10/20 8:04 PM

elements of successful team collaboration and how to meet team challenges

Whether you are an experienced practitioner of Scrum or still quite new to

H ow Thi s B ook I s O rga nize d

Chapter 2, “Common Problems,” addresses some of the common reasons

9780134862156_web.indb 17 06/10/20 8:04 PM

Chapter 4, “Releasable Is Less Than Released,” describes the ideas of

Chapter 6, “Measure Success,” discusses metrics that can be used by a Scrum

Chapter 7, “Scrum and Management,” focuses on the role of management

Chapter 8, “The Agile Organization,” describes the type of organization a

9780134862156_web.indb 18 06/10/20 8:04 PM

Chapter 9, “Continuous Improvement Never Stops,” stresses the fact that

Keep calm and Scrum on.

9780134862156_web.indb 19 06/10/20 8:04 PM

It takes a village to raise a child.

9780134862156_web.indb 21 06/10/20 8:04 PM

9780134862156_web.indb 22 06/10/20 8:04 PM