SM Workbook

Scrum Master Training
Thomas Bär
Version: 08/23
This manual has been crafted with great diligence and all links have been checked and come
without warranty of availability after this check date at the title page. If you find an error,
please email the author of this manual, and you will receive an invitation to a scoop of ice
cream of your choice. Contact: thomas.tb.baer@siemens-healthineers.com
Many of the designations used by manufactures and sellers to distinguish their products
are claimed as trademarks ™ or registered ®. Where those designations appear in this
workbook, and the author was aware of a trademark or registration claim, the designation
have been printed. All trademarks/registrations are used with respect to the owners rights.
The 2020 Scrum Guide™ and the 2021 Nexus™ Guide is used under
the Attribution Share-Alike license of Creative Commons, accessible at
https://creativecommons.org/licenses/by-sa/4.0/ legal code and also described in
summary form at https://creativecommons.org/licenses/by-sa/4.0. By utilizing this Scrum
and Nexus Guide, you acknowledge and agree that you have read and agree to be bound
by the terms of the Attribution Share-Alike license of Creative Commons.
©2020 Ken Schwaber and Jeff Sutherland for the Scrum Guide
©2021 Ken Schwaber for the Nexus Guide
SAFe® © Scaled Agile, Inc. see https://www.scaledagile.com/about/about-us
This workbook made with text set: LATEX and LYX.
Front page picture is a photo by Ian Keefe (https://unsplash.com/@iankeefe) on Unsplash
(https://unsplash.com/s/photos/lumberjack)
2
The difficulty lies not so much in developing new ideas as in escaping from old ones.—John
Maynard Keynes
There are only two things in a business that make money – innovation and marketing, every-
thing else is cost.—Peter Drucker
. . . a person and an organization must have goals, take actions to achieve those goals, gather
evidence of achievement, study and reflect on the data and from that take actions again. Thus,
they are in a continuous feedback spiral toward continuous improvement. This is what Kaizen
means.—W. Edwards Deming
3
Contents
instead of a foreword 6
I. Agile Development
1. agile software development 11

1.1 History, 11. 1.2 Introduction, 12. 1.3 The Manifesto of Agile Software Develop-
ment, 16. 1.4 Enlightened Approaches, 21. 1.5 Bibliography, 23.
2. agile hardware development 26

2.1 Same but Different, 26. 2.2 Agile Values Applied, 27. 2.3 Principles, 29. 2.4 Bene-
fits of Agile Approaches, 35. 2.5 Challenges and Solutions, 35. 2.6 Examples, 35. 2.7
Bibliography, 35.
3. agile practices 37
3.1 Cross–functional Teams, 38. 3.2 Approaches for Environment & Practices, 40. 3.3 In
Detail, 45. 3.4 Bibliography, 52.
II. Agile Frameworks
4. scrum 56
4.1 History, 57. 4.2 Scrum Definition and Theory, 57. 4.3 Scrum Values, 61. 4.4 Scrum
Team, 64. 4.5 Scrum Events, 67. 4.6 Scrum Artifacts, 73. 4.7 When to use Scrum and
When it is Better not to use it, 76. 4.8 Cargo Cult & Zombie Scrum, 77. 4.9 Who can be
a Scrum Master?, 80. 4.10 Who can be a Product Owner?, 81. 4.11 Bibliography, 82.
5. scrum in software development 85

5.1 Bibliography, 85.
6. scrum in hardware development 86

6.1 Additional Considerations, 86. 6.2 Example: Wikispeed, 87. 6.3 Bibliography, 88.
7. scrum outside the software organization 89
4
Contents
8. kanban 90
8.1 History, 90. 8.2 Usage, 91. 8.3 Bibliography, 94.
9. scaling frameworks 96
9.1 Nexus™, 96. 9.2 Scaled Agile Framework (SAFe), 98. 9.3 LeSS, 103. 9.4 Bibliogra-
phy, 104.
III. User Stories
10. user stories 107

10.1 Writing Stories, 109. 10.2 Where do the Stories Come From?, 113. 10.3 Bibliogra-
phy, 114.
11. story handling 117

11.1 Story Estimation, 117. 11.2 Story Splitting, 120. 11.3 Bibliography, 121.
IV. About Our Journey
12. agile@siemens healthineers 124

12.1 Agile Working at Team Level, 124. 12.2 Agile Working at ART Level, 125. 12.3
Bibliography, 127.
V. Appendix
A. certification & transfer into practice 130

A.1 PSM I Certification, 130. A.2 Transfer in Practice, 130. A.3 Bibliography, 131.
B. manifestos 132
B.1 Manifesto of Agile Software Development, 132. B.2 Manifesto of Agile Market-
ing, 134. B.3 The Manifesto of Agile Hardware Development, 135. B.4 The Manifesto of
Agile Sales, 135. B.5 Bibliography, 136.
C. team development 137

C.1 Team Size, 137. C.2 Development Stages of a Team, 138. C.3 Introduce Agile with
5
Contents
an Existing Team, 140. C.4 Role of the Management, 140. C.5 Bibliography, 142.
D. infra- and organizational structure 144

D.1 Servant Leadership, 144. D.2 Self-Organizing Team, 144. D.3 Team Facilitation, 144.
D.4 How Agile is a Software Team?, 145. D.5 A Great Developer in a Scrum Team, 146.
D.6 A Great Product Owner in a Scrum Team, 147. D.7 A Great Scrum Master in a
Scrum Team, 147. D.8 A Day in the Life of a Scrum Master, 148. D.9 Bibliography, 149.
E. agile frameworks 150

E.1 SCRUM, 150. E.2 Nexus Framework, 153. E.3 LeSS, 153. E.4 SAFe, 154. E.5 Other
Frameworks, 155. E.6 Bibliography, 155.
F. estimation methods 156

F.1 Planning Poker, 156. F.2 Magic Estimation, 158. F.3 Bibliography, 159.
G. measurement 160
G.1 Evidence-Based-Management, 160. G.2 Team Dashboard, 162. G.3 Project Dash-
board, 165. G.4 Bibliography, 166.
H. lean software development 167

H.1 Lean Principles, 167. H.2 Bibliography, 171.
I. additional material 172

I.1 Famous Quotes, 172. I.2 List of Learning Topics, 172. I.3 Videos, 173. I.4 Bibliogra-
phy, 173.
glossary 176
6
Instead of a Preface
About the course

First, let’s take a quick look at what we will and won’t cover in this course:
In Scope
• What is Agile Development
• What is Scrum
• What is my job as Scrum Master
• How are these values, principles, and practices applied within Siemens Healthi-
neers
• What and how to measure
• Preparation for PSM I certification
Out of Scope1
• Software and hardware development techniques
• Architecture and system engineering techniques
• Working with senior management
• Leading change in general
This course is different from most courses you will take or have taken. attended before.
We divide the course into a preparation phase, a phase, and a follow-up phase. In the
preparation and (the knowledge acquisition phases) you will work alone, with a alone,
with a learning buddy or in a group. I provide texts and links to videos or websites for
you to work with. In You will also find exercises in this book. The Presence phase (the
understanding phase) is for applying and deepening the topics.
We will loosely follow the ideas of the book “Training from the BACK of the Room!”
[Bow09]. The idea of this book is to into four phases, with the "Connection" and "Con-
cepts" parts in the preparation "concepts" part in the preparation phase and the "comple-
tion" part in the part in the follow-up phase. The "concrete practice" is our part of the
attendance phase.
During our presence phase we work in small time units (also called boxes) that help
us to focus on the goal and the outcome.
This course is just the beginning of the Scrum Master’s Learning Path, which is a
journey into a new world and will change you think and work.
There is so much knowledge out there that needs to be consumed and digested before
you can apply it to your business. This way of working will help you survive in the
Agile/Scrum world after the course.
1
These items may be part of your Scrum Master learning journey.
7
Contents
The Scrum Master’s Learning Path

We start this training with an introduction to Scrum and conclude with the certification.
Certification
Certification is very common in the Agile world. There are some registration organiza-
tions such as Scrum.org2 or Scrum Alliance3 . Both organizations offer certifications at
different levels and at different costs (one-time or annual fee). This course is a prepara-
tion course for the Scrum.org PSM I certification. Passing the exam will demonstrate the
mastery of the Scrum Master fundamentals.
Additional Learning Ideas

As you can imagine, after a two day (4-5 half days remote) course you will not have all
the knowledge to act appropriately in every in every situation. That’s okay. You may
want to explore the to gain a deeper understanding of situations, how people behave,
and how to situations, how people behave, and how to use the right language:
• coaching
• moderation
• group facilitation
• personality types
• hardware and software development techniques
• project management techniques
• product portfolio management
• product management
• leadership
• transition management
• system theory and thinking
• more starting with on page 172
2
https://www.scrum.org/professional-scrum-certifications
3
https://www.scrumalliance.org/get-certified
8
Contents
Learning Events4
There are a variety of learning opportunities to help you gain the knowledge you need,
including
• Agile Conferences
• Scrum Gatherings
• Meet-Ups
• Scrum Conferences
• Development Conferences
Introduction of the Simulation

We are a manufacturer of outdoor equipment. Our best-selling products are the hiking
backpacks "Jack"5 and "Diane"6 . Because more and more people want to go into the
wilderness and they may not be as well trained as our current customers. So we are
thinking about a pack that can carry the same load as Jack and Diane, but make it easier
for the user by taking most of the weight out of the pack itself.
Bibliography
[Bow09] Sharon L. Bowman. Training from the BACK of the Room! John Wiley & Sons
Inc., 2009.
4
Conference Index (https://conferenceindex.org/conferences/agile)
5
A men’s backpack with a capacity of 30–60 liters.
6
A women’s backpack with a capacity of 30–50 liters.
9
Part I.
Agile Development
1
Don’t focus on delivering a whole list of things–
everything and the kitchen sink–focus on de-
livering what’s valuable, what people actually
want or need.
Jeff Sutherland
Agile Software Development

THE Agile Development does not exist. What is summarized is by it is the description of
an environment for teams to learn how to be adaptive.1 In this chapter we will have a
look at the original ideas.
All development activities are seen as ideation, communication[Joh10] and a way for
a team to work together. But this could not be easily communicated to the companies
(and especially to their management), so the term "agile" was used to summarize it.
1.1. History
Iterative and incremental software development methods can be traced back as
early as 19572 , with evolutionary project management3 and adaptive software
development[Edm74] emerging in the early 1970s.[Gil81]
During the 1990s, a number of lightweight software development frameworks
evolved in reaction to the prevailing heavyweight methods/frameworks (often referred
to collectively as waterfall) that critics described as overly regulated, planned, and
micromanaged.[Swa00] These lightweight frameworks included:
• rapid application development (RAD), from 1991;[Mar91][KH93]
• the unified process (UP) and dynamic systems development method (DSDM),
both from 1994;
• Scrum, from 1995;
• Crystal Clear and extreme programming (XP), both from 1996; and
1
http://www.agile-process.org/
2
Gerald M. Weinberg, as quoted in [LB03], “We were doing incremental development as early as 1957
in Los Angeles, under the direction of Bernie Dimsdale at IBM’s Service Bureau Corporation. He was
a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do
remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola,
where the technique used was, as far as I can tell ... All of us, as far as I can remember, thought waterfalling
of a huge project was rather stupid, or at least ignorant of the realities. I think what the waterfall description
did for us was make us realize that we were doing something else, something unnamed except for ’software
development.”
3
“Evolutionary Project Management (Original page, external archive)”. Gilb. Archived from the original
on 27 March 2016. Retrieved 30 April 2017. and "Evolutionary Project Management (New page)". Gilb.
Retrieved 30 April 2017.
11
1. Agile Software Development
• feature-driven development (FDD), from 1997.
Although these all originated before the publication of the Agile Manifesto, they are now
collectively referred to as agile software development methods.[Lar04]
Already since 1991 similar changes had been underway in manufacturing4 [PML95]
and management thinking[San10] derived from Lean management.
In 2001, the Manifesto for Agile Software Development is published.1.3
In 2005, a group headed by Alistair Cockburn and James Highsmith III. wrote an
addendum of project management principles, the PM Declaration of Interdependence5 ,
to guide software project management according to agile software development methods.
In 2009, a group working with Robert C. Martin wrote an extension of software de-
velopment principles, the Software Craftsmanship Manifesto, to guide agile software
development according to professional conduct and mastery.
In 2011, the Agile Alliance created the Guide to Agile Practices (renamed the Agile
Glossary in 2016)6 an evolving open-source compendium of the working definitions of
agile practices, terms, and elements, along with interpretations and experience guidelines
from the worldwide community of agile practitioners.
1.2. Introduction
Agile development practices7 complements existing methods to address complex prob-
lems and does not devalue them.
4
Iacocca Institute (1991). "21st Century Manufacturing Enterprise Strategy: An Industry Led View".
Iacocca Institute, Lehigh University, Bethlehem, PA.
5
Anderson, David (2005). "Declaration of Interdependence". Archived from the original on 27 January
2018. Retrieved 4 October 2018.
6
McDonald, Kent (1 November 2016). "How You Can Help Agile Alliance Help You". Agile Alliance
Blog. Retrieved 4 July 2017.
7
Agile Software Development: eXtreme Programming (1980s–late 1990s), Adaptive Software Develop-
ment (mid-1990s), Dynamic Systems Development Method (DSDM), Crystal Clear, etc., and more general:
Scrum (mid-1990s)
12
1.2. Introduction
How much do you know about agile development? Check the phrases
that correctly complete the sentence.
1. The development of complex products is (predictable , unpre-

dictable ).
2. The practices of Agile Development are (context-specific , non-

context-specific ).
3. We are more (efficient , effective ) by applying Agile Develop-

ment practices.
4. We (adapt , stick to ) our plans.
5. The development will have a (sustainable , unsteady ) pace.
6. Reflection workshops will happen (regularly , infrequently ).

Every project has risks. To avoid them, there are several development models available8 . Reading to page 20
So we just have to choose the right development model to reduce the risks and therefore
the overall effort.
The Cynefin framework9 can help us find the right model. It offers three primary types
of systems: Ordered, Complex, and Chaotic, with the domains: Clear, Complicated,
Complex, Chaotic and Confused, that help people figure out how they classify the
situation and which steps should be considered.
• Clear—Here, the relationship between cause and effect is obvious to all. The
approach here is Sense (the problem)—Categorize (the problem)—Respond (to
the problem), and apply best practices because we have fixed or rigid constraints.
A best practice could be described by a template or a process.
• Complicated—Here, recognizing the relationship between cause and effect requires
analysis, another form of testing and/or the application of expertise (e.g., by using
experts to find the governing constraints). Here one proceeds according to the prin-
ciple Sense (the problem)—Analyze (the problem)—Respond (to the problem).
One can apply good practices (developed by experts).
• Complex—Here, the relationship between cause and effect can only be perceived
in hindsight, but not in advance. The approach is to Probe—Sense—Respond
approach, this can be seen in emergent practices (Agile Software Development,
eXtreme Programming, extreme manufacturing, etc.). We set the boundary condi-
tions so that we can find the first problem we need to solve.
• Chaotic—Here, there is no cause-and-effect relationship at the system level (but
there is one in the system environment, but it cannot be found experimentally).
8
For advantages and disadvantages of different development models, like waterfall, iterative, spiral and
v-model (see 1.5 on page 23)
9
https://en.wikipedia.org/wiki/Cynefin framework
13
Complex Complicated
enabling contraints, governing contraints,
loosely coupled tightly coupled
Emergent Practice Good Practice
probe–sense–respond sense–analyse–respond
Confusion
Chaotic Clear
lacking contraints, tightly contrainted,
de-coupled no degrees of freedom
Novel Practice Best Practice
act–sense–respond sense–categorize–respond
Figure 1.2.1.: Cynefin Framework
Here the approach is Act—Sense—Respond, and we can discover innovative prac-

tices (Design Thinking). There are no effective constraints.
• Confused—It is not clear which of the other contexts applies. By definition, it is

hard to see when this context applies. “Here, multiple perspectives jostle for promi-
nence, factional leaders argue with one another, and cacophony rules”, Snowden
and Boone write. “The way out of this realm is to break down the situation into
constituent parts and assign each to one of the other four realms. Leaders can then
make decisions and intervene in contextually appropriate ways.”10
In the complex and chaotic context, sensing is used to answer the question, “How can
we make sense of the world so that we can act in it?”
To move from one domain to another, we must expend energy. How to put that energy
into the system to work with elements that live in the complex domain is the main part
of this training. So if you are looking for best or good practices, this training will not give
you many answers because they only exist for the ordered system type. By the way, if
you can find best practices and successfully apply them to your work, you have already
left the complex domain.
The simplified Stacey model11 can also be used to determine the system type by
10
Snowden, David J.; Boone, Mary E. (2007). A Leader’s Framework for Decision-Making. Harvard Business
Review. No. 85 (11): 68–76.
11
Ralph D. Stacey created the Stacey Matrix in 2001. See Complexity & The Stacey matrixfor the complete
model.
14
1.2. Introduction
correlating the problem, the solution, and further dimensions.
Figure 1.2.2.: Simplified Stacey Model
Waterfall Development The waterfall model12 originated in construction and man-

ufacturing processes, such as the design of machine shops with all their air, fluid, and
power dependencies, where late changes are prohibitively expensive or impossible. It
was first time applied to software in SAGE13 in 1956.
The waterfall model was one of the first process models to be introduced. It is a
linear-sequential life cycle model, i.e. each phase must be completed before the next
phase can begin, and there is no overlap between phases, which makes it very easy to
understand and apply14 .
For all other types of problems, a more cyclical approach15 is recommended.
Agile Development encompasses all the frameworks and practices that already exist16 .
What they all have in common is that we look at what is already there. We build on it or
modify it. We stop working on it, take a deep breath, look at the result and ask ourselves:
"Is it close to the desired result?", "What do I need to adjust?", "What have I learned?".
And use the answers for further development.
We call this the empirical process model. We describe what we have—transparency.
Furthermore, we ask questions—inspection. And we change/adapt—adaptation.
12
https://en.wikipedia.org/wiki/Waterfall model
13
https://en.wikipedia.org/wiki/Semi-Automatic Ground Environment
14
for advantages and disadvantages see 1.5 on page 23
15
For more background information on cyclical approaches see [DS90].
16
E.g., Crystal Clear, DSDM, XP, Scrum, etc.
15
We apply this mindset to everything, both the product and the process that helps us
build the product. Without it, agile development will not be possible.
In 1997 Steven L. Goldman defined agility in business as “dynamic, context-specific,
aggressively, change-embracing, and growth-oriented. [Agility] is not about improving
efficiency, cutting costs, or battering down the business hatches to ride out fearsome
competitive ‘storms’. It is about succeeding and about winning: about arenas, and about
winning profits, market shares, and customers in the very center of the competitive
storms many companies now fear.” [Coc06](p. xxvi)
1.3. The Manifesto of Agile Software Development

A few words about the history17 : On February 11–13, 2001, at “The Lodge”18 at Snow-
bird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski,
relax, and try to find common ground—and of course, to drink. What emerged was the
Agile Software Development Manifesto [B+ ]. Representatives from eXtreme Program-
ming(XP), Scrum, Dynamic Systems Development Method (DSDM), Adaptive Software
Development, Crystal Clear, Feature-Driven Development, Pragmatic Programming, and
others sympathizers to the need for an alternative to the document driven, heavyweight
software development processes convened.
And here is the result of three intensive days of work:
We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck James Grenning Robert C. Martin
Mike Beedle† Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
©2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
17
https://agilemanifesto.org/history.html
18
Alistair Cockburn’s home
16
The Manifesto of Agile Software Development19 is a list of four behaviors that agile
developers value and twelve principles. There are items that we consider more important
for project success—those on the left. This does not mean that the items on the right
side can be neglected, they may even be necessary for our product (depending on the
context). If we want to focus on the adaptability, we choose the items on the left.
In any work environment, there are people, work packages (also called projects) and
processes that need to fit together. We cannot focus on just one of these aspects. As
described in the Stacey Matrix, the type of process we use depends on the project and
the people doing it. The twelve principles of the Agile Manifesto articulate these aspects.
These principles are as important as the valued behaviors themselves.
The 12 Principles
Agile principles are a set of domain-specific guidelines for finding practices that are
consistent with agile values. The following agile principles work best in software devel-
opment.
People
More than half of the principles addressing people needs:
• Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software. → We work in an outcome-oriented manner rather than in
an output-oriented manner.
• Build projects around motivated individuals. Give them the environment and sup-
port they need, and trust them to get the job done. → A request to the management
and the organization.
• Business people and developers must work together daily throughout the project.
→ no silos
• The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation. → We have to see the faces and the
body language, with that we get much more information20
• Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely. → e.g., no overtime
working before milestones
• The best architectures, requirements, and designs emerge from self-organizing

teams. → Discussion leads to a better understanding.
19
The Manifesto cannot be used for any other development than software development without adapta-
tions since the principles are context specific.
20
“You cannot not communicate. Every behavior is a kind of communication. Because behavior does not
have a counterpart (there is no anti-behavior), it is not possible not to communicate.”—Paul Watzlawick
17
• Simplicity — the art of maximizing the amount of work not done — is essential. →
Thinking deeply about a plain vanilla solution to the problem.
Processes
When we talk about processes, we must first talk about values and practices. Examples
of values are: from eXtreme Programming (XP): communication, feedback, simplicity
& courage. More generally, the most talked-about agile values are: minimalism, which
corresponds to simplicity21 , feedback, transparency, sustainability (or consistency), and
accountability.
• Welcome changing requirements, even late in development. Agile processes har-

ness change for the customer’s competitive advantage. → The second sentence is
important, there must be a good reason for the customer to change the require-
ments.
• At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly. → Create transparency, review & adapt →
Continually learn and incorporate that learning.
• Deliver working software frequently, from a couple of weeks to a couple of months,

with a preference to the shorter timescale. → Set your time boxes wisely to deliver
value at the end of the time box according to the market needs or rhythms
• Agile processes promote sustainable development. The sponsors, developers, and

users should be able to maintain a constant pace indefinitely. → No over-regulation
• Simplicity — the art of maximizing the amount of work not done — is essential.
→ Strive to find the simplest and most straightforward solutions to problems, avoid
unnecessary work and to prioritize delivering value quickly, but do not cut corners
or sacrifice quality.
Projects
When we talk about projects22 in the agile world, we do not mean projects in the sense of
phase-gated development, like shown in figure 1.3.1.
21
See also: https://www.agilealliance.org/glossary/rules-of-simplicity
22
We will see in a later chapter, that esp. big product development should not be seen as project anymore.
18
Ideas
Scoping
Gate 1: management approval
Business Case
Gate 2: sounding business plan
Development
Gate 3: working prototype
Testing
Gate 4: final product down
Launch
Figure 1.3.1.: Phase-Gated Development
Instead, we try to bring as many phases inside the cycle (named iteration), so that we
can learn as much as possible in a very short time (see empiricism). This also means
that we need different competencies in the team.
A
s na
ent ly
sis
m &
Initial Planning re
qui D
es
Re ig
n
Planning Implementation
Te n
sti tio Deployment
ng ua
al
Ev
Figure 1.3.2.: Iterative Development
19
• Working software is the primary measure of progress. → there might be other

project measures, but this is the only relevant one
• Continuous attention to technical excellence and good design enhances agility. →

invest in training as well as good architecture
• Simplicity — the art of maximizing the amount of work not done — is essential. →
what is really needed to make this project a success
Practice [Timebox: 15 min]

Discussion: Why do you think these principles are so important? We do
this exercise in the big room, all together.
Learning Log [5 min]

If you are a newspaper reporter and are asked to summarize this section for a new article, what
would you write?
Fundamental Ideas of Agile Software Development23

No matter what framework or method your management thinks they are applying, learn
to work this way:
• Produce running, tested, working, integrated software every two weeks, every
week. Build your skills until you can create a new fully operational version every
day, twice a day, multiple times a day.
• Keep the design of that software clean. As it grows, the design will tend to become
complex and crufty. Resist and reverse this tendency consciously, refactoring in
tiny continuous steps, all the time, so that your rate of progress is as steady and
consistent as possible.
23
From https://ronjeffries.com/articles/018-01ff/abandon-1/
20
1.4. Enlightened Approaches
• Use the current increment of software as the foundation for all your conversations
with your product leadership and management. Speak in terms of what’s ready to
go, and in terms of what they’d like you to do next
1.4. Enlightened Approaches

After thinking for half a year about the Manifesto of Agile Development the idea emerged
that all these statement have nothing to do with software and can be used in many places.
And here is the essence of these thoughts:
1.4.1. The Heart of Agile24

You want to change the world.
• Whatever your initiative, it involves changing the world just a little bit.
• The world, however, is remarkably resistant to interventions.
• The best ideas fail because of misunderstandings of how the world will react, or
because of errors in implementation.
These four words help you do it:
• Collaborate
closely with others to generate and develop better starting ideas. Communicate
often to smooth transitions.
• Deliver
small probes initially to learn how the world really works. Expand deliveries as
you learn to predict and influence outcomes.
• Reflect
periodically, along the way. Think about what you’ve learned in your collaboration
and from your deliveries.
• Improve
the direction of your ideas, their technical implementation, and your internal
processes.
1.4.2. Modern Agile25

Over the past decade, innovative companies, software industry thought leaders and
lean/agile pioneers have discovered simpler, sturdier, more streamlined ways to be agile.
These modern approaches share a focus on producing exceptional outcomes and growing
24
From: https://heartofagile.com/lets-begin/
25
From: https://modernagile.org/
21
an outstanding culture. Today, it makes far more sense to bypass antiquated agility in
favor of modern approaches.
Modern agile methods are defined by four guiding principles:
• Make People Awesome

Steve Jobs used to ask his colleagues, “What incredible benefits can we give to the
customer? Where can we take the customer?" In modern agile we ask how we can
make people in our ecosystem awesome. This includes the people who use, make,
buy, sell or fund our products or services. We learn their context and pain points,
what holds them back and what they aspire to achieve. How can we make them
awesome?
• Make Safety a Prerequisite

Safety is both a basic human need and a key to unlocking high performance. We
actively make safety a prerequisite by establishing safety before engaging in any
hazardous work. We protect people’s time, information, reputation, money, health
and relationships. And we endeavor to make our collaborations, products and
services resilient and safe.
• Experiment & Learn Rapidly

You can’t make people awesome or make safety a prerequisite if you aren’t learning.
We learn rapidly by experimenting frequently. We make our experiments “safe
to fail” so we are not afraid to conduct more experiments. When we get stuck or
aren’t learning enough, we take it as a sign that we need to learn more by running
more experiments.
• Deliver Value Continuously

Anything that isn’t delivered isn’t helping anyone become more awesome or safe.
In modern agile we ask ourselves, “How could valuable work be delivered faster?”
Delivering value continuously requires us to divide larger amounts of value into
smaller pieces that may be delivered safely now rather than later.
World famous organizations like Google, Amazon, AirBnB, Etsy and others are living
proof of the power of these four principles. However, you don’t need to be a name brand
company to leverage modern agile wisdom.
22
1.5. Bibliography

Please create some stories and a Definition of Done e.g., for a backpack (
on page 9). Please do the exercise in your breakout teams.
Notes:

Compare and contrast the knowledge and assumptions you had about Agile Practices before the
training with after this section. Write a paragraph summarizing your comparisons.
1.5. Bibliography
[Adz12] Gojko Adzic. Impact Mapping: Making a Big Impact with Software Products and
Projects. Neuri Limited, 2012.
[B+ ] Kent Beck et al. Manifesto for Agile Software Development. last visited:
2021-02-09.
[Bro95] Frederick P. Brooks jr. The Mystical Man-Month. Addison-Wesley, 1995.
[Coc97] Alistair Cockburn. Surviving Object-Oriented Projects. Addison-Wesley

Professional, 1997.
23
[Coc04] Alistair Cockburn. Crystal Clear: A Human-Powered Methodology for Small

Teams. Addison-Wesley Professional, 2004.
[Coc06] Alistair Cockburn. Agile Software Development — The Cooperative Game.

Addison-Wesley, 2006.
[Den17] Scott Densmore. Agile Development Practices Explained. Agile Alliance,

2017. last visited: 2021-02-09.
[DS90] Peter DeGrace and Leslie Hulet Stahl. Wicked Problems, Righteous Solutions —
A Catalogue of Modern Software Engineering Paradigms. Prentice-Hall, 1990.
[Eck14] Jutta Eckstein. Agile Teams: Self-Organizing, Collocated and Distributed.

Agile Alliance, 2014. last visited: 2021-02-09.
[Edm74] E. A. Edmonds. A Process for the Development of Software for Nontechnical

Users as an Adaptive System, pages 215–218. Number 19 in General Systems.
Ernest Edmonds, 1974.
[Gil81] Tom Gilb. Evolutionary development, page 17. Number 6 (2) in ACM SIGSOFT
Software Engineering Notes. 1981.
[Joh10] Steven Johnson. Where Good Ideas Come From: The Seven Patterns of Innovation.
Penguin Group, 2010.
[KH93] James M. Kerr and Richard Hunter. Inside RAD: How to Build a Fully Func-
tional System in 90 Days or Less, page 3. Macmillan, 1993.
[Lar04] Craig Larman. Agile and Iterative Development: A Manager’s Guide, page 27.
[LB03] Craig Larman and Victor R. Basili. Iterative and Incremental Development: A
Brief History, page 47–56. Number 36 (3) in IEEE Computer. 2003.
[Mar91] James Martin. Rapid Application Development. Macmillan, 1991.
[New15] James Newkirk. Introduction to Agile (The Genesis). Agile Alliance, 2015.
last visited: 2021-02-09.
[PML95] A. Presley, J. Mills, and D. Liles. Agile Aerospace Manufacturing. Nepcon

East, 1995.
[San10] Luis Sanchez. A Review of Agile Manufacturing Systems, pages 3561–3600.

Number 39(16) in International Journal of Production Research. November
2010.
[Swa00] P. M. Swamidass. Heavyweight project organizationHEAVYWEIGHT PROJECT

ORGANIZATION, pages 261–262. Encyclopedia of Production and Manu-
facturing Management. Springer, 2000.
24
1.5. Bibliography
Additional Readings
[1] Wikipedia Article about Mental Modelshttps://en.wikipedia.org/wiki/Mental model
[2] Google project oxygen—8 point plan to help managers https://rapidbi.com/google-

project-oxygen-8-point-plan-to-help-managers/
[3] Blog: What is Agile really about https://www.scrum.org/resources/blog/so-what-

agile-really-about
[4] Waterfall Model: https://www.tutorialspoint.com/sdlc/sdlc waterfall model.htm
[5] Iterative Model: https://www.tutorialspoint.com/sdlc/sdlc iterative model.htm
[6] Spiral Model: https://www.tutorialspoint.com/sdlc/sdlc spiral model.htm
[7] V-Model: https://www.tutorialspoint.com/sdlc/sdlc v model.htm
[8] Agile Model: https://www.tutorialspoint.com/sdlc/sdlc agile model.htm
25
2
People who are more than casually interested
in computers should have at least some idea
of what the underlying hardware is like. Oth-
erwise the programs they write will be pretty
weird.
Donald Knuth
Agile Hardware Development

The agile hardware development processes uses the principles of the agile software
development (see section 1.3 on page 17) to enable a more flexible and responsive
approach to creating innovative and life-saving technologies. These processes are based
on collaboration, adaptability and customer focus.
2.1. Same but Different1

The top 3 differences in hardware vs. software development are
Procurement Lead Time While software teams have a relatively short “compile” step
that is part of the design-build-test cycle, hardware teams have a relatively long “procure”
step. Reducing the length of the procure steps is a key initiative in Lean New Product
Development (NPD) today, but we are not, and will not be, anywhere near being able
to procure parts and build assemblies in the few minutes it takes to compile software.
From the first day of a new project to its last minute changes, lead time is ever-present
and highly influential. This simple fact changes what we do and how we do it.
Component Cost Software development is almost entirely a labor cost. It’s not difficult
or expensive to give everyone full access to the latest and greatest version of the software
so they can test it. In hardware development, however, it costs a lot to give everyone who
needs it access to the latest and greatest hardware, and it takes longer to deliver those
units. Like lead time, component cost changes what we should be doing for maximum
profit.
Non-homogenous Work While software teams are made up of several different skill
sets, such as marketing, design, a few different engineering disciplines, and quality, hard-
ware teams are typically made up of these and many more. In addition to the software
that is increasingly present in new hardware products, there are often molded compo-
nents, optics, sheet metal, castings, cabling, piping, circuitry, assembly, and packaging
skills needed by different people who must stay in sync during product development.
There are other additional skills needed in hardware development, such as research
1
Chapter credits: https://www.playbookhq.co/blog/agile-hardware-development
26
2.2. Agile Values Applied
scientists, supply chain, manufacturing, receiving/inspection, and field service, that are
not typically involved in a software project. The list goes on.
The complexity of communication channels and keeping everyone in sync on such a
necessarily large team, as well as component lead time and cost, changes what we do in
hardware product development.
2.2. Agile Values Applied2

Individuals and interactions vs. processes and tools As the size of the team and
the diversity of skills increase, the number of interactions increases exponentially.
The greater the number of interactions, the greater the complexity of the system, and
the more likely it is that there will be communication breakdowns or that individuals will
follow a far worse than "best practice" approach to something. As a result, development
is slower and company profits are reduced through the Cost of Delay.
To combat this increasing complexity, it is even more important to have a good frame-
work of processes and tools that keep everyone on the same page, in sync, using best
practices, and communicating well.
However, most processes and tools are not very good at replacing people and interac-
tions, so face-to-face, real-time communication is often still the fastest way to get things
done. This is often true in hardware development as well. However, there are more
people affected by each piece of information and a wider variety of backgrounds involved
in the interaction. Some of these people will not be able to be present and interact when
the change is made, and/or some words make less sense to people in other disciplines,
so a good communication framework (processes and tools) is the best alternative. The
key is to minimize the effort.
Working Software Vs. Comprehensive Documentation It has been the dream of

mechanical designers for over 20 years to never have to create a drawing. We are still
dreaming. We are slowly moving away from it, but we are still at a point where many
companies rely on drawings to procure parts. This is an example of documentation that
we cannot yet eliminate, although we will continue to work toward it.
In addition, as mentioned above, with the larger, multi-disciplinary teams required
for hardware development, we can’t effectively be in the same room at the same time,
so documentation of decisions and changes is typically more valuable. The list goes
on to include documentation of the design, the factors (knowledge) that drive our
design decisions, and the results of those decisions. While I know it is often difficult
to look at a piece of software code and understand what the person who wrote it was
thinking, it is often more difficult to look at a mechanical or electrical design and gain
much understanding and knowledge. Knowledge is often better transferred through
documentation when face-to-face transfer isn’t possible.
2
Chapter credits: https://www.playbookhq.co/blog/agile-values
27
2. Agile Hardware Development
In addition, as we will discuss in more detail in later posts, one of the main challenges
of applying Agile to hardware product development is the difficulty of breaking down
design tasks into small, distinct, manageable chunks. A good practice to address this
issue is to capture what we actually do on a daily basis, so that we can use that to guide
the breakdown and estimates the next time we do something similar. Again, minimizing
the effort is key, which is where a tool like Playbook can really help.
Since we are considering how these values apply to hardware product development,
we can replace "working software" with "working product". A working hardware product
is certainly of very high value, despite the increased value of good documentation. Again,
we just have to be careful to keep the documentation effort to a minimum so that we
can focus on making our product work. This can be minutes a day if we have the right
framework and tools.
Customer Collaboration Vs. Contract Negotiation This is a comparison that ap-

plies most directly to hardware development. Despite our best efforts, we still cannot
predict the future or read our customers’ minds very well in either software or hardware.
Therefore, customer feedback is essential to ensure our profitability.
However, the cost of customer collaboration is much higher in hardware development,
largely due to the cost of parts. Good feedback often requires expensive parts so that
customers can see, feel, and use our product, or at least a subset of the product. Our
ability to get feedback is limited by the number of test units we can afford to purchase
and the time we have to move them from one customer to another. While the latest
software can easily be made available to many people around the world at the same time,
hardware is not as portable-at least not until we invent teleportation.
Just as valuable as minimizing the effort required for documentation is minimizing the
effort, delay, and cost of working with customers. While we continue to make progress
in improving customer collaboration, the benefit/cost ratio (value) of collaboration is
lower because the cost is higher. The benefits still outweigh the costs until you reach the
point of diminishing returns, which comes sooner with hardware.
Responding To Change Vs. Following A Plan Changing hardware is more expensive

than changing software. The cost and procurement time required to obtain new parts
causes delays and involves scrap or rework costs. As a result, changing plans is often
costly. One of the most important "plans" in hardware development is the "build plan"-
how many units of each product iteration we will build and test. Careful coordination
of this affects our ability to get customer feedback, find problems, and accelerate our
project and profits. Late changes to the number of units we will build often cause delays
and increase costs.
One part of the plan that is particularly costly to change is the launch date. If our
marketing and sales departments, our suppliers, and our production facilities do not
know when to be ready to ramp up, costly delays will occur. Confidence in our launch
date is more important in hardware development. Therefore, at least one part of the plan
28
2.3. Principles
(the end date) must be sufficiently accurate early on (so that it can be tracked without
significant cost).
2.3. Principles3
2.3.1. General Aspects
Software and hardware product development teams share important characteristics. It
took us decades to realize this, but now it seems pretty obvious. Those attributes are:
1. We are not perfect
2. We cannot predict the future with 100% accuracy and,
3. We cannot think of everything, no matter how hard we try.
The Cost Of Change In Hardware Development We can calculate the profit we

expect from each new product, each new release of the product, and each change to the
product. For our business to be sustainable and profitable, changes must, on average,
return more than they cost.
Every change costs us something. In software, the cost of change includes the labor to
make the change, and if testing and releases aren’t automated yet, it costs time (money)
to test and release that change. We often have to update training documents or videos,
write release notes, and various other activities with each change.
For hardware, changes involve the same costs as software, plus additional costs. For
example, for most changes in our supply chain, there are labor and material costs associ-
ated with changing manufacturing or inspection processes and tooling. For example,
tooling for a new plastic injection molding part often costs many thousands of dollars. It
can take weeks of sales of units made with these parts to pay for that tool alone. Then
there are tooling for other parts, assembly tooling, inspection tooling, and test tooling.
As another example, in medical device design, many changes add hours, days, weeks,
or years of additional time and delay due to required regulatory approvals. Most electrical
devices must be re-certified by UL, CE, or another regulatory body for some changes.
The list of additional costs goes on.
Hardware products are inherently highly integrated Another major cause of higher
change costs is the highly integrated nature of hardware products. With hardware
products, changes typically affect multiple (often many) components and processes.
Software teams have long understood and built modular architectures that limit the
ripple effect of each change. Object-oriented programming was born in the 50s.
Hardware teams have not solved the modularity problem because of the forces that
push us away from increased modularity. Increasing modularity typically increases
3
Chapter credits: https://www.playbookhq.co/blog/applying-agile-principles-4-12-hardware-
developmentand https://www.playbookhq.co/blog/making-hardware-development-more-agile
29
our costs of goods sold (COGS) and degrades system performance, including the of-
ten important weight and size of our product. These forces counteract the benefits of
modularization and push us back toward more costly changes.
The higher our change costs, the longer it takes to recoup those costs, and the longer
the payback period of each new change and release. This alone is enough to lengthen
optimal release cycles.
Component COGS typically consumes 30% of product revenue COGS of hardware

products typically consume at least 30% of our product revenue (not including the capital
costs of tooling). In most companies, this percentage is much higher. With increased
COGS comes decreased profits from each unit. We have to sell more units in order to
pay for the cost of development and change. This further lengthens the payback period
and our optimal release cycle.
This is evidenced in our calculations for Cost of Delay for a new product release. When
material costs are high and margins are low, the Cost of Delay is low. Because we make
less profit on each unit, delaying that profit costs us less. As the value of releasing a
new product early gets smaller and smaller, continuous delivery becomes less and less
valuable.
2.3.2. Our Highest Priority Is To Satisfy The Customer Through Early And
Continuous Delivery Of Valuable Product
In other words, our priority is to focus first and foremost on the early and continuous
delivery of valuable products to our customers. And here is the problem with this
principle, the continuous part, which is not necessarily optimal for most hardware
products.
Even among the most advanced product development companies, continuous delivery
is rarely the most profitable option. For example, in the four years that the iPad has been
on the market, there have only been five different models, even though the operating
system has been updated more frequently. Toyota releases new models every year.
The fact that it is usually not profitable to continuously release hardware products
to customers does not prevent us from developing the product more continuously (in
smaller batches) and so reducing the project risk and changing the meaning of delivering
value. We learn to de-batch our development processes. We de-batch our learning
into more frequent and extensive testing, and we de-batch our phase gates into more
individualized major milestones. The more continuous (de-batched) our risk burn-down,
the faster the product development system will flow, and the earlier and more profitable
our eventual product release will be. So we can rephrase the first principle to:
Our highest priority is to satisfy the consumer through early and continuous delivery
of value.
30
2.3. Principles
2.3.3. Welcome changing requirements, even late in development. Agile

processes harness change for the customer’s competitive
advantage.
The impact of change in hardware development will beside the cost aspect cause a delay
of the lauch of the product. However, hardware teams are more often stuck between a
rock and a hard place. The rock is the cost of making the change, and the hard place is the
cost of not making the change. Very often, both costs are high unless we are deliberately
careful and prepared early in the development process.
How do we do better?
• Find places to build more modularity into our products - places that have a low
impact on our performance and are cost effective.
• Identify early on which requirements we expect to change and which components

are likely to be affected by those changes.
• Combine the first two keys and deliberately find ways to build modularity into
those high-risk places where we can expect change.
• Avoid change by having a good, healthy project risk management process and use
it to learn earlier.
And, of course, we need our economic models to help us quickly and effectively determine
which changes are worth the cost of change and which are not.
This leads us to the rephrased principle:
Enable and welcome profitable changing requirements, even late in development.

Agile processes harness change for the customer’s competitive advantage.
2.3.4. A Working Product

A "working product" is a physical object that internal and external customers can use
well enough to be happy to pay for it or to give good feedback about it. The working
product is reflected on in the two principles: “Deliver working product frequently, from
a couple of weeks to a couple of months, with a preference to the shorter timescale.” and
“Working product is the primary measure of progress.”
When we talk about development we often mean the “Design-Build-Test Cycles” which
means different things in hard- and software development.
Working product is the primary measure of progress. Small lot sizes help us move
through the design-build-test (DBT) cycle relatively quickly. That is, we reduce our DBT
lot size by reducing the number of requirements we try to satisfy before we test. This
allows us to test sooner and keeps the undiscovered bug queue (unknown unknowns)
smaller. This helps us diagnose and fix problems faster and with more focus. More
31
Software Hardware
User Story Detailed Design Requirements
Mockup CAD Model
Function Piece Part (designed, not yet physical)
Line of Code Single Part or Process Specification (e.g., a dimension)
Table 2.1.: Design–Build–Test Cycles Terms in hard- and software development
importantly, we learn earlier where our unknown unknowns are, which ultimately helps
us complete our projects much faster.
In addition, we see that there are two types of bugs, those that we can find by testing
our product internally and those that can only be found by the customer in a customer
use test. These times also need to be taken into account.
Deliver working product frequently, from a couple of weeks to a couple of months,

with a preference to the shorter timescale. This principle is difficult for us, because
we do not have a short "compile and install" step like in software development, but rather
a long "procure and assemble" step. We can only shorten this step to a limited extent.
We have the investment in upfront design is higher and affects more than a single part of
the product described by few requirements.
However, we can take advantage of these principles by getting early feedback and thus
finding errors in our assumptions (requirements) earlier.
These principles do not need to be rewritten, they are still valid in their original form.
2.3.5. Learning Fast

The principles “Business people and engineers must work together daily throughout
the project.”, “The most efficient and effective method of conveying information to and
within a team is face-to-face conversation.”, and “The best architectures, requirements,
and designs emerge from self-organizing teams.” all speak to learning quickly from each
other.
As we’ve discussed before, product development is all about information. We spend
every day generating, translating, and transferring information. The key to success is
to do this as quickly as possible by eliminating unnecessary delays and not wasting
valuable time on useless information.
In fact, these principles are often not enough for many hardware development teams.
Remember from the #3 big difference between hardware and software development
(see 2.1 on page 26) is the larger number of people and the variety of disciplines and
knowledge involved in hardware. Daily stand-up meetings are not so easy with a team
of thirty or more people from marketing, two to ten engineering disciplines, quality,
manufacturing, scientists, regulatory, purchasing, and more. It helps to break into smaller
stand–ups (or do a cascaded Daily Standup), but whenever we separate people who
need to share information, the information flows more slowly.
32
2.3. Principles
This is where hardware teams need to complement agile principles with an effective
information framework. With this framework, we can more quickly transfer, even gener-
ate and translate information among a large group of people with very different ways of
thinking.
2.3.6. Theory of Constraints

The Theory of Constraints established that people are the constraints in our product
development systems. We can think of them as little pipelines through which we often
try to push too much work, except that these pipelines have thoughts, feelings, desires,
families, and lives to live.
When we push too much work in, we clog these critical pipelines. Among other big
problems this causes, eventually some of the pipelines just go away. We have to replace
them with a smaller pipeline that won’t be as productive as the one they replaced until
they get up to speed on everything. If people are not engaged and motivated, the flow
becomes even more restricted because they lack the focus and desire to get the job done.
Losing some availability of an already congested resource has a huge impact on
throughput. It is like an accident blocking a lane on the highway during rush hour.
It causes huge delays, which is a real profit killer because most projects have a high cost
of delay.
Instead, we replace push with pull. We make sure everyone on the team has what they
need, including maximum availability for the most important tasks. We make our goals
and expectations of them clear and realistic. We make the risks, work, and progress
highly visible, and we trust them to get the job done. In return, we get happy people and
great throughput.
These aspects are reflect on in the principles: “Build projects around motivated indi-
viduals. Give them the environment and support they need, and trust them to get the job
done.” and Agile processes promote sustainable development. The sponsors, engineers,
and users should be able to maintain a constant pace indefinitely.”.
2.3.7. Technical Simplicity

“Continuous attention to technical excellence and good design enhances agility.” and
“Simplicity—the art of maximizing the amount of work not done—is essential.” we will
cover in this section. The later principle is always a bit confusion so in more common
terms it means minimize the work you do in order to achieve your goal.
Reading this principle a little further, I see that “value–maximizing” work is really
what we should be focusing on, not just "value–added" work. If we can get more value
per hour of work on Task B than we can on Task A - Task A is not value–maximizing
work. We should focus our limited time on value-maximizing work. For example, the
documentation and processes mentioned in the first Agile Value are value-adding, but not
value–maximizing. We often maximize our profits and ROI—even in the long run—by
building the next new feature instead.
33
Both of these principles are certainly as applicable to hardware product development

as they are to software.
Albert Einstein is credited with saying; “Everything should be made as simple as
possible, but not simpler.” But where is the line between not simple enough and too
simple? It is wide and fuzzy and it takes skill to see it and to really maximize the work
not done.
These skills include the ability to analyze our system and make these tradeoffs math-
ematically. They include knowing how to identify, manage, and burn down our work
and our project risks most quickly, which includes knowing how to determine the best
(fastest) ways to get good (reliable) information.
Speed is a critical factor in these tradeoffs. "Fastest" comes partly from less work, yes,
but there is more to it when component lead times are involved. The ROI of some work
is a function of the amount of work involved (effort) and the time it takes to realize the
value of that work (duration). The ROI of any work is also a function of the delay to
other activities caused by the work and the cost of that delay. But more importantly, it
is a function of the value we realize. To determine value-maximizing work, we must
consider all of these factors.
Ultimately, we can strike this balance by maximizing our risk burn rate (confidence in
future profits gained per day). By focusing on this, we maximize our value creation rate,
which maximizes our overall profit production rate.
2.3.8. Agile Principle: At regular intervals, the team reflects on how to

become more effective, then tunes and adjusts its behavior
accordingly.
We simply can’t get better unless we look at the past and learn (change) from it. The
scientific method in its many forms (Plan-Do-Check-Act, Build-Measure-Learn, LAMDA,
A3 sheets, Design-Build-Test, and more) is very effective, but only if there is an experiment
(Check/Measure/Test) or some other form of reflection on what we have done.
Our products, development processes, and ultimately our profits will only improve
if we act on that reflection and actually tweak or adjust what we are doing. Profits will
grow faster if we do this more often because we shrink the batch size of information and
therefore realize value sooner.
Truly effective software and hardware teams do this at a daily cadence with daily
stand-up meetings. In 15 minutes, we reflect on the previous day and adjust our project’s
short-term plans, priorities, tasks, and resources to be more effective. We do it on a
weekly or bi-weekly cadence in team meetings to adjust our mid- and long-term project
plans. And we do it bi-weekly, monthly, quarterly, and/or annually to adjust and improve
our processes to be more effective.
34
2.4. Benefits of Agile Approaches
2.4. Benefits of Agile Approaches

Flexibility Agile methodologies enable rapid response to changing clinical needs, reg-
ulatory requirements and technological advances, ensuring that devices remain relevant
and effective.
Faster time to market Iterative development enables faster iterations, resulting in

faster product releases. This is critical for introducing innovative medical technologies
when they are needed most..
Reduced risk Continuous testing and iteration identify problems early in the devel-
opment process, reducing the risk of major setbacks later on.
Stakeholder engagement Regular feedback from healthcare professionals, patients

and regulators ensures that the device meets their needs and complies with regulations.
2.5. Challenges and Solutions

Regulatory compliance Stringent regulations in the medical industry can conflict
with the agile need for flexibility. One solution is to integrate regulatory experts into the
agile team and build regulatory compliance testing into every iteration.
Safety considerations Medical devices must meet high safety standards. Agile teams
must prioritize safety throughout development, building risk assessments and validation
processes into every iteration.
2.6. Examples
• Portable ultrasound devices, that offer real-time imaging for point-of-care diag-
nostics. Iterative testing with healthcare professionals allowed rapid refinement of
image quality and usability.
• An implantable cardiac monitors that track heart rhythms. Regular collaboration

with cardiologists ensured that the devices met clinical accuracy standards.
2.7. Bibliography
[GC14] Eliyahu M. Goldrat and Jeff Cox. The Goal: A Process of Ongoing Improvement.
The North River Press Publishing Coperation, 2014.
[HMO15] Jez Humble, Joanne Molesky, and Barry O’Reilly. Lean Enterprise — How
High Performance Organizations Innovate at Scale. O’Reilly, 2015.
35
[Kee23] Michael Keer. Agile Hardware Product Realization: Mastering the Journey from
Concept to Scale. self-published, 2023.
[Lef11] Dean Leffingwel. Agile Software Requirements - Lean Requirements Practices

for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
[Rei09] Donald Reinertsen. The Principles of Product Development Flow. Celeritas

Publishing, 2009.
[Rie17] Eric Ries. The Lean Startup: How Today’s Entrepreneurs Use Continuous Inno-
vation to Create Radically Successful Businesses. Currency, 2017.
[SS20] Jeff Sutherland and Ken Schwaber. The Scrum Guide. scrum.org, 2020.
Additonal Reading
[1] Eric Graves: Lean Agile Project Management Blog
(https://www.playbookhq.co/blog/author/eric-graves)
36
3
Semantic diffusion occurs when you have a
word that is coined a person or group, often
with a pretty good definition, but then gets
spread through the wider community in a way
that weakens that definition. This weakening
risks losing the definition entirely - and with it
Agile Practices1
any usefulness to the term.
Martin Fowler
In software development, agile practices (sometimes written "Agile")2 include require-

ments discovery and solutions improvement through the collaborative effort of self-
organizing and cross-functional teams with their customer(s)/end user(s)[Col10],3
Popularized in the 2001 Manifesto for Agile Software Development[B+ ], these values
and principles were derived from and underpin a broad range of software development
frameworks, including Scrum and Kanban.4 [Lar04]
While there is much anecdotal evidence that adopting agile practices and values im-
proves the effectiveness of software professionals, teams and organizations, the empirical
evidence is mixed and hard to find. [DD08, KPA18, LX10]
1
see also https://en.wikipedia.org/wiki/Agile software development#Agile software development methods
2
Rally (2010). "Agile With a Capital ”A” Vs. agile With a Lowercase ”a”". Archived from the original on
5 January 2016. Retrieved 9 September 2015
3
What is Agile Software Development?". Agile Alliance. 8 June 2013. Retrieved 4 April 2015.
4
Which is better – Kanban or Scrum?, 4 March 2016
37
3. Agile Practices
Velocity tracking Ken Rubin

Practice Main contributor(s)
Acceptance test–driven development (ATDD) Gojko Adzic
Agile modeling Scott Ambler
Agile testing Janet Gregory; Lisa Crispin
Product and Sprint Backlog Ken Schwaber
Behavior–driven development (BDD) Dan North, Liz Keogh
Continuous integration (CI) Grady Booch
Cross–functional team
Daily stand–up / Daily Scrum James O. Coplien
Domain–driven design (DDD) Eric Evans
Iterative and incremental development (IID) Kent Beck
Pair programming Kent Beck
Planning poker James Grenning, Mike Cohn
Refactoring Martin Fowler
Reflection Alistair Cockburn
Scrum events Jeff Sutherland, Ken Schwaber
Specification by Example Gojko Adzic
Story–driven modeling Albert Zündorf
Test–driven development (TDD) Kent Beck
Timeboxing Kent Beck
User story Alistair Cockburn
Table 3.2.: Overview Agile Practices
3.1. Cross–functional Teams
How much do you know about agile teams? Tick the sub-sentences that
correctly complete the sentence.
1. An Agile team consists of (many different functions , only devel-

opers ).
2. An Agile team works (on tasks predefined by the project manage-

ment , along a backlog ).
3. Team members of an Agile team are more likely to work (collabora-

tively , individually ).
4. An Agile team has (more , less ) than 10 members.
38
3.1. Cross–functional Teams
3.1.1. Team Members

Agile teams follow the idea of cross-functional set up, i.e., the Agile team has all the Reading to page 39
knowledge, expertise, and skills to work on a list of work packages. The team organizes
itself and its work, which gives the team more flexibility to meet the needs of the customer
and the business. In addition, cross-functionality means that the team either has domain
experts themselves (e.g., UX, security, testers, developers, business people) or the team
members are willing to acquire the needed skills for unknown topics. Cross-functional
teams are critical to the success of a project because they can deliver in the shortest time,
with the highest quality and without having to consider external dependencies.
“XP can work with any size [of teams] . . . The values and principles behind XP are
applicable at any scale. Practices need to be supplemented and modified when many
people are involved.” [Bec04] (Kindle edition, position 369)5 “Twelve is the number
of people who can comfortably interact with each other in a day. With more than 150
people6 on a team, you can no longer recognize the faces of everyone on your team.
Across both of these thresholds, it is harder to maintain trust, and trust is necessary
for collaboration. For larger projects, finding ways to fracture the problem, so it can be
solved by a team of teams allows XP to scale.” [Bec04] (Kindle edition, position 907)
Agile teams follow esteems and principles (see People, Processes & Projects) described
in the Manifesto of Agile Software Development. Team members are accountable to share
their knowledge with all other team members, which helps create collective responsibility
for product delivery and the development process.
Agile teams welcome mistakes and errors. They see them as learning opportunities.
Team members are self-reflective at all times, both personally and as a team.
3.1.2. Product Owner

The Product Owner (PO) is a backport from Scrum into agile development to help the
Agile team find direction for product development. Other role titles that basically fulfil
the same function are e.g. Customer on Site (XP), Product Champion, Product Director
or Value Manager.
3.1.3. Team Coach

The Team Coach is an optional responsibility in or for the team. Shexp7 coaches the team
in self-organization & creation of valuable products. She collaborates with other roles
and functions that have connections to the team and helps break down barriers in the
organization.
N.B.:In eXtreme Programming we call the role project manager and in Scrum, Scrum
Master.
5
A Roman Legion (military unit of the Roman army - 4500 men) was divided into cohorts (480 men),
centuria (80 men), contubernium (8 men + 1 mule).
6
From: The Tipping Point by Malcolm Gladwell; N.B.: The number 150 is called Dunbar’s Number
7
In the agile literature the Team Coach is always female.
39
3. Agile Practices

For your team find a Team Coach, who will be responsible for the time-
boxes and keeping the team together, and a Product Owner who will be
responsible to help the team in understanding of the current task. All
other team members will form the developers. Please do the exercise in
your breakout teams.

In what ways does this information change previous perceptions you’ve held about the responsibil-
ities in Agile Development? How do you think you might use this information?
3.2. Approaches for Environment & Practices

How much do you know about Agile practices? Tick the sub-sentences
that correctly complete the sentence.
1. We sequence (any work item , only work items that contain prod-
uct changes ).
2. We write the tasks in such a way that they describe (the value ,
the solution ).
3. We estimate jobs (relatively , absolutely ).
4. We work in (value–based , time–based ) manner.
5. We reflect (whenever necessary , regularly at set times ).

Reading to Page 22 Here are some ideas taken from XP8 (or The Scrum That Actually Works) that give an
idea of setups and practices:
8
All citations taken from [Bec04] (chap. 7, position 866–1153)
40
3.2.1. Environment
Sitting Together We communicate with all our senses. For distributed teams, this is
more of a prediction “the more face time you have, the more humane and productive
the project” will be.
Whole Team We have included all the people in a team who have the skills and
perspectives to complete the project successfully.
Informative Workspace “An interested observer should be able to walk into the team
space and get a general idea of how the project is going, in fifteen seconds. He should be
able to get more information about real or potential problems by looking more closely.”
and have big visible charts e.g., to chart the resolution of an issue.
Energized Work “Work only as many hours as you can be productive and only as
many hours as you can sustain. Burning yourself out unproductively today and spoiling
the next two days’ work isn’t good for you or the team.” “Software development is a
game of insight, and insight comes to the prepared, rested, relaxed mind.”
Pairing and Personal Space It means that there is enough space to work together
and enough space to retreat, e.g. to reflect.
3.2.2. Practices
Pair Programming “[It] is a dialog between two people simultaneously programming
(analyzing, designing, and testing) and trying to program better” (see Pair Program-
ming9 @Agile Alliance for details). It support being able to compensate absences of
experts.
Stories “Plan using units of customer-visible functionality. ‘Handle five times the traffic
with the same response time.’ or ‘Provide a two-click way for users to dial frequently
used numbers.’. As soon as the story is written, try to estimate the development effort
necessary to implement it.” Stories have a short name and a longer description, we put
everything at an index card. While discussing them, we can add constraints to the card.
(The User Story will be discussed in more detail in chapter 11.)
Weekly Cycle A good idea is to plan the work for a week. At the beginning of each
week we review progress so far and talk about current and expected progress. We invite
the client to choose the stories that are worth a week’s work and divide them into tasks
that are signed off and appreciated by the team members. We create automated tests
9
https://www.agilealliance.org/glossary/pairing
41
3. Agile Practices
that are successful at the end of the week. (see \gls{bdd}10 aka. Acceptance Test-Driven-
Development, see [Sma14] and [Adz11] e.g., implemented with JBehave11 ). At the end
of the week we will have a deployable software and celebrate our success.
Quarterly Cycle We plan bigger goals e.g., closing bottlenecks that are out of the
team’s control, themes (which are subsequently filled with a series of stories worth a
quarter of the work). The outcome of this planning is to focus on the big picture of our
project/product. This is a good time to hold a reflection workshop.
Slack “In any plan, include some minor task that can be dropped if you get behind.
. . . it is important in an atmosphere of distrust and broken promises to meet your com-
mitments.” Slack can mean that 20% of the capacity of a developer could be used by
programmer-chosen tasks. (see Atlassian’s 20% Time Experiment12 )
Ten–Minutes Build “Automatically build the whole system and run all the tests in ten
minutes. A build that takes longer will be used much less often, missing the opportunity
for feedback. A shorter build doesn’t give you time to drink your coffee.” Additional
benefit: It is a stress reliever at crunch time.
Continuous Integration “Team programming isn’t a divide and conquer problem. It is

a divide, conquer, and integrate problem.” If we don’t integrate often, we have to spend
a lot of money fixing buggy builds by looking for the change set where the bug occurred.
Test–First Programming Simply put, write a failing test before changing the code.
Then write just enough code for the test to succeed. These tests support the ten-minute
build.
Incremental Design “Invest in the design of the system every day. Strive to make the
design of the system an excellent fit for the needs of the system that day.” “If small, safe
steps are how to design, the next question is where in the system to improve the design.”
Additionally, we find more practices coming from other sources:
Ruthless Prioritization (Planning) We have a collection of sequenced items, we call

it the backlog. The backlog is accessible to everyone because we want to pick up the
most important problem to be solved. A one-time order will not help us to be successful.
We have to maintain the backlog constantly, we often do grooming (inspect & adapt) of
the backlog, at best in regular meetings. The backlog and the grooming help to create
transparency about the changes in the product as well as the changes in the market.
10
https://www.agilealliance.org/glossary/bdd/
11
https://jbehave.org/
12
https://www.atlassian.com/blog/2008/03/10/20 time experiment
42
Design (UX/Interaction) To have consistency in the usage of the products somebody

is needed who translates the mental models13 of the users into the product, otherwise
people will not find their way of thinking/working with the product.
Estimation For sizing of the User Stories (11 on page 117) we will use relative sizing,
since humans are better in relative comparison than in absolute estimation14 .
For estimation, we will use the Fibonacci sequence15 (0, 1, 1, 2, 3, 5, 8, 13, 21, . . . ). The
recommendation is to find the small work package (which is then called reference story
or work package) and give it a 3 (or 5)16 . Now estimate every other work package in
relation to this.
Bugs Well, bugs get handled like any other work package, but additionally they will
get “kano-ed”17 (e.g., now, next, never). Now means, it is an incident, and has to be
fix immediately otherwise the system will no longer work. Next means, it will be fixed
during the upcoming cycle and never stands for delete it.
Iterations An iteration is the time box in which we do all the work for the product. An
iteration has always a clear focus, is sustainable, and is planned. It will be measured on
its outcome as well as on its performance to achieve this outcome. It contains as much
work as it is needed to fulfill the goal and achieve the outcome.
Specu
la
te
Learn
te
ra
bo
C o ll a
Figure 3.2.1.: Adaptive Development Life Cycle
13
A mental model is an explanation of someone’s thought process about how something works in the
real world. It is a representation of the surrounding world, the relationships between its various parts and a
person’s intuitive perception about their own acts and their consequences. Mental models can help shape
behavior and set an approach to solving problems (similar to a personal algorithm) and doing tasks.
14
See https://www.agilealliance.org/glossary/relative-estimation
15
https://en.wikipedia.org/wiki/Fibonacci number
16
To have enough breathing room for all other work packages, smaller and bigger than this one
17
https://en.wikipedia.org/wiki/Kano model
43
3. Agile Practices
We do not record the team’s performance (how much work is done in the iteration) in
a performance report for management, but rather we will use this information for future
planning.
What is a good iteration length? Well, there is no all-time-right answer. There is an
idea how to find the optimal iteration length. If the market has a fast pace of changing
the time box has to be small, since we might have to change our mind along with the
market change frequency. At best, content changes happen at the edges of an iteration,
but not within it.18 Let’s have an example: If we would work in a 3-week iteration, in
a year we could change our mind (and get feedback) 17 times (52 weeks/3 weeks), if
we do 2-week iterations: 26 times and 1-week iterations: 52 times. If we work in a slow
changing market, we could go with longer iterations (up to 1 month, but not longer than
that)19 .
It is a good practice to ship as often as possible, at best every iteration. This will have
impact on our development process and will help us to reduce the cost of building and
shipping our product.
Daily Stand–up The Daily Stand–up is a daily meeting. It is kept very short (< 10
min). The focus is on the work the team is currently working on. It should help team
members finish the work and hold each other accountable. In the best case, the meeting is
in front of the board with all the tasks. We look at the work in progress and have people
announce what they are working on and where they are stuck.20 It is good practice for
everyone to speak up. [Coc06](p. 357)
Measurement We continuously measure our progress and focus on empirical and

value-based measurements. Since we measure along the value chain, we do not need
a defined baseline. The value-based measurement can be done e.g., by having a burn-
down chart21 or a Cumulative Flow Diagram(G.2 on page 164) in form of an information
radiator at the team wall. The focus lies on information saturation instead of reporting.
N.B.: All these metrics are proxy measurements, as ultimately only the value of the
functioning product is relevant.
For the prediction of processing times, we need small work sections and a team that
works on few tasks in parallel. The speed of the team must be stable. A prediction should
only be made for a few weeks in advance.
Reflection Workshop The reflection workshop (aka.retrospectives) is a pause from

work, “for an hour periodically, certainly after each delivery, to reflect on the product,
18
That is not fully correct. Content changes in the iteration are possible but only exchange work items
of the same size with ones from the backlog is possible. Exchanging content might add effort because of
additional Backlog Refinement session.
19
See the principles “Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.”. Together with “Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.”
20
N.B. In Scrum we will talk about the progress towards our committed Sprint Goal.
21
Can be done with Azure DevOps almost automatically.
44
3.3. In Detail
progress, and process.” [Coc06]22 . We could split the reflection workshop in two steps:
review and retrospective. The book “Agile Retrospectives” [DL06] contains a lot of nice
ideas how to run a retrospective. .
Definition of Done The Definition of Done is a living collection of checks, which are
needed to ensure the quality of our finished User Stories and features. By fulfilling the
checklist we state that the delivery is ready for the customer’s use.
“The team agrees on, and displays prominently somewhere in the team room, a list of
criteria which must be met before a product increment ‘often a user story’ is considered
‘done’. Failure to meet these criteria at the end of a sprint normally implies that the work
should not be counted toward that sprint’s velocity.”23 [SC+ 19] ¶82
3.3. In Detail
3.3.1. Pair Programming24
Styles25
Driver and Navigator These classic pair programming role definitions can be applied
in one way or another to many of the approaches to pairing.
The driver is the person at the wheel, that is, the keyboard. She is focused on accom-
plishing the tiny goal at hand, ignoring larger issues for the moment. A driver should
always talk through what she is doing as she does it.
The navigator is in the observer position while the driver is typing. She reviews the
code on the fly, gives directions, and shares thoughts. The navigator also keeps an eye
on larger issues, bugs, and notes potential next steps or roadblocks.
The idea of this role division is to have two different perspectives on the code. The
driver’s thinking is supposed to be more tactical, thinking about the details, the lines
of code at hand. The navigator can think more strategically in their observer role. They
have the big picture in mind.
A common flow goes like this:
• Start with a reasonably well-defined task
• Agree on one small goal at a time. This can be defined by a unit test, or by a commit
message, or written on a sticky note.
• Switch keyboards and roles regularly. Shared active participation keeps the energy
level up, and we learn and understand things better.
22
See also [Coc97]
23
Since the quote comes from a Scrum book, we find the word Sprint here, which is a Scrum term for
a time span of maximum 30 days. Definition of “Definition of Done”, first appearance of a “Definition of
Done” - 2002
24
Taken from: https://martinfowler.com/articles/on-pair-programming.html
25
Selection, more can be found under: https://martinfowler.com/articles/on-pair-programming.html
45
3. Agile Practices
• As navigator, avoid the "tactical" mode of thinking, leave the details of coding to
the driver-your job is to step back and complement your pair’s more tactical mode
with medium-term thinking. Park next steps, potential roadblocks, and ideas on
sticky notes and discuss them after the small goal is achieved, so as not to interrupt
the driver’s flow.
Strong-Style Pairing This is a particularly useful technique for knowledge transfer,

described in much more detail by Llewellyn Falco26 .
The rule: "For an idea to get from your head to the computer, it MUST go through
someone else’s hands. In this style, the navigator is usually the person much more
experienced with the setup or task at hand, while the driver is a novice (with the language,
the tool, the codebase, ...). The experienced person usually stays in the navigator role
and guides the novice.
An important aspect of this is the idea that the dTest-Driven Development (TDD)
for Complex Systems Introductionriver trusts the navigator completely and should be
"comfortable with incomplete understanding". Questions of "why" and challenges to
the solution should be discussed after the implementation session. In an environment
where one person is a complete novice, this can make the pairing much more effective.
While this technique borders on micromanagement, it can be a useful onboarding tool
to emphasize active learning by doing over passive learning by watching. This style is
great for initial knowledge transfer, but shouldn’t be overused. Remember, the goal is
to be able to easily switch roles and move out of micromanagement mode after a while.
This will be a sign that the knowledge transfer has worked.
Time management In addition to the general styles for pairing, there are other little
tools and techniques that make it easier.
The Pomodoro Technique is one such tool. It is a time management technique that
breaks work into chunks of time - traditionally 25 minutes - separated by short breaks.
The technique can be applied to almost any of the pairing approaches described and will
keep you focused. Pairing can be an exhausting practice, so it is helpful to be reminded
to take breaks and switch keyboards periodically.
Here is an example of using the Pomodoro technique in practice.
• Decide what you want to work on next
• Set a timer for 25 minutes, using one of the many Pomodoro browser extensions,
or even a real kitchen timer shaped like a tomato
• Work without interruption
• Stop working when the timer goes off—start with short breaks (5–10 minutes)
• After 3 or 4 of these “pomodoros”, take a longer break (15–30 minutes)
26
https://llewellynfalco.blogspot.com/2014/06/llewellyns-strong-style-pairing.html
46
3.3. In Detail
• Use the short breaks to really take a break and recharge, get some water or coffee,
use the restroom, get some fresh air. Avoid using these short breaks for other work,
such as writing emails.
Pair Rotations Rotating pairs means that after working together for some time, one
half of the pair leaves the story while the other person brings someone new on board to
continue. The person who stays is often called the “anchor” of the story.
One category of reasons to rotate is logistics. Your pairing partner might be sick or
on vacation. Or one of you may be working remotely for a day, and the work requires a
physical presence on site, such as a hardware setup.
Another group of reasons to rotate is to mix things up. Either the two of you have
been working together for a while and are showing signs of “cabin fever” from spending
too much time together. Or you’re working on something very tedious and energy
draining - a rotation will give one of you a break, and a new person can bring some fresh
perspectives and energy.
Finally, the most commonly cited reason for pair rotations is to avoid knowledge silos,
increase collective code ownership, and get a little more code review on the road. Pairing
itself helps with these things, but rotations can further increase the average number of
eyes on each line of code that goes into production.
As for the ideal frequency of rotations, opinions vary. Some people believe that
rotations every 2–3 days are crucial to ensure sufficient knowledge distribution and
quality. However, every rotation comes at a cost. There’s the time it takes to bring a
new person up to speed, and the cost of a context switch for one of the two. Without a
constant anchor of continuity, there is an increased risk that tacit knowledge about the
problem and solution space will be lost, triggering rework. For more junior developers,
it’s sometimes more beneficial to stay on something longer, so they have enough time to
immerse themselves in a topic and give new knowledge time to take hold.
Think about the tradeoff between these costs and benefits. For example, let’s say you
already have a high quality of knowledge sharing, with team “shows and tells”, readable
code, and good documentation. In this case, insisting on frequent rotations may only
marginally improve your collective code ownership, while creating a lot of friction and
overhead.
Plan the Day Pairing requires a certain amount of scheduling and calendar coordina-
tion. If you don’t take the time to acknowledge and accommodate this, it will come back
to haunt you later in the day.
Start the day with a calendar check—agree with your pairing partner on how many
hours you will be pairing, and see if you need to schedule meetings or time to work on
other things outside of the pairing task. If it turns out that one of you will need to work
alone for a while, make sure you are prepared to continue without the other person, for
example, by not using that person’s computer to code.
If you have meetings or other commitments during the day, make sure you have a
reminder that you will be aware of them, especially if you are working on your pairing
47
3. Agile Practices
partner’s computer. If your team pairs by default, consider agreeing on regular “core
coding hours” for everyone. This will make scheduling much easier.
Physical Setup Pair programming means that you have to work very closely together
in the physical space of a shared desk. This is very different from having your own table
to spread out on. Being so close requires a certain level of respect and attention to each
other’s needs. So it pays to spend some time figuring out a setup that is comfortable for
both of you.
• Make sure you both have enough space, and clear out the desk if necessary.
• Is there enough room for both chairs in front of the desk? Move trash cans and
backpacks out of the way.
• Will you be using two keyboards or one? Same with the mouse, one or two? There’s
no hard and fast rule that always works, so we recommend that you try what works
best for you in each situation. Some of the factors that come into play are hygiene,
how well you can share keyboard time, or how much space you have available.
• Do you have an external monitor, or maybe even two? If not, you might consider
setting up some kind of screen sharing, like a remote pairing. In this setup, each of
you would use your own laptop keyboards.
• Check with your partner to see if he or she has any special preferences or needs
(e.g., larger font size, higher contrast, ...).
• If you have an unusual keyboard/IDE setup, check with your partner to see if they
are comfortable with it. See if there is an easy mechanism to switch your settings
back to a more standard configuration for these situations.
It’s helpful if your team can agree on a default setup so that you don’t have to discuss
these things over and over again.
For remote setup see On Pair Programming by Martin Fowler27 .
Things to Avoid The different approaches and techniques help you to have a better
pairing experience. Here are a some common pitfalls to avoid:
Drifting apart When you are pairing, avoid reading email or using your phone.
These distractions can be disrespectful to your pair, and they take you away from the
task you are working on. If you really need to check something, be transparent about
what you are doing and why. Make sure everyone has enough time to read their email
by taking adequate breaks and setting aside some individual time each day.
27
https://martinfowler.com/articles/on-pair-programming.html
48
3.3. In Detail
Micro-Management Mode Watch out for micromanagement mode: It doesn’t leave

room for the other person to think and is a frustrating experience, if someone keeps
giving you instructions like:
• “Now type ’System, dot, print, . . . ’”
• “Now we need to create a new class called . . . ”
• “Press command shift O . . . ”
Impatience Use the “5 second rule”: If the navigator sees the dTest-Driven Devel-
opment (TDD) for Complex Systems Introductionriver doing something "wrong" and
wants to comment, wait at least 5 seconds before saying anything - the driver may already
have it in mind, then you are unnecessarily interrupting his flow.
As a navigator, don’t immediately point out an error or upcoming obstacle: Wait a bit
for the driver to correct it, or write a sticky note to remember it later. If you intervene
immediately, you may disrupt the driver’s thought process.
Keyboard Hogging Watch out for keyboard hogging: Are you controlling it all the
time and not letting your pairing partner type as well?
This can be a very annoying experience for your pair, and may cause them to have
difficulty focusing because of limited "active participation". Try one of the approaches
described above to make sure you switch keyboards frequently.
Pairing 8 Hours per Day Teams that are really committed to making pair program-
ming work sometimes end up pairing for 8 hours a day. In our experience, this is not
sustainable. First, it is just too exhausting. And second, it doesn’t even work in practice
because there are so many other things you do besides coding, like checking email, hav-
ing 1:1s, going to meetings, researching/learning. So keep that in mind when planning
your day and don’t assume that it will be 100% coding together.
3.3.2. Test-Driven Development28

Test–driven development (TDD) is a software development process that relies on con-
verting software requirements into test cases before the software is fully developed, and
tracking all software development by repeatedly testing the software against all test cases.
This is in contrast to developing software first and creating test cases later.
Test-driven development cycle The following sequence is based on the book Test-
Driven Development by Example29 :
28
https://en.wikipedia.org/wiki/Test-driven development
29
From: [Bec02]
49
3. Agile Practices
1. Add a test
Adding a new feature starts with writing a test that passes if the feature’s specifica-
tions are met. The developer can discover these specifications by asking about use
cases and user stories. A key benefit of test–driven development is that it forces
the developer to focus on requirements before writing code. This is in contrast to
the common practice of writing unit tests after the code is written.
2. Run all tests.

The new test should fail for the expected reasons. This shows that new code is
indeed required for the desired feature. It validates that the test harness works
correctly. It rules out the possibility that the new test is buggy and will always
pass.
3. Write the simplest code that passes the new test

Inelegant or hard code is acceptable as long as it passes the test. The code will be
polished anyway in step 5. No code should be added beyond the tested functional-
ity.
4. All tests should now pass

If any fail, the new code must be reworked until they pass. This ensures that the
new code meets the test requirements and does not break existing functionality.
5. Refactor as needed, using tests after each refactor to ensure that functionality is
preserved
Refactor the code for readability and maintainability. In particular, hard-coded test
data should be removed. Running the test suite after each refactoring helps ensure
that no existing functionality is broken.
Refactoring examples:
• Move code to where it most logically belongs
• Remove duplicate code
• Make names self-documenting
• Break methods into smaller pieces
• Rearrange inheritance hierarchies
6. Repeat
The above cycle is repeated for each new piece of functionality. Tests should be
small and incremental, and commits should be frequent. That way, if new code
fails some tests, the programmer can simply undo or revert, rather than debug
excessively. When using external libraries, it is important not to write tests so small
that they effectively test only the library itself [NV04], unless there is reason to
believe that the library is buggy or not feature-rich enough to meet all the needs of
the software being developed.
50
3.3. In Detail
[ test ]
p u b l i c void add21and21equals42 ()
{
Calculator calculator = Calculator ();
var answer = c a l c u l a t o r . Add( 2 1 , 21 ) ;
A s s e r t . Equal ( 4 2 , answer ) ;
}
Test −Driven Development (TDD) f o r Complex Systems I n t r o d u c t i o n
class Calculator
{
p u b l i c i n t Add{ i n t l h s , i n t rh s )
{
return 42;
}
Anti-patterns
Dependence to previous test run Having test cases depend on system state ma-
nipulated from previously executed test cases (i.e., you should always start a unit test
from a known and pre-configured state).
Dependencies between test cases A test suite where test cases are dependent
upon each other is brittle and complex. Execution order should not be presumed. Basic
refactoring of the initial test cases or structure of the UUT causes a spiral of increasingly
pervasive impacts in associated tests.
Interdependent tests These can cause cascading false negatives. A failure in an

early test case breaks a later test case even if no actual fault exists in the UUT, increasing
defect analysis and debug efforts.
Testing precise execution, behavior, timing or performance
51
3. Agile Practices
Building “all-knowing oracles” An oracle that inspects more than necessary is

more expensive and brittle over time. This very common error is dangerous because it
causes a subtle but pervasive time sink across the complex project.30
Testing implementation details
Slow running tests
3.4. Bibliography
[Adz11] Gojko Adzic. Specification by Example: How Successful Teams Deliver the Right
Software. Manning Publication, 2011.
2021-02-09.
[Bec02] Kent Beck. Test Driven Development: By Example. Addison-Wesley Profes-

sional, 2002.
[Bec04] Kent Beck. Extreme Programming Explained — Embrace Change. Addison-

Wesley, 2004.
[Coc97] Alistair Cockburn. Surviving Object-Oriented Projects. Addison-Wesley

Professional, 1997.

[Col10] Ken W. Collier. Agile Analytics: A Value-Driven Approach to Business Intelli-

gence and Data Warehousing. Pearson Education, 2010.
[DD08] Tore Dyba and Torgeir Dingsoyr. Empirical studies of agile software development:
A systematic review, pages 833–859. Information and Software Technology.
2008.
[DL06] Esther Derby and Diana Larsen. Agile Retrospectives: Making Good Teams
Great! Pragmatic Bookshelf, 2006.
[KPA18] I. Kroll, J.and Richardson, R. Prikladnicki, and J. L. Audy. Empirical evidence

in follow the Sun software development: A systematic mapping study, page 30–44.
Number 93 in Information and Software Technology. 2018.
[Lar04] Craig Larman. Agile and Iterative Development: A Manager’s Guide, page 27.
30
Test-Driven Development (TDD) for Complex Systems Introduction on YouTube by Pathfinder Solu-
tions: https://www.youtube.com/watch?v=0BWSms3J40Y
52
3.4. Bibliography
[LX10] Gwanhoo Lee and Weidong Xia. Toward Agile: An Integrated Analysis of
Quantitative and Qualitative Field Data on Software Development Agility, pages
87–114. MIS Quarterly. 2010.
[NV04] JW Newkirk and AA Vorontsov. Test-Driven Development in Microsoft .NET.

Microsoft Press, 2004.
[SC+ 19] Jeff Sutherland, James O. Coplien, et al. A Scrum Book. Pragmatic Bookshelf,
2019.
[Sma14] John F. Smart. BDD in Action: Behavior-driven development for the whole software
lifecycle. Manning Publication, 2014.
Additional Reading
Extreme Programming: http://www.extremeprogramming.org
53
Part II.
Agile Frameworks
55
4
I’m often amazed that a process I pioneered in
1993 to aid software development has proven
itself as universal applicable.
Jeff Sutherland
Scrum
Along with the course it is highly recommended to read the book “Scrum—The Art of
Doing Twice the Work in Half the Time” [Sut14] and the following section of “A Scrum
Book” [SC+ 19]1 :
• Conway’s Law ¶4
• Scrum Team ¶7
• Product Owner ¶11
• Scrum Master ¶19
• Sprint ¶46
• Sprint Planning ¶24
• Sprint Review ¶35
• Sprint Retrospective ¶36
• Sprint Goal ¶71
• Sprint Backlog ¶72 (Item ¶73)
• Product Backlog ¶54 (Item ¶55)
And for scaled agility:
• Scrum of Scrums ¶34
• MetaScrum ¶37
If you are looking for companies using the Scrum framework you will find a lot of
examples in “The Scrum Fieldbook” [Sut19] by J.J. Sutherland and what can be observed
by using the Scrum Framework.
Scrum is described in The 2020 Scrum Guide™. It is provide as PDF or can be read
online2 .
1
Also available online: http://www.scrumbook.org/
2
https://scrumguides.org.
56
4.1. History
4.1. History3
1986 Hirotaka Takeuchi and Ikujiro Nonaka publish their article “The New New Product
Development Game” in Harvard Business Review4 . The article describes a rugby
approach where “the product development process emerges from the constant
interaction of a hand-picked, multidisciplinary team whose members work together
from start to finish.” This article is often cited as the inspiration for the Scrum
framework.
1993 Jeff Sutherland invents Scrum as a process at Easel Corporation5
1995 Ken Schwaber and Jeff Sutherland co-present Scrum at the OOPSLA Conference6
4.2. Scrum Definition and Theory

How much do you know about the theory behind Scrum? Check off the
phrases that correctly complete the sentence.
1. (A technique used by the US Air Force / A method of industrial

work ) inspired the development of the Scrum framework.
2. The Scrum Guide describes (practices /events ).
3. Scrum is a (cyclical , linear ) process.
4. Scrum requires a reflection at the end of a (time-box , project ).
5. Scrum depends on (people , methods ).
The following text is taken from The Scrum Guide 2020™:
Purpose of the Scrum Guide7 We developed Scrum in the early 1990s. We Reading to Page 60
wrote the first version of the Scrum Guide in 2010 to help people worldwide under-
stand Scrum. We have evolved the Guide since then through small, functional updates.
Together, we stand behind it.
The Scrum Guide contains the definition of Scrum. Each element of the framework
serves a specific purpose that is essential to the overall value and results realized with
Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following
the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even
rendering it useless.
3
See also [SS20]
4
https://hbr.org/1986/01/the-new-new-product-development-game
5
http://www.jeffsutherland.com/scrum/FirstScrum2004.pdf
6
https://www.scrum.org/resources/scrum-development-process
7
https://scrumguides.org/scrum-guide.html#purpose-of-the-scrum-guide
57
4. Scrum
We follow the growing use of Scrum within an ever-growing complex world. We are
humbled to see Scrum being adopted in many domains holding essentially complex
work, beyond software product development where Scrum has its roots. As Scrum’s use
spreads, developers, researchers, analysts, scientists, and other specialists do the work.
We use the word “developers” in Scrum not to exclude, but to simplify. If you get value
from Scrum, consider yourself included.
As Scrum is being used, patterns, processes, and insights that fit the Scrum framework
as described in this document, may be found, applied and devised. Their description is
beyond the purpose of the Scrum Guide because they are context sensitive and differ
widely between Scrum uses. Such tactics for using within the Scrum framework vary
widely and are described elsewhere.
Scrum Definition8 Scrum is a lightweight framework that helps people, teams,

and organizations generate value through adaptive solutions for complex problems.
[SS20]
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
1. A Product Owner orders the work for a complex problem in a Product Backlog.
2. The Scrum Team turns a selection of work into an Increment of value during a
Sprint.
3. The Scrum Team and its stakeholders review the results and adjust them for the
next Sprint.
4. Repeat
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help
to achieve goals and create value. The Scrum framework is purposefully incomplete,
only defining the parts required to implement Scrum theory. Scrum is built upon by the
collective intelligence of the people using it. Rather than provide people with detailed
instructions, the rules of Scrum guide their relationships and interactions.
Various processes, techniques, and methods can be employed within the framework.
Scrum wraps around existing practices or renders them unnecessary. Scrum makes
visible the relative efficacy of current management, environment, and work techniques,
so that improvements can be made.
The Scrum Framework is a managing framework for setting an environment to develop in an

agile way, hence it needs additional practices e.g., from eXtreme Programming (XP) [Bec04](3)
to be applied successfully. The Scrum Master is the expert for this framework ([SC+ 19] ¶19).
The Product Owner is one of the three accountabilities in the framework. ([SC+ 19] ¶11 & ¶12)
8
From: https://scrumguides.org/scrum-guide.html#scrum-definition
58
4.2. Scrum Definition and Theory
Scrum Theory9 Scrum is founded on empiricism and lean thinking (see figure:
The Deming Cycle). Empiricism asserts that knowledge comes from experience and
making decisions based on what is observed. Lean thinking reduces waste and focuses
on the essentials.
PL
T A
AC
N
CH
EC
O
D
K
Figure 4.2.1.: The Deming Cycle
Scrum employs an iterative, incremental approach to optimize predictability and to

control risk (see figure 4.2.1). Scrum engages groups of people who collectively have all
the skills and expertise to do the work and share or acquire such skills as needed.
Scrum combines four formal events for inspection and adaptation within a containing
event, the Sprint. These events work because they implement the empirical Scrum pillars
of transparency, inspection, and adaptation.
Transpa
re
nc
A d a p ti o n
io y n
ct
Inspe
Figure 4.2.2.: Cycle of Empiricism
9
https://www.scrumguides.org/scrum-guide.html#scrum-theory
59
4. Scrum
Transparency
The emerging process and work must be visible to both, those who do the work and
those who receive the work. In Scrum, important decisions are based on the perceived
state of the three formal artifacts (Product Backlog, Sprint Backlog and Increment, see
page 73 et sqq.). Artifacts that lack transparency can lead to decisions that reduce value
and increase risk.
Transparency enables inspection. Inspection without transparency is misleading and

wasteful.
Inspection
The Scrum artifacts and the progress toward agreed goals (see Product and Sprint
Goal at page 73 et sqq.) must be inspected frequently and diligently to detect potentially
undesirable variances or problems. To help with inspection, Scrum provides cadence in
the form of its five events.
Inspection enables adaptation. Inspection without adaptation is considered pointless.

Scrum events are designed to provoke change.
Adaptation
If any aspects of a process deviate outside acceptable limits or if the resulting product is
unacceptable, the process being applied or the materials being produced must be adjusted.
The adjustment must be made as soon as possible to minimize further deviation.
Adaptation becomes more difficult when the people involved are not empowered or
self-managing. A Scrum Team is expected to adapt the moment it learns anything new
through inspection.

What are your notes, what would you like to discuss?
Please discuss what does transparency, inspect and adapt mean for your
daily work as and take notes in your workbook. Please do the exercise
in your breakout teams.
Notes:
60
4.3. Scrum Values

How could you use your new knowledge about empiricism?
4.3. Scrum Values10

The Scrum Values were added to the Scrum Guide in:
A 1986?
B 1995?
C 2017?
D 2020?
Successful use of Scrum depends on people becoming more proficient in living five Reading to
values: Page 63
Commitment, Focus, Openness, Respect, and Courage.
The Scrum Team commits to achieving its goals and to supporting each other. Their
primary focus is on the work of the Sprint to make the best possible progress toward these
goals. The Scrum Team and its stakeholders are open about the work and the challenges.
Scrum Team members respect each other to be capable, independent people, and are
respected as such by the people with whom they work. The Scrum Team members have
the courage to do the right thing, to work on tough problems.
These values give direction to the Scrum Team with regard to their work, actions, and
behavior. The decisions that are made, the steps taken, and the way Scrum is used should
reinforce these values, not diminish or undermine them. The Scrum Team members learn
and explore the values as they work with the Scrum events and artifacts. When these
values are embodied by the Scrum Team and the people they work with, the empirical
Scrum pillars of transparency, inspection, and adaptation come to life building trust.
[SS20]
To make it even more clear which behavior should be shown in accordance with the values:
10
https://www.scrumguides.org/scrum-guide.html#scrum-values
61
4. Scrum
• Commitment means; “We will do our absolute best to do so.” [Sut19]
• Focus means; Do not deviate from the Sprint Goal by doing even tiny little things (“this I
can do, it will not take long”) outside the commitment. These will derail your focus.
• Openness means; stick to your problems and address them, because as Taiichi Ohno said:
“Having no problems is the worst problem of all”. Openness helps us to make them visible
and known to all, both in the team and in the organization. Psychological safety is not
created by keeping silent and hiding problems. It is created by people talking about problems,
even if it means having to endure a tough discussion.
• Respect means; taking all people in the organization as they are, with all their weaknesses
and strengths, their misunderstandings and mistakes, their resistance and willingness.
Treat all people with the respect with which you would like to be respected. Help overcome
the culture of blame. Remember Kerth’s primer: “Regardless of what we discover, we
understand and truly believe that everyone did the best job they could, given what they
knew at the time, their skills, and abilities, the resources available, and the situation at
hand.”11 Let’s replace the 5-Whos by the 5-Whys.
• “Courage involves the ability to take action and carry on even when we are afraid. No
matter how big or consequential a given step may be, that step cannot be said to involve
courage if we are not afraid to take it. It may show how smart we are, how energetic, how
focused; but not how brave. It is action in the face of fear that demonstrates courage.”[KL09]
Commitment
Focus
Openness
Respect
Courage
Figure 4.3.1.: Scrum Value Pyramid

11
Norm Kerth, Project Retrospectives: A Handbook for Team Review
62
4.3. Scrum Values
If we were to stack these values, courage would be the foundation, followed by respect,
openness, and focus, with commitment at the top. Demanding commitment without
living up to the other four values and exhibiting the appropriate behavior for them
creates an unstable structure.
1-2-4-Alla : What would a lived value look like? How will team members
behave, communicate (2 dimensions)? Use the notes box.
1. Choose a value and describe the two dimensions. (1 min)
2. Get together in pairs. Discuss your results from round 1. (2 min)
3. Pair up and discuss your findings from round 2. (4 min)
4. We present the results from all groups in the class room. (5 min)
Notes:
a
https://liberatingstructures.de/liberating-structures-menue/1-2-4-all/
Where could you use the Scrum Values?
63
4. Scrum
4.4. Scrum Team

Internet Hunt: Find a description of the daily routine of a Scrum Master, Product
Owner or Developer in a Scrum Team on the Internet. Take notes, prepare a
short (2 minutes) presentation for the class, have a speaker ready to give the
presentation. Please do the exercise in your breakout teams.
Notes:
Scrum Team12
Reading to Page 66 The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum
Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum
Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused
on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary
to create value each Sprint. They are self-managing, meaning they internally decide who
does what, when, and how.
The Scrum Team is small enough to remain nimble and large enough to complete
significant work within a Sprint, typically 10 or fewer people. In general, we have found
that smaller teams communicate better and are more productive. If Scrum Teams become
too large, they should consider reorganizing into multiple cohesive Scrum Teams, each
focused on the same product. Therefore, they should share the same Product Goal,
Product Backlog, and Product Owner.
The Scrum Team is responsible for all product-related activities from stakeholder
collaboration, verification, maintenance, operation, experimentation, research and devel-
opment, and anything else that might be required. They are structured and empowered
by the organization to manage their own work. Working in Sprints at a sustainable pace
improves the Scrum Team’s focus and consistency.
The entire Scrum Team is accountable for creating a valuable, useful Increment ev-
ery Sprint. Scrum defines three specific accountabilities within the Scrum Team: the
Developers, the Product Owner, and the Scrum Master.
12
https://www.scrumguides.org/scrum-guide.html#scrum-team
64
4.4. Scrum Team
Developers Developers are the people in the Scrum Team that are committed to creat-
ing any aspect of a usable Increment (4.6 on page 75) each Sprint (4.5 on page 68).
The specific skills needed by the Developers are often broad and will vary with the
domain of work. However, the Developers are always accountable for:
• Creating a plan for the Sprint, the Sprint Backlog (4.6 on page 74);
• Instilling quality by adhering to a Definition of Done(4.6 on page 75);
• Adapting their plan each day toward the Sprint Goal(4.6 on page 75); and,
• Holding each other accountable as professionals.
Product Owner The Product Owner is accountable for maximizing the value of the
product resulting from the work of the Scrum Team. How this is done may vary widely
across organizations, Scrum Teams, and individuals.
The Product Owner is accountable for effective Product Backlog management, which
includes:
• Developing and explicitly communicating the Product Goal(4.6 on page 74);
• Creating and clearly communicating Product Backlog items(4.6 on page 74);
• Ordering Product Backlog items; and,
• Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others.
Regardless, the Product Owner remains accountable.
For Product Owners to succeed, the entire organization must respect their decisions.
These decisions are visible in the content and ordering of the Product Backlog, and
through the inspectable Increment at the Sprint Review.
The Product Owner is one person, not a committee. The Product Owner may represent
the needs of many stakeholders in the Product Backlog. Those wanting to change the
Product Backlog can do so by trying to convince the Product Owner.
Scrum Master The Scrum Master is accountable for establishing Scrum as defined
in the Scrum Guide. They do this by helping everyone understand Scrum theory and
practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by
enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
The Scrum Master serves the Scrum Team in several ways, including:
• Coaching the team members in self-management and cross-functionality;
65
4. Scrum
• Helping the Scrum Team focus on creating high-value Increments that meet the
Definition of Done;
• Causing the removal of impediments to the Scrum Team’s progress; and,
• Ensuring that all Scrum events take place and are positive, productive, and kept
within the time-box.
The Scrum Master serves the Product Owner in several ways, including:
• Helping find techniques for effective definition of the Product Goal and the man-
agement of the Product Backlog;
• Helping the Scrum Team understand the need for clear and concise Product Backlog
items;
• Helping establish empirical product planning for a complex environment; and,
• Facilitating stakeholder collaboration as requested or needed.

The Scrum Master serves the organization in several ways, including:
• Leading, training, and coaching the organization in its Scrum adoption;
• Planning and advising Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact an empirical approach

for complex work; and,
• Removing barriers between stakeholders and Scrum Teams.

Create a list of tasks that each accountability needs to complete and com-
pare it to your current task list and the task list of the other accountabilities
on your team.a Please do the exercise in your breakout teams.
Notes:
a
https://www.scrumguides.org/scrum-guide.html#scrum-team
66
4.5. Scrum Events

How many responsibilities do the Product Owner, the Scrum Master and the developers have?
Why do you think it makes sense to have a full-time Scrum Master?
4.5. Scrum Events13

How much do you know about Scrum events? Choose the phrases that
complete the sentence correctly.
1. Scrum has (3 ,5 ,8 ) events.
2. The Sprint is used (as container for all activities towards , for
developing ) the product.
3. In the Sprint Planning (assigns , explains ) the Product Owner

the work to other team members.
4. The Scrum Team commits the Sprint Backlog , the Sprint Goal .
5. In the Daily Scrum the Scrum Teams (inspects , reports ) the

progress towards the Sprint Goal.
6. The Scrum Team uses the Sprint Review to (determine future adap-
tations , approve the set plan ).
7. The Product Owner (takes part , does not take part ) in the
Sprint Retrospective.
The Sprintitself, is a container for all other events. Each event in Scrum is a formal Reading to Page 72
opportunity to inspect and adapt Scrum artifacts. These events are specifically designed
to enable the transparency required. Failure to operate any events as prescribed results
in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity
and to minimize the need for meetings not defined in Scrum.
Optimally, all events are held at the same time and place to reduce complexity.
13
https://www.scrumguides.org/scrum-guide.html#scrum-events
67
4. Scrum
The Sprint Sprints are the heartbeat of Scrum, where ideas are turned into value.
They are fixed length events of one month or less to create consistency. A new Sprint
starts immediately after the conclusion of the previous Sprint.
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily
Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
During the Sprint:
• No changes are made that would endanger the Sprint Goal;
• Quality does not decrease;
• The Product Backlog is refined as needed; and,
• Scope may be clarified and renegotiated with the Product Owner as more is learned.
Sprints enable predictability by ensuring inspection and adaptation of progress toward

a Product Goal at least every calendar month. When a Sprint’s horizon is too long the
Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter
Sprints can be employed to generate more learning cycles and limit risk of cost and effort
to a smaller time frame. Each Sprint may be considered a short project.
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative
flows. While proven useful, these do not replace the importance of empiricism. In
complex environments, what will happen is unknown. Only what has already happened
may be used for forward-looking decision-making.
A Sprint could be canceled if the Sprint Goal becomes obsolete. Only the Product
Owner has the authority to cancel the Sprint. [SS20]
Sprint Planning Sprint Planning initiates the Sprint by laying out the work to be
performed for the Sprint. This resulting plan is created by the collaborative work of the
entire Scrum Team.
The Product Owner ensures that attendees are prepared to discuss the most important
Product Backlog items and how they map to the Product Goal. The Scrum Team may
invite other people to attend Sprint Planning to provide advice.
Sprint Planning addresses the following topics:
Topic One: Why is this Sprint valuable?
The Product Owner proposes how the product could increase its value and utility
in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal
that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be
finalized prior to the end of Sprint Planning.
Topic Two: What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select items from the
Product Backlog to include in the current Sprint. The Scrum Team may refine these items
during this process, which increases understanding and confidence.
68
4.5. Scrum Events
Selecting how much can be completed within a Sprint may be challenging. However,
the more the Developers know about their past performance, their upcoming capacity,
and their Definition of Done, the more confident they will be in their Sprint forecasts.
Topic Three: How will the chosen work get done?
For each selected Product Backlog item, the Developers plan the work necessary to
create an Increment that meets the Definition of Done. This is often done by decomposing
Product Backlog items into smaller work items of one day or less. How this is done is at
the sole discretion of the Developers. No one else tells them how to turn Product Backlog
items into Increments of value.
The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for
delivering them are together referred to as the Sprint Backlog.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
For shorter Sprints, the event is usually shorter. [SS20]
In Sprint Planning, developers use the velocity14 from previous Sprints to pull work packages
from the Product Backlog into the Sprint Backlog. Now, developers begin to look at implementation
details and, if desired, create tasks and estimate them in hours. Then developers can calculate
the available capacity (total developer time minus vacation, holidays, meetings, and other non-
development activities) in hours and compare it to the total planned effort of the tasks. If this is
too high, the excess work is moved back to the product backlog. Developers can now agree on a
sprint goal with the PO and commit to it. It is important to remind the developers to commit only
to this goal, and not to the individual work packages (as these can change in each Daily Scrum).
Sprint Planning is prepared in Backlog Refinements.
Sprint Planning should not be used for detailed solution discussions, that is a task for the
Sprint. It should not be used to divide the work among the team members, as this would contradict
the pull principle. We do not consider the fair workload of all team members who cannot contribute
directly to this sprint, they use the time to participate in another work package.
The Scrum Master makes sure that the Sprint Planning takes place, he makes sure that the
developers don’t get bogged down and that the discussions don’t get too detailed. The Scrum
Master has a more passive role, being available for explanations and helping to set the Sprint Goal
at the end of the planning. Sprint Planning is done by the developers.
Daily Scrum The purpose of the Daily Scrum is to inspect progress toward the Sprint
Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce
complexity, it is held at the same time and place every working day of the Sprint. If the
Product Owner or Scrum Master are actively working on items in the Sprint Backlog,
they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as
their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable
14
Number of Story Points of completed work packages in the last Sprint.
69
4. Scrum
plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-
making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan.
They often meet throughout the day for more detailed discussions about adapting or
re-planning the rest of the Sprint’s work. [SS20]
We check daily to see how well we are progressing toward our Sprint Goal. The work packages
and task cards are just a reminder of the content of the work. The bottom line is to answer the
question of what do as a team in the next 24 hours to get closer to or reach our our sprint goal.
Without a sprint goal, this will be difficult15 , because the team is missing the common goal.
In addition, obstacles should be addressed and if possible solved or at least mitigated within the
next 24 hours. Whereby only address obstacles that prevent the sprint goal from being from being
achieved. All others end up in the Retrospective.
In Daily Scrum we want to achieve a good information saturation, because this speeds up
decision making enormously, since everyone has the same information. When using a task board,
the status should be updated during the event, but it should not become the only the sole purpose
of the Daily Scrum. Technical discussions are rather undesirable, since the only purpose is to plan
for the next 24 hours. These can be done after the Daily Scrum.
The Daily Scrum is run by the developer, the Scrum Master makes sure it happens but does not
but does not moderate and has a more passive role. role. The PO has a passive role, participates,
and answers questions about the Sprint Goal and work packages.
Sprint Review The purpose of the Sprint Review is to inspect the outcome of the
Sprint and determine future adaptations. The Scrum Team presents the results of their
work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished
in the Sprint and what has changed in their environment. Based on this information,
attendees collaborate on what to do next. The Product Backlog may also be adjusted to
meet new opportunities. The Sprint Review is a working session and the Scrum Team
should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is time-boxed to a
maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually
shorter. [SS20]
Sprint Retrospective The purpose of the Sprint Retrospective is to plan ways to

increase quality and effectiveness.
15
As a Scrum Master you should take notes if the Daily Scrum is not considered to be valuable, because
then ONE Sprint Goal could be missing for the whole team. for the whole team.
70
4.5. Scrum Events
The Scrum Team inspects how the last Sprint went in regard to individuals, interactions,
processes, tools, and their Definition of Done. Inspected elements often vary with the
domain of work. Assumptions that led them astray are identified and their origins
explored. The Scrum Team discusses what went well during the Sprint, what problems
it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The
most impactful improvements are addressed as soon as possible. They may even be
added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is time-boxed to a maximum of three
hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. [SS20]
The Sprint Review and Sprint Retrospective are the two parts of the reflection workshop. We
stop our daily work and look at the quality (the what) of the Sprint outcome and the path (the
how) to the Sprint outcome. We do this whether or not we have achieved the Sprint Goal. Based
on the results of these two events, the Product or Sprint Backlog is changed.
Sprint Review
A Sprint Review without stakeholders makes no sense. Stakeholders need to make decisions
that may affect the Product Backlog. Simply moving work packages around is common, but not in
the spirit of the method. We decide for each unfinished work package whether to continue it, split
it, or count it as completed because the value has already been created with the existing subset of
the original plan. The Sprint Review is a great learning opportunity: for the developers, how well
they understood and implemented what the stakeholders and the PO wanted; for the PO and the
stakeholders, what the state of delivery is and how well they were able to express what they wanted.
The developers show the stakeholders and the PO what they have created, and the stakeholders
and the PO, decide what still needs to be done or changed and add it to the backlog. They decide
what can be removed from the backlog.
The following questions are examples the Scrum team needs to answer in order to have a good
sprint review:
• What product are we integrating our increment into, or what is our increment, and who is
consuming it?
• What does the consumer do with our increment?
• What happens on the consumer side if we move the work package?
• How well did we meet our Sprint Goal
• Which acceptance tests16 were met?.

The Scrum Master makes sure that the 17 takes place, but remains in the background during the
event. It is the time for the Scrum Team to celebrate. Stakeholders and PO actively participate
and evaluate the working product presented by the developers. The review should be conducted
16
Acceptance tests are performed by the PO in collaboration with the developers
17
Sprint Review
71
4. Scrum
as PowerPoint-free as possible. It is good practice for the Developers to show something that the
stakeholders and PO can touch, try out, etc.
Always remember Humphrey’s Law: “Basically, people don’t know what they want until they
see what they don’t want. You can get them write down their wishes in documents thousands of
pages long, but until they actually see something that works, they don’t really know what they
want.” [Sut19] Please do not fight Humphrey’s law, it is better to embrace it.
Sprint Retrospective
Even though the Scrum Team, says that we talk about improving the development process every
day, we should take a break from the regular work. During the Sprint Retrospective we should
dig deeper into the root causes of problems during a Sprint Retrospective (up to 3 hours). In
particular, the deferred (non-urgent) obstacles from the Daily Scrum should be looked at in the
Sprint Retrospective.
If the Scrum Team members are only complaining, it would be useful to start writing down the
positive experiences. In the first Sprint Retrospectives is is useful to talk about how to keep the
velocity stable and to focus only on that in the first Sprints.
The Sprint Retrospective should be a ritual and not be skipped (even if the Scrum Team says
there is nothing to reflect on). Regular topics here could be: stabilizing velocity,, limiting parallel
work (Work-in-Progress (WIP)), stakeholder involvement etc.
The Scrum Master makes sure that the Sprint Retrospective takes place. Any member of
the Scrum Team can facilitate. The Product Owner and the Scrum Master participate as team
members when they are not facilitating.

To prepare a Sprint Review half of the group will prepare a presenta-
tion about the Scrum artifacts (4.6 on the next page) and the other half
will prepare a presentation about the events and their duration (4.5 on
page 67).
• Let’s have a Sprint Review about the results of your work.
• Let’s do a Sprint Retrospective. Preparation time: 5 minutes, the

Scrum Master reads through https://retromat.org/en/?id=107-19-
8-63-67and moderates the session.
Notes:
72
4.6. Scrum Artifacts

What would you like to contribute to the facilitation of events in your Scrum team? What are the
elements you are missing in reality for the described event purposes?

The Scrum Guidea describes all 5 Scrum Artifacts and their commitments.
What do you think about these statements?
1. The Increment is the result of (one Sprint , this Sprint and all
former Sprints ).
2. The Sprint Backlog (can , cannot ) be changed during a Sprint.
3. The Product Backlog contains (all , only parts of ) the work to

be done.
4. The Sprint Backlog Items (will be committed , will not be com-

mitted ) by the Scrum Team.
5. The Product Backlog Items are (prioritized , ordered ) by the

PO.
6. A Definition of Done (is necessary , is not necessary ) for a

Scrum Team.
7. The Sprint Goal is (a summary of the Sprint Backlog , an overar-

ching goal for the Sprint ).
a
https://scrumguides.org/scrum-guide.html
Scrum Artifacts18
Scrum’s artifacts represent work or value. They are designed to maximize transparency Reading to Page 75
of key information. Thus, everyone inspecting them has the same basis for adaptation.
18
https://www.scrumguides.org/scrum-guide.html#scrum-artifacts
73
4. Scrum
Each artifact contains a commitment to ensure it provides information that enhances

transparency and focus against which progress can be measured:
• For the Product Backlog it is the Product Goal.
• For the Sprint Backlog it is the Sprint Goal.
• For the Increment it is the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum
Team and their stakeholders.
Product Backlog The Product Backlog is an emergent, ordered list of what is needed
to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are
deemed ready for selection in a Sprint Planning event. They usually acquire this degree
of transparency after refining activities. Product Backlog refinement is the act of breaking
down and further defining Product Backlog items into smaller more precise items. This
is an ongoing activity to add details, such as a description, order, and size. Attributes
often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product
Owner may influence the Developers by helping them understand and select trade-offs.
Commitment: Product Goal The Product Goal describes a future state of the
product which can serve as a target for the Scrum Team to plan against. The Product
Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what”
will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known

stakeholders, well-defined users or customers. A product could be a service,
a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or
abandon) one objective before taking on the next.
Sprint Backlog The Sprint Backlog is composed of the Sprint Goal (why), the set of
Product Backlog items selected for the Sprint (what), as well as an actionable plan for
delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time
picture of the work that the Developers plan to accomplish during the Sprint in order
to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout
the Sprint as more is learned. It should have enough detail that they can inspect their
progress in the Daily Scrum.
74
Commitment: Sprint Goal The Sprint Goal is the single objective for the Sprint.
Although the Sprint Goal is a commitment by the Developers, it provides flexibility in
terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and
focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the
Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in
mind. If the work turns out to be different than they expected, they collaborate with the
Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without
affecting the Sprint Goal.
Increment An Increment is a concrete stepping stone toward the Product Goal. Each
Increment is additive to all prior Increments and thoroughly verified, ensuring that all
Increments work together. In order to provide value, the Increment must be usable.
Multiple Increments may be created within a Sprint. The sum of the Increments is
presented at the Sprint Review thus supporting empiricism. However, an Increment may
be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should
never be considered a gate to releasing value.
Work cannot be considered part of an Increment unless it meets the Definition of Done.
Commitment: Definition of Done The Definition of Done is a formal description of

the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is
born.
The Definition of Done creates transparency by providing everyone a shared under-
standing of what work was completed as part of the Increment. If a Product Backlog
item does not meet the Definition of Done, it cannot be released or even presented at the
Sprint Review. Instead, it returns to the Product Backlog for future consideration.
If the Definition of Done for an increment is part of the standards of the organization,
all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the
Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple
Scrum Teams working together on a product, they must mutually define and comply
with the same Definition of Done.
End Note Scrum is free and offered in this Guide. The Scrum framework, as outlined
herein, is immutable. While implementing only parts of Scrum is possible, the result is
not Scrum. Scrum exists only in its entirety and functions well as a container for other
techniques, methodologies, and practices.
75
4. Scrum

Please do the exercise in your breakout teams.\ What does the Scrum
Guide say about estimation? What would be an example of an Increment
for your workplace?
Notes:
Why is it important to have a Sprint Goal and a Definition of Done?
4.7. When to use Scrum and When it is Better not to use it
Scrum is a managing framework for agile development. It is a perfectly match for the
development of complex software and hardware systems in a complex environment (1
on page 11). It requires a product backlog that is stable for at least some time in the
future so that at least one Sprint can be planned. It requires all the competencies in a
single team to transfer the product backlog items into value.
If you work in a service organization with constantly changing (short term) tasks,
the use of Scrum will fall far short of its potential. In this case it is better to apply other
approaches e.g., Kanban (8 on page 90).
If you handle most of the times non-complex problems (1.2 on page 13) then get help
from experts or have an action plan.
If Scrum is applied to developments that do not meet the prerequisites, this can easily
lead to a so-called Zombie Scrum.
76
4.8. Cargo Cult & Zombie Scrum

A cargo cult is a Melanesian indigenous millenarian belief system in which a group of
people in an indigenous society imitate the behaviors, rituals, and symbols associated
with technologically advanced societies, particularly those characterized by transporta-
tion and material wealth, in the apparent hope of gaining similar benefits.19 The term
“cargo cult” was introduced into the field of anthropology during and after World War
II. Recent scholarship on cargo cults has questioned the appropriateness of the term for
the movements associated with it, with some critics arguing that the term is based on
prejudice and does not accurately convey the nature of the movements to which it refers.
Background20
Cargo cults are marked by a number of common characteristics, including a ‘myth-dream’
that is a synthesis of indigenous and foreign elements, the expectation of help from the
ancestors, charismatic leaders, and lastly, belief in the appearance of an abundance of
goods.[Ott09] The indigenous societies of Melanesia were typically characterized by a
‘big man’ political system in which individuals gained prestige through gift exchanges.
The more wealth a man could distribute, the more people who were in his debt, and the
greater his renown. Those who were unable to reciprocate were identified as ‘rubbish
men’.
Faced, through colonialism, with foreigners with a seemingly unending supply of
goods for exchange, indigenous Melanesians experienced ‘value dominance’. That is,
they were dominated by others in terms of their own (not the foreign) value system, and
exchange with foreigners left them feeling like rubbish men.[Sch76]
Since the modern manufacturing process is unknown to them, members, leaders, and
prophets of the cults maintain that the manufactured goods of the non-native culture
have been created by spiritual means, such as through their deities and ancestors. These
goods are intended for the local indigenous people, but the foreigners have unfairly
gained control of these objects through malice or mistake. Thus, a characteristic feature
of cargo cults is the belief that spiritual agents will, at some future time, give much
valuable cargo and desirable manufactured products to the cult members.[Har74]
Symbols associated with Christianity and modern Western society tend to be incor-
porated into their rituals: For example, the use of cross-shaped grave markers. Notable
examples of cargo cult activity include the setting up of mock airstrips, airports, airplanes,
offices, and dining rooms, as well as the fetishization and attempted construction of
Western goods, such as radios made of coconuts and straw. Believers may stage ‘drills’
and ‘marches’ with sticks for rifles and use military-style insignia and national insignia
painted on their bodies to make them look like soldiers. Thereby treating the activities
of Western military personnel as rituals to be performed for the purpose of attracting
the cargo.”
19
Lindstrom, Lamont (29 March 2018). "Cargo cults". Cambridge Encyclopedia of Anthropology.
doi:10.29164/18cargo.
20
https://en.wikipedia.org/wiki/Cargo cult
77
4. Scrum
Cargo cult can be particularly evident in behaviors that mimic an observed behavior
without recognizing the reasons for that behavior.
For example, we can hold a daily scrum or a regular sprint review without having
even the slightest effect. If we don’t understand why we should exhibit a behavior, we
become zombies and Scrum becomes Zombie Scrum.
Zombie Scrum as a Form of Cargo Cult

Let’s start with some questions:
• How about shipping it fast?
• How about improving continuously?
• How about building what stakeholders need?
• How about self-organization?
• How about valuable outcomes?
• How about management support?
If we only use the Scrum Guide as a checklist to establish the 3-5-3 elements, we can
easily end up in a Cargo Cult, which we will call Zombie Scrum here.
It looks like Scrum, we have all accountabilities (Product Owner, Scrum Master, De-
velopers) in the team. We plan at the beginning of the Sprint, we hold a Daily Scrum,
and have a Sprint Review and Sprint Retrospective at the end of the Sprint. We have a
Product Backlog and a Sprint Backlog, maybe even a Product Goal and a Sprint Goal
(4.6 on page 73). All that and all the problem-solving work is done in short time frames.
Everything is fine? Maybe we see the following signs:
Scrum teams
• do not know the needs of their stakeholders
• are not delivering value at the end of the Sprint
• do not continuously improve the way they work
• do not organize themselves to remove obstacles
What can we do now? Here are some ideas21 :
• For the stakeholders:

– we do the treasure hunt, we look for stakeholders or ask ourselves how far is
the stakeholder separated from us?
21
Taken from:
https://shop.theliberators.com/collections/zombie-scrum/zombie-scrum-experiments#MainContent
78
– we hang up the product purpose in our team room

– we invite the stakeholders to review and actively ask for feedback
– we look over the shoulder of the users (work shadowing)
– we use a form of guerrilla testing22
• For delivering a value proposition

– we show the financial consequences
– we measure lead and cycle time
– we create a Definition of Done
– we create a skill matrix
– we reduce parallel work
• Continuous Improvement
– we create a monthly newsletter with all impediments
– we do root cause analysis and work on root causes23
– we try to improve only 15% for now24
– we focus on the things we want to stop doing25
• Self Organization
– we question processes23
– we identify where we see overlap between team autonomy and collaboration
with the organization26
– we create a list of rules for self-organization27
– we clearly express our requests for help28
– we create meaningful sprint goals by challenging them in planning29
These activities could beat back the zombies, but they could always regroup and find
new gaps, so stay alert.
22
Guerrilla testing is an approach to test your user interfaces by using colleagues in your team who are
not involved in the development of the UI, give them some tasks/scenarios to execute with the UI, and
observe their interactions. This might last only 15 min. https://www.userbrain.com/blog/7-step-guide-
guerrilla-usability-testing-diy-usability-testing-method
23
https://www.liberatingstructures.com/4-wicked-questions/
24
https://www.liberatingstructures.com/7-15-solutions/
25
https://www.liberatingstructures.com/6-making-space-with-triz/
26
https://www.liberatingstructures.com/29-integrated-autonomy/
27
https://www.liberatingstructures.com/14-min-specs/
28
https://www.liberatingstructures.com/16-helping-heuristics/
29
https://www.liberatingstructures.com/12-2510-crowd-sourcing/
79
4. Scrum
4.9. Who can be a Scrum Master?

Scrum Master candidates can come from many areas of an organization (preference
should be given to candidates with experience in staff or project management, or with
good organizational networking), as long as they match and are comfortable with the
following list of characteristics:
• Clear Communication
Scrum Master must be strong communicators. This is completely independent of
how much experience they have with the Scrum framework, how organized they
are in managing projects, or how deep their technical knowledge is. If they cannot
communicate clearly and effectively with their team, they will have a hard time.
• Natural Authority of the Person
Scrum Master are servant leader. So they will not have the usual HR-based au-
thority over the team. Rather than simply issuing decisions, Scrum Master must
be directional leader. Team members follow them out of trust and respect — not
because of an official authority function.
• Openness to Change
An agile development/Scrum environment encourages experimentation. Scrum
Master will suggest new approaches and monitor the result.
• Competence in Dealing with Conflicts
Scrum Master must be able to deal with conflict. In any project, they will naturally
encounter issues that team members cannot agree on. As part of their facilitation,
they need to help resolve these issues so that the team can achieve its Sprint Goal.
Sometimes that means they have to accept being uncomfortable or annoying.30
• Know When (and how) to Push Back
They often have to resist the demands of the PO. It is their job to protect both the
Developers and the quality of the product, i.e., no cutting corners, no last-minute
rushes, and no technical debt. An overzealous PO or non-technical stakeholder
may not always know when they are asking too much of the developers, but Scrum
Master do. So they need to be able to push back in a way that keeps the peace while
still protecting the Developers and the product.
• Knowing when to say something and when to keep the mouth shut
Knowing when is the right time for Scrum Master to say something and when it
is better to let the Scrum Team do, is another challenge. Scrum Master need to
make suggestions to get the Scrum team on track, and should help when the Scrum
Team has reached an impasse. Scrum Master need to give the Scrum Team the
opportunity to solve and fix problems themselves. If they are constantly interfering
with answers and immediately enforcing their advice, you are not giving the team
a chance to learn or, worse, think.
30
This is an unfortunate side effect of dealing with unproductive/dysfunctional attitudes.
80
4.10. Who can be a Product Owner?
• Genuinely Care About the Scrum Team

Scrum Master should be empathetic and genuinely want to care about the people
who make up the Scrum team. Scrum Master need to understand each individual
e.g., how does Ben handle feedback, does Sanjay tend to clash with Jan, and what
motivates Beatrice? Only by taking the time to understand the people in the Scrum
Team, their frictions and their needs the Scrum Master can create a better work
environment.
• The Ability to Appear Clueless

Appearing clueless is not the same as being clueless. Rather, it is about developing
the Scrum team to the point where it can organize itself efficiently, it does not
depend on the Scrum Master’s help for every little thing, and it does not collapse
immediately when the Scrum Master is not available. From the outside, the Scrum
Team looks so good that anyone not in the loop might wonder if the Scrum Master
is needed at all.
• Do not be Afraid of Failing

Failure is not a dirty word in Scrum. It is a stepping stone to success. Scrum Masters
should always take an empirical approach that - instead of fearing failure - tries to
learn from mistakes. This does not mean that Scrum Team should strive for failure
- but they should not fear it either. Scrum masters see every failure as an attempt
for the team to pick itself up again and grow from it.
• Comprehensive Technical Knowledge

Ultimately, a Scrum Master has to understand his craft. Being a good project
manager or a good leader is one thing. Knowing how to understand and manage
the key technical issues in an agile development environment is quite another. It is
fine if Scrum Master are not deep specialists in every area , but they need a good
technical generalist knowledge coupled with a willingness to keep learning.
4.10. Who can be a Product Owner?

A candidate for the responsibility as Product Owner can come from many roles in an
organization as long as he would send an application for this job offering: “We are
looking for a visionary person with excellent business and domain understanding. In
your role, we expect you to be a decisive leader displaying strong negotiation skills with
all stakeholders and people involved. Your passion for the product and your ability to
listen helps you to cope with changes and occasional setback.”[MJ18b]
Fulfilling the tasks of a PO is not a walk in the park. The abbreviation CRACK [TT03]
can support this:
• Collaborative
Work with the Developers and all stakeholders; get to know them. Give them your
mobile number, so they can write or call at any time. Participate during the Sprint
81
4. Scrum
and give feedback when needed, not only at the Sprint Review. You are a member
of the Scrum Team.
• Representative
Develop empathy for stakeholders and clients. Give them a voice when they are not
present. Create and present a product vision that accurately reflects these needs.
Be the Scrum team’s representative to management. Remain steadfast even when
the pressure to deliver is constantly increasing.
• Authorized
You have the authority to make all product-related decisions regarding scope, sched-
ule, and budget. Make the final decision if stakeholders cannot reach agreement,
and trust that you can adjust your path later when you have more information.
• Committed
Product responsibility is a full-time job. Stay committed to the product, the Scrum
Team, the stakeholders and the quality. Stay true to the vision, the values, the
validation and the empirical process. Don’t let anything throw you off track.
• Knowledgeable
Know your field and learn all the time. Work closely with users and professionals
to fill knowledge gaps. Keep up to date with the latest technology trends. Study
the market and the competition to stay ahead.
4.11. Bibliography
[Bec02] Kent Beck. Test Driven Development: By Example. Addison-Wesley Profes-
sional, 2002.

Wesley, 2004.
[Bur69] Kenelm Burridge. New Earth: A study of Millenarian Activities, page 65–72.
Basil Blackwell, 1969.
[Har74] Marvin Harris. Cows, Pigs, Wars, and Witches: The Riddles of Culture, pages
133–152. Random House, 1974.
[KL09] Robert Kegan and Lisa Laskow Lahey. Immunity to Change: How to Overcome
It and Unlock the Potential in Yourself and Your Organization (Leadership for the
Common Good). Harvard Business Review Press, 2009.
[May13] Tobias Mayer. The People’s Scrum. Dymaxicon, 2013.
[MJ18b] Don McGreal and Ralph Jocham. The Professional Product Owner, chapter 9,
page 319. Addison-Wesley, 2018.
82
4.11. Bibliography
[OR20] Stephanie Ockerman and Simon Reindl. Mastering Professional Scrum.

[Ott09] Ton Otto. What happened to Cargo Cults? Material Religions in Melanesia and
the West, page 90. Number 53 (1) in Social Analysis. 2009.
2019.
[Sch76] Theodore Schwartz. The Cargo Cult: A Melanesian Type-Response to Change,

page 174. In DeVos, George A. (ed.). Responses to Change: Society, Culture,
and Personality. Van Nostrand, 1976.
[Sut14] Jeff Sutherland. Scrum — The Art of Doing Twice the Work in Half the Time.
Penguin Random House, 2014.
[Sut19] J. J. Sutherland. The Scrum Fieldbook. Penguin Random House, 2019.
[TT03] Barry Turner and Richard Turner. Balancing Agility and Discipline: A Guide
for the Perplexed. Addison-Wesley, 2003.
[Wat13] Geoff Watts. Scrum Mastery - From Good to Great Servant Leadership. Inspect
& Adapt Ltd, 2013.
Additional Reading
[1] Henrik Kniberg and Mattias Skarin. Kanban and Scrum - Making the Most of Both.
2009
[2] Donald Reinertsen. The Principles of Product Development Flow. Celeritas Publishing.
2009
[3] Ladas Corey. Scrumban and other essays on Kanban System for Lean Software develop-
ment. Modus Cooperandi Press. 2008
[4] Esther Derby and Diana Larsen. Agile Retrospective: Making Good Teams Great!.
Pragmatic Bookshelf. 2006
[5] Kenneth S. Rubin. Essential Scrum: A Practical Guide to the Most Popular Agile
Processes. Addison-Wesley. 2013
[6] Zombie Scrum Checklist: https://scrumteamsurvey.org/
83
4. Scrum
Videos
[1] Empiricism is an Essential Element of Scrum https://youtu.be/q603WTOSYDk
[2] Job Titels and Scrum https://youtu.be/0fW8aoxyVHs
[3] Daily Scrum https://youtu.be/i7 RPceEIYE
[4] Sprint Planning https://youtu.be/syXnhduPxqM
[5] Sprint Review https://youtu.be/Ct uQg9jlp8
[6] Sprint Retrospective https://youtu.be/lJo4OO6hF84
Blog Posts
[1] SCRUM: An extension pattern language for hyperproductive software development
(http://jeffsutherland.org/scrum/scrum plop.pdf), first paper about Scrum by
Mike Beedle
[2] Jeff Patton, Story Mapping https://www.jpattonassociates.com/user-story-

mapping/
[3] Ordered vs. prioritized list https://medium.com/the-liberators/myth-in-scrum-

the-product-backlog-is-prioritized-bae533f7514a
84
5
In any given moment we have two options: to
step forward into growth or to step back into
safety.
Abraham Maslow
Scrum in Software Development

Scrum as described in the Scrum Guide[SS20] is domain independent.
Software development can use the events, artifacts and accountabilities as they are
described in the Scrum Guide directly. In case you only want to start with one single
change do the Sprint Retrospective at least every 30 days and adapt you organization
along the found impediments for the development teams.
If you would like to go further introduce the Sprint Review to discuss the value you
have created in the last 30 days. This can be supported by introducing the Sprint Planning
and the daily check of the process towards the Sprint Goal in the Daily Scrum.
5.1. Bibliography
[Jus21] Joe Justice. Scrum Master: The Agile Training Seminar for Business Performance.
self-published, 2021.

Publishing, 2009.
[SP19] Matthew Skelton and Manuel Pais. Team Topologies: Organizing Business and
Technology Teams for Fast Flow. IT Revolution Press, 2019.
85
6
Failure is not fatal, but failure to change might
be.
John Wooden
Scrum in Hardware Development

The implementation of Scrum as described in the Scrum Guide[SS20] is domain inde-
pendent. The only real headache creating point is that the sprint can last up to 30 days
and then you have to have a value-maximizing increment[Sam18] (see also section 2.3.4
on page 31).
Scrum is a managing framework for Agile Development (chapter 2 on page 26). It is
intentinally incomplete and the gaps have to be filled with practices from your domain.
All aspects listed in the chapter Agile Hardware Development starting on page 26 are to
be considered.
For the accountabilities, artifacts and events see the chapter 4 on page 56.
6.1. Additional Considerations

To successfully implement Scrum in hardware development, consider these adaptations:
Regulatory Integration Include regulatory expert knowledge in the team to ensure

compliance throughout the development process.
Documentation Management Define clear processes for documentation. Determine

what documentation is necessary and how it will be incrementely done.
Risk Assessment Integrate risk assessments and validation testing into each Sprint to
ensure that safety and compliance concerns are addressed.
Test Automation Automate testing processes where possible to ensure thorough

testing within the short cycles.
Skillful Team Formation Assemble a team with a blend of hardware engineering

expertise, regulatory knowledge, and medical domain understanding.
86
6.2. Example: Wikispeed
6.2. Example: Wikispeed1

WikiSpeed is an open-source, volunteer–based project that aims to develop modular,
fuel–efficient, and safe road–legal cars using agile methodologies. The project was
initiated by Joe Justice in 2008 and gained attention for its unique approach to car devel-
opment.
Agile Approach WikiSpeed utilizes agile principles, including Scrum, to streamline

the development of its vehicles. Here’s how it works:
1. Cross-Functional Teams: WikiSpeed organizes its development teams into small,

cross-functional groups that work on specific car modules, such as chassis, pow-
ertrain, and interior. Each team consists of engineers, mechanics, and volunteers
with relevant expertise.
2. Iterative Development: Just like in Scrum, WikiSpeed follows iterative development

cycles. Teams work in short sprints, usually a week long, to design, build, and test
specific components. These components are then integrated into the overall vehicle
design.
3. Rapid Prototyping: Agile principles promote rapid prototyping. WikiSpeed applies

this by building working prototypes of individual car components within a short
timeframe. This allows for quick validation and adjustment of designs.
4. Customer Feedback: WikiSpeed encourages constant feedback from both team

members and potential users of the cars. This helps in refining designs and ad-
dressing concerns early in the development process.
Successes WikiSpeed’s agile approach has led to some significant successes
1. Fuel Efficiency: One of the key goals of WikiSpeed is to develop fuel–efficient

vehicles. Through iterative development and optimization, they have achieved
impressive fuel efficiency in their cars, far surpassing traditional automobile stan-
dards.
2. Modularity: The modular design of WikiSpeed vehicles allows for easy customiza-
tion and upgrades. This aligns with agile principles of adaptability and responding
to changing needs.
3. Open Collaboration: WikiSpeed operates with an open–source ethos, allowing

anyone to contribute to the project. This collaborative approach has attracted a
diverse community of volunteers and experts.
1
https://wikispeed.com/
87
6. Scrum in Hardware Development
4. Speed of Development: The agile methodology has enabled WikiSpeed to produce

working prototypes in remarkably short timeframes, demonstrating the effective-
ness of the iterative approach.
5. Learning and Adaptation: WikiSpeed emphasizes continuous learning and adap-

tation. Lessons learned from one sprint are carried over to the next, leading to
continuous improvement.
WikiSpeed’s success highlights how agile principles can be applied beyond software
development and in innovative contexts such as automotive engineering. It showcases
the potential for accelerated development, efficient resource utilization, and community
collaboration through the agile methodology.
6.3. Bibliography
[Jus21] Joe Justice. Scrum Master: The Agile Training Seminar for Business Performance.
self-published, 2021.

Publishing, 2009.
[Sam18] Paolo Sammicheli. Scrum for Hardware. self-published, 2018.
88
Scrum Outside the Software Organization
7
Here are some examples of application of Scrum outside the software development:
• eduScrum:
https://www.eduscrum.nl
– Vision of eduScrum:
https://www.eduscrum.nl/img/Shu Ha Ri Path international ENs.pdf
– Scrum for Education - Experiences from eduScrum and Blueprint Education:
https://www.infoq.com/articles/scrum-education
– Scrum4Schools: Wie fuehrt man Scrum in der Schule ein?
https://www.borisgloger.com/blog/2019/05/10/scrum4schools-wie-fuehrt-
man-scrum-in-der-schule-ein
• Scrum for Hardware:

http://scrum-hardware.com
– Scrum for Hardware? Yes!
https://medium.com/supplyframe-hardware/scrum-for-hardware-yes-
6c848806a8c1
– The Scrum in Hardware Guide:
https://www.scruminc.com/scrum-in-hardware-guide
– Joe Justice Uses Scrum for Wikispeed
https://www.youtube.com/watch?v=x8jdx-lf2Dw
– Teaching Scrum at Tesla
https://www.scruminc.com/teaching-scrum-at-tesla-talking-with-silicon-
valley-agile-leadership-network/
– Master Thesis from Volvo Car
https://odr.chalmers.se/bitstream/20.500.12380/256781/1/256781.pdf
89
8
Of course, speed is most useful if it is in the
correct direction.
David J. Anderson
Kanban
8.1. History
Kanban in Lean Manufacturing
The system originates from the simplest visual stock replenishment signaling system, an
empty box. This was first developed in the UK factories producing Spitfires airplanes
during the Second World War, and was known as the “two bin system”. In the late
1940s, Toyota started studying supermarkets with the idea of applying shelf-stocking
techniques to the factory floor. In a supermarket, customers generally retrieve what they
need at the required time—not more, not less. Furthermore, the supermarket stocks
only what it expects to sell in a given time, and customers take only what they need,
because future supply is assured. This observation led Toyota to view a process as being
a customer of one or more preceding processes and to view the preceding processes as a
kind of store.
Kanban aligns inventory levels with actual consumption. A signal tells a supplier to
produce and deliver a new shipment when a material is consumed. This signal is tracked
through the replenishment cycle, bringing visibility to the supplier, consumer, and buyer.
Kanban uses the rate of demand to control the rate of production, passing demand from
the end customer up through the chain of customer-store processes. In 1953, Toyota
applied this logic in their main plant machine shop. [Ohn88]
Kanban in Service and Software Development

The history of Kanban in Service and Software Development is directly connected to the
name of David J. Anderson and his book “Kanban” [And10], which describes the result
of a project in 2004 at Microsoft [AD15] and Corbis in the years 2006/07. The method
was inspired by the theory-of-constraints1 [CS10] approach and incorporating a drum-
buffer-rope [GC14] but looked more on the differences of each product development
e.g., team skill set, project schedule, etc. than at the shop floor, where always identical
items will be processed.
Don Reinertsen was in close contact with David and recommends looking a bit deeper
into the success of the Toyota Production System (TPS), which uses batch-size and
variability reduction to lower work-in-progress inventory and so improve the flow of work
1
https://en.wikipedia.org/wiki/Theory of constraints
90
8.2. Usage
(items) in the system. These points are summarized in his book on second-generation
lean product-development [Rei09]2 back in 2009.
In the following years combinations and fields of application of Kanban where ex-
plored e.g., Scrumban [Cor08], Personal Kanban [BB11], Agile Project Management with
Kanban [Bre15] (p. 160), Kanban Change Leadership [LK15].
In 2016 Lean Kanban University Press published a condensed guide to the method,
incorporating improvements and extensions from the early Kanban projects [AC16] and
in 2018 the method was complemented by the Kanban Maturity Model [AB18].
8.2. Usage
How much do you know about Kanban? Check the sub-sentences that
correctly complete the sentence.
1. Kanban is a (weakly rule-based , strongly rule-based ) method.
2. Kanban works (well , not so well ) with Scrum.
3. Kanban works (in Japan , world-wide ).
4. Kanban practices are (easy , hard ) to establish.
5. Kanban teams and Scrum teams (can , cannot ) work together

on a single product.
Kanban Principles
The idea behind Kanban is to establish a work-in-process limited pull system to find the Reading until page
bottleneck (constraint) in the system and remove them from the system. If you have 94
an existing Scrum implementation you will enjoy the additional benefits from applying
Kanban principles and core practices [KS].
The principles are:
• Start with what you do Now
• Agree to pursue improvement through Evolutionary Change
• Encourage acts of Leadership at every level
• Understand & focus on Customer’s needs and expectations
• Manage the work; let the People self-organize around it
• Policy (process) controlled Service Delivery
2
supported by [Rei98], [Rei97]
91
8. Kanban
And the core practices are:
• Visualize (the work, workflow, and risks to flow/value delivery)
• Limit WIP3
• Manage flow
• Make policies (processes) explicit
• Implement feedback loops
• Improve collaboratively, evolve experimentally (using models4 and the scientific

method5 )
Visualize Scrum teams often visualize the flow of work by visualizing all the steps
needed from the idea identification to the customer is using the product (–increment)6 .
This is then looking similar to this:
Idea Pool Analysis Development Build Test Release Done

In Progress Done In Progress Done
But let’s start with the basics. A Personal Kanban board helps to get an overview on
workflow states per person:
Team Member Backlog Next In-Progress Done

(∞) (max. 3 per person) (max. 3 per person) (∞)
Bernhard
Lin
Steven
Joanna
Limit Work in Progress Now that the team has visualized its workflow a Kanban
system can be installed by adding WIP limits7 .
3
To calculate the WIP (work-in-procress) limit chapter G on page 160
4
http://www.agile-process.org/model.html
5
The scientific method is an empirical method for acquiring knowledge that has character-
ized the development of science since at least the 17th century (with notable practitioners in
previous centuries; see the article history of scientific method for additional detail.) from:
https://en.wikipedia.org/wiki/Scientific method
6
We can visualize the full value stream across the organization.
7
The Sprint limits the number of work items only, but not the parallel work.
92
8.2. Usage
Idea Pool Analysis Development Build Test Release Done

2 1 3 2 2 2
In Progress Done In Progress Done
When a limit is reached, no additional Product Backlog Item (PBI) can be pulled into
this column. The Developers have to free up capacity for new items by doing work
downstream, i. e. working from right to left, starting with the column “release” and ask,
what can be finished now.
If the Scrum Team would run a board without WIP limits, work will pill up in some
columns of the systems while others columns will run idle. By limiting the work in
each process step it will create a continuous flow of work items and so have a better
throughput in the system [Rei09]. To stabilize the flow it is required to limit the inflow
of each column where work in pilling up. This will be done by working upstream8 .
WIP limits
• are represented by the numbers in each column (main or sub-column) that repre-
sent the maximum numbers of work items per column.
• should be as low as painful, to trigger the need of improving the Kanban system, e.g.,
by reducing batch size [Rei09]or introduce Acceptance Test-Driven-Development.
• forster team collaboration.
• can be read from a cumulative flow chart (section G.3 on page 165)
Manage Flow As soon as the Kanban is established managing of the flow of the work
items will start, by using a continuous improvement process, which will especially follow
up on the bottlenecks (or constraints) in the system. (see Theory of Constraints in
[GC14] and [CS10]). This can be done by using a Cumulative Flow Diagram (section
G.3 on page 165) or just be looking for work pilling up.
Make policies (processes) explicit The team clearly states exit criteria for each column,
e.g., like the Definition of Done (DoD) for moving items into the “Done” column.
Implement feedback loops The Scrum team will use the regular Scrum events to
collect the feedback from the stakeholders.
8
From right to left on the board.
93
8. Kanban
Improve collaboratively, evolve experimentally (using models and the scientific

method) The Scrum team applies inspect and adapt in all Scrum events. The team
might use additional techniques, like A3 [SS08] & Toyota Kata [Rot09] or get inspired
by Don Reinertsen’s principles [Rei09].
Discussion: When would you combine Scrum and Kanban? We do this
exercise in the big room, all together.

Where could you apply the ideas of a Kanban system?
8.3. Bibliography
[AB18] David J. Anderson and Teodora Bozheva. Kanban Maturity Model. Lean
Kanban University Press, 2018.
[AC16] David J. Anderson and Andy Carmichael. Essential Kanban Condensed. Lean
Kanban University Press, 2016.
[AD15] David J. Anderson and Dragos Dumitriu. From worst to best in 9 months:
Implementing a drum-buffer-rope solution at microsoft’s it department.
TOC ICO World Conference November 2005, 2015. Retrieved 24 September
2020.
[And10] David J. Anderson. Kanban: Successful Evolutionary Change for Your Technology
Business. Blue Hole Press, 2010.
[BB11] Jim Benson and Tonianne DeMaria Barry. Personal Kanban: Mapping Work,
Navigating Life. Modus Cooperandi Press, 2011.
[Bre15] Eric Brechner. Agile Project Management with Kanban. Microsoft Press, 2015.
[Bur14] Mike Burrows. Kanban From The Inside. Blue Hole Press, 2014.
94
8.3. Bibliography
[Cor08] Ladas Corey. Scrumban and other essays on Kanban System for Lean Software
development. Modus Cooperandi Press, 2008.
[CS10] James F. Cox and John G. Schleier. Theory of Constraints Handbook. Mcgraw-
Hill Professional, 2010.
[GC14] Eliyahu M. Goldrat and Jeff Cox. The Goal: A Process of Ongoing Improvement.
The North River Press Publishing Coperation, 2014.
[KS] Henrik Kniberg and Mattias Skarin. Kanban and Scrum - Making the Most
of Both. last visited: 2021-02-09.
[LK15] Klaus Leopold and Siegfried Kaltenecker. Kanban Change Leadership. John
Wiley & Sons, 2015.
[Ohn88] Taiichi Ohno. Toyota Production System: Beyond Large-Scale Production. Pro-
ductivity Press, 1988.
[Rei97] Donald Reinertsen. Managing the Design Factory. Free Press, 1997.
[Rei98] Donald Reinertsen. Developing Products in Half the Time. Van Nostrand
Reinhold, 1998.

Publishing, 2009.
[Rot09] Mike Rother. Toyota Kata: Managing People for Improvement, Adaptiveness and
Superior Results. McGraw-Hill Education Ltd, 2009.
[SS08] Art Smalley and Durward K. Sobek. Understanding A3 Thinking: A Critical

Component of Toyota’s PDCA Management System. Taylor & Francis, 2008.
95
9
Size clearly matters. You probably couldn’t run
an XP (Extreme Programming) Project with a
hundred programmers. Nor 50. Nor 20, proba-
bly. Ten is definitely doable. . .
Kent Beck
Scaling Frameworks
Internet Hunt: How many scaling frameworks do you find?

Notes:
Reading on Developing multi-layered products like MRI, CT or X-ray machines in a very short
page 103 time requires many teams & suppliers to work together.
We need a supporting architecture that allows us to divide the product into functional
groups and develop these functional groups with individual teams as independently as
possible.
Finally, if our organization is going to apply agile principles and values, we need to
scale the necessary practices.
In general, we focus on managing the dependencies between teams using the ideas and
practices from these frameworks for scaling agility: Nexus™, SAFe®, LeSS, Scrum@Scale,
Spotify Engineering Model, and others.
We will pick the two used at Siemens Healthineers to illustrate the scaling aspects.
9.1. Nexus™
Nexus™ is described in the Nexus™ Guide1 and bases on the ideas of Scrum and
enhancing it.
“A Nexus is a group of approximately three to nine Scrum Teams that work together
to deliver a single product; it is a connection between people and things. A Nexus has a
1
See https://www.scrum.org/resources/nexus-guide
96
9.1. Nexus™
single Product Owner who manages a single Product Backlog from which the Scrum
Teams work.”2
“Nexus extends Scrum in the following ways:
• Accountabilities: The Nexus Integration Team ensures that the Nexus delivers
a valuable, useful Integrated Increment at least once every Sprint. The Nexus
Integration Team consists of the Product Owner, a Scrum Master, and Nexus
Integration Team Members (the appropriate members from the Scrum Teams).
• Events: Events are appended to, placed around, or replace regular Scrum events to
augment them. As modified, they serve both the overall effort of all Scrum Teams
in the Nexus, and each individual team. A Nexus Sprint Goal is the objective for
the Sprint.
• Artifacts: All Scrum Teams use the same, single Product Backlog. As the Product
Backlog items are refined and made ready, indicators of which team will most likely
do the work inside a Sprint are made transparent. A Nexus Sprint Backlog exists
to assist with transparency during the Sprint. The Integrated Increment represents
the current sum of all integrated work completed by a Nexus.”3
With Nexus, we add an accountability: The Nexus Integration Team, which is account-
able for ensuring that an integration happens at least once per Sprint. If there are
integration issues, the Nexus Integration Team Members will be selected by their skill
and knowledge to resolve this issue, i.e., the composition of the Nexus Integration Team
might change over time.
As for the Nexus events we will not change the Sprint, but we now have a Cross-Team
Refinement. The Product Backlog has to be prepared to show the dependencies. The PBIs
have to fit into on Sprint for a single Scrum Team. The Nexus Sprint Planning will help to
coordinate the activities in a single Sprint. It is held prior to the actual individual team
sprint planning sessions to identify, remove or minimize the interdependencies between
teams.
“The result of Nexus Sprint Planning is:
• a Nexus Sprint Goal that aligns with the Product Goal and describes the purpose
that will be achieved by the Nexus during the Sprint
• a Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal
• a single Nexus Sprint Backlog that represents the work of the Nexus toward the
Nexus Sprint Goal and makes cross-team dependencies transparent
• A Sprint Backlog for each Scrum Team, which makes transparent the work they
will do in support of the Nexus Sprint Goal”4
2
From: https://www.scrum.org/resources/online-nexus-guide
3
4
97
9. Scaling Frameworks
The Nexus Daily Scrum is used to identify integration issues as well as inspecting the
progress toward the Nexus Sprint Goal. It will be joined by team representatives. Plans
might be adapted to new information. Changing plans hasn’t to be a one time per
day activity, it could happen at any time. The Nexus Sprint Review is used alike to the
Scrum Review, but replaces the individual team Sprint Review in favor of the integrated
Increment of all Scrum Teams. The Nexus Sprint Retrospective is used in addition to the
Team Sprint Retrospectives to improve the Nexus. It concludes the Sprint.
The Nexus handles the Artifacts like in Scrum but now with another scale. The
Product Backlog might now contain bigger items, but is still the single source of truth. The
commitment for the Product Backlog is still the Product Goal. The Nexus Sprint Backlog
contains all PBIs and Sprint Goals from all Scrum Teams. It shows the dependencies
and gets constantly updated. The commitment of the Nexus Sprint Backlog is the Nexus
Sprint Goal, which is a single objective for the whole Nexus. Last but not least we have
the Integrated Increment with its commitment the Definition of Done.
9.2. Scaled Agile Framework (SAFe)

Video: SAFe in 5 minutes
The Scaled Agile Framework (SAFe)5 is another scaling framework, which can be used
like the Nexus Framework up 125 people in a so-called Agile Release Train (ART)—again
a Team-of-Teams—or even combining ARTs to a Solution Train with up to 600 people to
build a system of systems. SAFe is an operating system for business agility. It provides
you with practices for the Core Competencies of the Lean Enterprise6 .
The base of Scaled Agile Framework (SAFe) is the Agile Team, which has 5–11 members
and is able to define, build, test and deploy value in a short timeframe, called Iterations.
It uses Scrum and/or Kanban to process and visualize work. The team has the artifacts
and is following the events of the chosen framework.
The ART works in a timebox called Program Increment(PI) consisting of five iterations.
The PI starts with the PI Planning, where all teams come together and plan their work
for the upcoming PI in a two–day PI Planning event. The facilitation is done by the
Release Train Engineer (RTE). The RTE is the coach (Chief Scrum Master) for the ART.
Product Management(PM) is responsible for the Product Vision and the Backlog, the
System Architect gives architectural guidance. The outcome of the PI Planning is the
Program Board showing the dependencies of the teams and projected finish iterations of
the features. At the end of every iteration the ART demos the integrated solution in the
System Demos. At the end of the PI all teams reflect on how to improve in the Inspect
& Adapt (I & A) event. Design Thinking is applied by the PM to follow the idea of
Customer Centricity to create solutions that are desirable, feasible, and sustainable.
The ART builds a Continuous Delivery Pipeline (CD) consisting of Continuous Ex-
ploration (CE), Continuous Integration(Continuous Integration (CI)), and Continuous
5
https://www.scaledagileframework.com/
6
Team and Technical Agility, Agile Product Delivery, Enterprise Solution Delivery, Lean Portfolio
Management, Organizational Agility,Continuous Learning Cultureand Lean-Agile Leadership
98
Deployment (Continuous Deployment (CD)). By applying DevOps practices the gap be-
tween development and operations gets closed and Release on Demand will be possible.
If the product gets too big to be delivered by a single ART, the Core Competency
of “Enterprise Solution Delivery” comes into play. A Solution Train7 now coordinates
multiple ARTs and suppliers and will deliver large, complex solutions. The Solution
Management has the backlog authority for the solution. The Solution Architect coordi-
nates the architecture across ARTs and the Solution Train Engineer (STE) is the coach of
Solution Train and will facilitate the Solution Train events.
To connect strategy and execution Lean Portfolio Management(LPM) is used. LPM
provides Strategic Themes and a Portfolio Vision to align solution development with the
enterprise strategy. LPM helps to create and fund value streams for product delivery.
Organizational Agility will enable the organization to create agility beyond develop-
ment (Business Agility) and helps to create lean-agile thinking people.
Relentless improvement will be supported by the Core Competency of Continuous
Learning Culture.
All this is build upon Lean-Agile Leadership who have to embody, teach and exhibit a
mindset, values, and principles of lean and agile.
9.2.1. SAFe Principles

Let’s take a look at the principles:
Most of the principles are inspired by Don Reinertsen’s book “Product Development
Flow” [Rei09].
The principles8 are:
Take an economic view
While you may ignore economics, it won’t ignore you.—Don Reinertsen
“Delivering the ’best value and quality for people and society in the shortest sustainable
lead time’ requires a fundamental understanding of the economics of building systems.
Everyday decisions must be made in a proper economic context. This includes the
strategy for incremental value delivery and the broader economic framework for each
value stream. This framework highlights the trade-offs between risk, Cost of Delay (CoD),
manufacturing, operational, and development costs. In addition, every development
value stream must operate within the context of an approved budget, and be compliant
to the guardrails which support decentralized decision-making.” ©Scaled Agile, Inc.
Apply system thinking
A system must be managed. It will not manage itself. Left to themselves,

components become selfish, competitive, independent profit centers, and
7
This is the next scaling configuration in SAFe
8
https://www.scaledagileframework.com/safe-lean-agile-principles/
99
thus destroy the system. The secret is cooperation between components

toward the aim of the organization.—W. Edwards Deming
“Deming observed that addressing the challenges in the workplace and the marketplace
requires an understanding of the systems within which workers and users operate. Such
systems are complex, and they consist of many interrelated components. But optimizing
a component does not optimize the system. To improve, everyone must understand
the larger aim of the system. In SAFe, systems thinking is applied to the system under
development, as well as to the organization that builds the system.” ©Scaled Agile, Inc.
Assume variability; preserve options
Generate alternative system-level designs and subsystem concepts. Rather

than try to pick an early winner, aggressively eliminate alternatives. The
designs that survive are your most robust alternatives.—Allen C. Ward
“Traditional design and life cycle practices encourage choosing a single design-and-
requirements option early in the development process. Unfortunately, if that starting
point proves to be the wrong choice, then future adjustments take too long and can lead
to a suboptimal design. A better approach is to maintain multiple requirements and
design options for a longer period in the development cycle. Empirical data is then used
to narrow the focus, resulting in a design that creates optimum economic outcomes.”
©Scaled Agile, Inc.
Build incrementally with fast, integrated learning cycles
The epiphany of integration points is that they control product development

and are the leverage points to improve the system. When timing of integration
points slips, the project is in trouble.—Dantar P. Oosterwal
“Developing solutions incrementally in a series of short iterations allows for faster cus-
tomer feedback and mitigates risk. Subsequent increments build on the previous ones.
Since the ‘system always runs’, some increments may serve as prototypes for market
testing and validation; others become Minimum Viable Products (MVPs). Still others
extend the system to with new and valuable functionality. In addition, these early, fast
feedback points help determine when to ‘pivot’, where necessary to an alternate course
of action.” ©Scaled Agile, Inc.
Base milestones on objective evaluation of working systems
There was in fact no correlation between exiting phase gates on time and
project success . . . the data suggested the inverse might be true.—Dantar P.
Oosterwal
100
“Business owners, developers, and customers have a shared responsibility to ensure that
investment in new solutions will deliver economic benefit. The sequential, phase-gate
development model was designed to meet this challenge, but experience shows that it
does not mitigate risk as intended. In Lean-Agile development, integration points provide
objective milestones at which to evaluate the solution throughout the development life
cycle. This regular evaluation provides the financial, technical, and fitness-for-purpose
governance needed to assure that a continuing investment will produce a commensurate
return.” ©Scaled Agile, Inc.
Visualize and limit WIP, reduce batch sizes, and manage queue lengths
Operating a product development process near full utilization is an economic

disaster.—Donald Reinertsen
“Lean enterprises strive to achieve a state of continuous flow, where new system ca-
pabilities move quickly and visibly from concept to cash. Keys to implementing flow
are:
1. Visualize and limit the amount of WIP. This increases throughput and limits
demand to actual capacity.
2. Reduce the batch sizes of work to facilitate fast and more reliableReading to page
121 flow.
3. Manage queue lengths to reduce the wait times for new functionality.”
Apply cadence, synchronize with cross-domain planning
Cadence and synchronization limit the accumulation of variance.—Don Rein-

ertsen
“Cadence creates predictability and provides a rhythm for development. Synchronization

causes multiple perspectives to be understood, resolved, and integrated at the same
time. Applying development cadence and synchronization, coupled with periodic cross-
domain planning, provides the mechanisms needed to operate effectively in the presence
of the inherent development uncertainty.” ©Scaled Agile, Inc.
Unlock the intrinsic motivation of knowledge workers
It appears that the performance of the task provides its own intrinsic reward
. . . this drive . . . may be as basic as the others . . . —Daniel Pink
“Lean-Agile leaders understand that ideation, innovation, and employee engagement

are not generally motivated by individual incentive compensation. Such individual
incentives can create internal competition and destroy the cooperation necessary to
101
achieve the larger aim of the system. Providing autonomy and purpose, minimizing
constraints, creating an environment of mutual influence, and better understanding the
role of compensation are keys to higher levels of employee engagement. This approach
yields better outcomes for individuals, customers, and the enterprise.” ©Scaled Agile,
Inc.
Decentralize decision-making
Knowledge workers themselves are best placed to make decisions about how
to perform their work.—Peter F. Drucker
“Achieving fast value delivery requires decentralized decision-making. This reduces

delays, improves product development flow, enables faster feedback, and creates more
innovative solutions designed by those closest to the local knowledge. However, some de-
cisions are strategic, global, and have economies of scale that justify centralized decision-
making. Since both types of decisions occur, creating a reliable decision-making frame-
work is a critical step in empowering employees and ensuring a fast flow of value.”
Organize around value
Applying management frameworks from a hundred years ago to organiza-

tions that need to compete in the digital age is futile.—Mik Kersten
“Many enterprises today are organized around principles developed during the last
century. In the name of intended efficiency, most are organized around functional
expertise. But in the digital age, the only sustainable competitive advantage is the speed
with which an organization can respond to the needs of its customers with new and
innovative solutions. These solutions require cooperation amongst all the functional
areas, with their incumbent dependencies, hand-offs, waste and delays. Instead, Business
Agility demands that enterprises organize around value to deliver more quickly. And
when market and customer demands change, the enterprise must quickly and seamlessly
reorganize around that new value flow.” ©Scaled Agile, Inc.
A 2-day class training “Leading SAFe”9 will provide a deeper insights into SAFe.
9.2.2. Accountability of the Scrum Master in SAFe

Everything said in the previous chapters (see Scrum at page 56 and Kanban at page 90)
will help the Scrum Master to work in a scaled environment.
In addition, some task will be added by SAFe:
A Scrum Master within SAFe is a team–based servant leader. She applies Lean-Agile
leadership on a daily basis, helps the team internalize SAFe core values, adopt and apply
SAFe principles by implementing SAFe practices.
9
See Learn4U for training’s dates
102
9.3. LeSS
The Scrum Master is constantly challenging old norms of development to continuously

improve quality, predictability, work flow and speed. To do this, she facilitates team
retrospectives, teaches and supports with problem-solving techniques. She helps the
team create value, as well as achieve daily, iteration, and Program Increment (PI) goals.
The Scrum Master supports the coordination of the teams within the ART. She helps
to make sure that the train works well. To do this, she participates in the Scrum of
Scrums (SoS). She supports building effective relationship with the System Team, User
Experience, Architecture and the Shared Services. However, each team member must par-
ticipate in cross-team coordination; the Scrum Master cannot be given sole responsibility
here.
The Scrum Master supports the adoption of SAFe across the organization by coaching
stakeholders and non-agile teams on how to work with the agile team. She is the part of
the Scrum Master Community of Practice (CoP) and supports the LACE team with its
SAFe Program Consultants (SPCs). In doing so, she collaborates with all teams along
the development value stream.
In collaboration with the RTE, she prepares ART events and assists with Program
Increment Planning, System Demos and Inspect & Adapt (I & A) event . To this end,
she conducts estimates with the team for features and capabilities and helps the team
submit normalized estimates.
• Which of the two scaling frameworks would you choose? What are
the criteria to select the framework? We do this exercise in the big
room, all together.
• Please prepare the SAFe principles by reading from page 99 to 102

and answer the question: “What does this principle mean to our
work?” Please do the exercise in your breakout teams. We will
share your ideas afterwards. We do this exercise in the big room,
all together.
• What is the job of a Scrum Master in SAFe? (Please read Account-

ability of the Scrum Master in SAFe starting at page 102 to 103)
Please do the exercise in your breakout teams.
• Run SAFe City Simulation Please do the exercise in your

breakout teams. There is a section on the Conceptboard:
https://siemens.conceptboard.com/board/5qto-087y-36t1-gkio-
h046 for this exercise.
9.3. LeSS
[?, ?]
LeSS provides two different large–scale Scrum frameworks. Most of the scaling el-
ements of LeSS are focused on directing the attention of all the teams onto the whole
103
product instead of ”my part”. Global and “end–to–end” focus are perhaps the dominant
problems to be solve in scaling. The two frameworks, which are basically single–team
Scrum scaled up are:
LeSS — Up to eight teams (of eight people each).
LeSS Huge — Up to a few thousand people on one product
For more detailed information see: https://less.works/
9.4. Bibliography
[KL20] Richard Knaster and Dean Leffingwell. SAFe® 5.0 Distilled. Addison-Wesley,
2020.


Publishing, 2009.
[Scr] Scrum.org. Ken Schwaber explains: What is Scaled Scrum? last visited:
2021-03-08.
Additional Reading
[1] Ken Schwaber. 2021 Nexus™ Guide. https://www.scrum.org/node/4709 (Last
visited: 2023-02-16)
[2] 10 Scaling Tips for Product People https://www.romanpichler.com/blog/10-

scaling-tips-for-product-people (Last visited: 2023-02-16)
[3] SAFe https://www.scaledagileframework.com/ (Last visited: 2023-02-16)
[4] LeSS https://less.works (Last visited: 2023-02-16)
[5] Nexus https://www.scrum.org/resources/scaling-scrum (Last visited: 2023-02-16)
[6] Nexus explained https://youtu.be/wuc3NPsL844 (Last visited: 2023-02-16)
[7] SAFe in 5 minutes https://youtu.be/aW2m-BtCJyE (Last visited: 2023-02-16)
104
Part III.
User Stories
106
10
Do the simplest thing that could possibly work.
Kent Beck
User Stories
Breaking news: Imagine you are a news reporter and you are asked to
research to research what are typical problems in creating and editing
requirements? Of course, you explain the term requirement as well. Will
you make the news in prime time?
Notes:
As we have seen, agile development is based on feedback, learning, and collaboration. Reading to Page
Requirements such as "The email notification must include the dollar amount, the date, the 108
name of the payee, and an identification number"‌ lead to information loss. They do not name
the customer’s problem or provide context, and thus do not open up solution space for
development.
The user story [Bec04] deals with this problem, a lot of different aspects, and interests
e.g.,1
• Project managers want to track progress
• Programmers want to implement the system
• Product managers want flexibility
• Testers want to measure
• Users want an efficient system
Ron Jeffries2 names three critical aspects of a user story [Jef01]:
1
taken from [Coh04](p. xv)
2
Ron Jeffries cofounded Extreme Programming (XP) together with Kent Beck and Ward Cunningham.
107
10. User Stories
• “The Card is a token representing the requirement. It’s used in planning.”3
• “The requirement itself is communicated from customer to programmers through

Conversation: an exchange of thoughts, opinions, and feelings. ”3
• “The conversation is largely verbal, but can be supplemented with documents. The
best supplements are examples; the best examples are executable, We call these
examples Confirmation.”3
An example of an initial user story is: “A user can post her resume to the website.” but
not “We use Haskell to create the software.”
What is meant by conversation and confirmation? XP came up with the idea of sketch
the idea of the customer in a short sentence on a card. This card is the reminder to have a
conversation about what is behind that sketch. The developer could simply ask the user
what they really need since XP was created for a small group of users. The developer
built what they understood and showed it to the user with a request for confirmation.
There are some disadvantages of user stories when we are working in large projects or
on large topics that require a lot of interactions:
• Lack of foresight—“the teams need a better form of look-ahead to detect earlier on

what questions are likely to be asked which will be easy to answer, and which will
take time.” [Coc06] This could be accomplished by having the PO setting the goal
for the product4 .
• Lack of context— since a user story contains a very short description5 we might not
understand the context in which it is embedded. And here comes the rule, a user
story “has user value” but “there is nothing in the idea of a user story about how
much value to the user it contains.” [Coc06] Listing the value gives us an idea of
what the customer might expect. We can create additional confirmation if we are
doing the right thing by listing acceptance tests/criteria or user acceptance tests on
the back of the card.
• Lack of completeness— “the developers ask questions, these answers generate more
user stories, often more than were anticipated” [Coc06]. We address that by accept-
ing this incompleteness. There will be always more ideas than time for developing
them.The PO must have a clear idea of what the product is about and in most cases
say "no".6
Another way to mitigate these disadvantages is to create use cases instead of user stories
and then derive the user stories for the next Sprint from the use cases. [Coc00]
3
From: Essential XP: Card, Conversation, Confirmation
4
In Scrum, there is the Product Goal (4.6 on page 74) and the Sprint Goal (4.6 on page 75).
5
“The shortest user story I have heard of is the one word ‘Kaboom’ on naval artillery project, meaning
‘Take a shot and tell me where it hit’” [Coc06]
6
See blog: A thousand No’s (http://blackswanfarming.com/why-doesnt-apple-make-a-printer) and
video: Agile Product Ownership in a Nutshell - Henrik Kniberg [16:00] (https://youtu.be/502ILHjX9EE)
108
10.1. Writing Stories

What do you think the disadvantage do to your work? How could you
close this gap? Please do the exercise in your breakout teams. Notes:

What information should a user story contain?

Complete the sentences by selecting the correct sub-sentence:
1. A user story should follow the idea of (invest / spend ).
2. User stories should be (independently /connected to each other

).
3. Scrum uses (user stories / use cases ) to describe product back-

log items.
4. User stories are (estimated / just counted ).
How to start writing user stories? Bill Wake ([Wak]) suggests using an acronym Reading to Page
113
109
10. User Stories
INVEST for remembering the characteristics of a story card:
I ndependent
N egotiable
V aluable to users and customers
E stimatable
S mall
T estable
All examples are from [Coh04].
Independent
When user stories are interdependent, we lose the ability to sequence them in a way that
optimizes the value of the product. Independent stories would look like this:
“A company can pay for a job posting “A company can pay for a job posting
with Visa card.” with MasterCard.”
Negotiable
Stories are not written contracts or specifications. They are short descriptions of customer
desires and expected value. (see10 on page 107)
“A company can pay for a job posting with credit

card.”
Note: Will we consider Discover?

Note for UI: Don’t have a field for card type (it
can be derived from first two digits of the card).
Valuable to Customer and User

Stories should have value, and who the story is valuable to must be judged individually.
One end of the continuum represents the value position for the user, and the other
represents the value position for the developer. We can move freely along it.
A client-related stories:
110
“All configuration’s information is read from a

central location.”
An example on the other end:
“All connections to the database are through a

connection pool.”
A better variant of this story could be7 :
“Up to fifty users should be able to use the appli-

cation with a five-user database license.”
Estimable
The developers have to be able to estimate the story (see also 11 on page 117).
“There are three common reasons why a story may not be estimable:
1. Developers lack domain knowledge
2. Developers lack technical knowledge
3. The story is too big.” [Coh04]
The first point can be removed by discussing the story with the customer or PO.
The second point can be addressed by running a little experiment, called a spike
(fromXP8 ) to learn about the technology. The “real” story goes on a second card.
The third point can be handled by naming the story “epic” (see also 10.1).
7
to move to the customer-centricity end
8
http://www.extremeprogramming.org/rules/spike.html
111
10. User Stories
Small
Size is important for the planning. Large–format stories can be divided into two cate-
gories: compound stories and complex stories. “A composite story is an epic that consists
of several shorter stories.” [Coh04] Therefore the epic can be broken down while dis-
cussing the expected outcome/value with the customer/user. Unlike the Compound
Story, the Complex Story is a user story that is extensive in nature and cannot be easily
broken down into a series of individual stories. [Coh04] Usually it is a convenient to
split this type of story into a research story (aka. spike8 ) and a development story. It is
important that the spike is time-boxed, which is the maximum time for learning. This
spike will be estimated (just use the time-box information for that).
Testable
“If the story cannot be tested, how can the developer know when they have finished
coding?” Untestable stories can be a sign of non-functional requirements.
Remember to automate tests. Do not break already working parts during the incre-
mental development of the product.
A worse example of a test is: “A user never has to wait long for a screen to appear.”
because the words “never” and “wait long” cannot be measured and therefore can not
be automated.. Better wording: “New screens appear within two seconds in 95% of the
time.” [Coh04]
Using invest may not give you a good phased user story because it should be simple
and easy to understand. Better use simple sentences and enrich them with the ideas of
invest : subject, verb, object.
Ambiguous terms do not belong in a user story. Therefore, the user story should
focus on the essentials. Rachel Davies, recommends formulating the user story along
the following lines, like this [DS09]: “As [role], I want [function] to [benefit].” or “As
[who], I want [what] to [why].”
The placeholder can be filled by answering the following questions:
• Who is requesting something? (=role)
The requester (a persona9 .) is usually the future user of the system or the benefi-
ciary of the solution being developed.
• What does the requester want? (=function)
The requester wants something specific to happen. The clearer and more precise
the request is in the user story, the more helpful the user story is to the development
team in creating the requirements or the task to be performed.
• Why is this important to the business case? (=benefit)
The requirement is intended to achieve a goal. The requester expects a benefit from
it. Describing the reason for the requirement gives the development team with
more information to execute it correctly.
9
User and customer personas can be found at https://ux-hub.healthineers.siemens.com/
112
10.2. Where do the Stories Come From?
Additionally, just a few additional words on good story10 :
• A good starting point is to write a story that describes a user/customer goal.
• Slice the story to support a good understanding and flow.
• Write the story as closed as possible.
• Arrange the stories according to the timeline.
• Keep the UI out as much as possible.
• Address only one user.
• Use defined user roles (personas) to describe the user.

Take some user stories from your context and rephrase them according
to the INVEST model. Please do the exercise in your breakout teams.

What do you think is the most important part of the INVEST model?
10.2. Where do the Stories Come From?

There are many ways to get stories11 .
• User interviews
• Questionnaires
• Observation
10
See [Coh04] pp. 76–83.
11
See [Coh04] pp. 43–54.
113
10. User Stories
• Story writing workshops.
Another possible starting point for a team discussion might be the creation a story map12 .
Be aware of the pitfall while using electronic tools: In Azure DevOps, you can put a
lot of descriptions and other information in the template, but the purpose of a user story
is to be a reminder to discuss the feature. It does not replace the conversation with the
customer or its representative (PO). Documentation is not communication.
We now check the available stories. There is a section on the Concept-
board: https://siemens.conceptboard.com/board/5qto-087y-36t1-gkio-
h046 for this exercise.Please do the exercise in your breakout teams.

For you, what are the most important concepts and insights of the section? How do you plan to
use what you’ve learned?
10.3. Bibliography
Wesley, 2004.
[Coc00] Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley Professional,

2000.

[Coh04] Mike Cohn. User Stories Applied: For Agile Software Development. Addison-
Wesley Professional, 2004.
12
Video: Story Mapping explained[12:00] and video: Jeff Patton - User Story Mapping: Discover The
Whole Story[50:00]
114
10.3. Bibliography
[Cor08] Ladas Corey. Scrumban and other essays on Kanban System for Lean Software
development. Modus Cooperandi Press, 2008.
[DS09] Rachel Davies and Liz Sedley. Agile Coaching. The Pragmatic Programmers,
2009.
[Jef01] Ron Jeffries. Essential xp: Card, Conversation, Confirmation. XP Magazin,

2001. last visited: 2021-03-02.
[KS] Henrik Kniberg and Mattias Skarin. Kanban and Scrum - Making the Most
of Both. last visited: 2021-02-09.
[May13] Tobias Mayer. The People’s Scrum. Dymaxicon, 2013.
[MJ18a] Don McGreal and Ralph Jocham. The Professional Product Owner. Addison-
Wesley, 2018.
[PE14] Jeff Patton and Peter Economy. User Story Mapping: Discover the Whole Story,
Build the Right Product. O’Reilly and Associates, 2014.

Publishing, 2009.
2019.
[Wak] William C. Wake. INVEST in Good Stories, and SMART Tasks. last visited:
2021-02-09.
[Wat13] Geoff Watts. Scrum Mastery - From Good to Great Servant Leadership. Inspect
& Adapt Ltd, 2013.
Additional Readings
[1] Stephanie Ockerman and Simon Reindl. Mastering Professional Scrum. Addison-
Wesley. 2020
[2] Ron Jeffries. Essential XP: Card, Conversation, Confirmation13 . 2001 (Last visited:
2023-02-16)
13
https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
115
10. User Stories
[3] Mike Cohn. Why the Three-Part User Story Template Works So Well14 . 2018 (Last
visited: 2023-02-16)
[4] Scrum Master Checklist https://scrummasterchecklist.org/ (Last visited: 2023-02-

16)
[5] Story Splitting Cheat Sheet15 (Last visited: 2023-02-16)
14
https://www.mountaingoatsoftware.com/blog/why-the-three-part-user-story-template-works-so-
well
15
https://agileforall.com/wp-content/uploads/2009/10/Story-Splitting-Cheat-Sheet.pdf
116
11
... software people are terrible at estimating,
because humans are terrible at estimating.
Lets not just try harder. Lets find a better way.
Ron Jeffries
Story Handling
11.1. Story Estimation

This section follows the content of [Coh04] pp. 87–129.
Complete the sentence: We estimate our work in
A ideal person hours.
B senior developer persons days.
C the team’s T-Shirt sizes.
D Story Points.
Mike Cohn [Coh04] describes the best approach for estimating user stories as: Reading to page
119
• “allows us to change our mind whenever we have new information about a story
• works for both epics and smaller stories
• doesn’t take a lot of time
• provides useful information about our progress and the work remaining
• is tolerant of imprecision in the estimates
• can be used to plan releases” [Coh04]
All of this can be fulfilled with Story Points. The team defines the meaning of a Story
Point. It could be an ideal day of work1 , an ideal week of work or a measure of complexity
or the unknown. It is a dimensionless unit and remedies a human deficiency. Everybody
in the team has to have the same understanding what’s behind a Story Point.
The Scrum Team owns the estimate, and it helps to plan (long and short term). Ad-
ditionally, the Scrum Team will do the estimates and no one else. The estimate itself
could be a qualified guess. Another approach is that all estimates are created by having
a reference story. Since humans are not good at estimating absolutely, they are better at
comparing to existing data points.
1
A day without interruptions, like meetings, emails, phone calls, etc.
117
11. Story Handling
We do this by selecting a story. To this we assign a 3 or 52 as an estimate. We now

call this story reference story. All other stories are now estimated with respect to the
estimate of the reference story3 .
There are several methods for estimation. The most used ones are Planning Poker4 ,
Magic Estimation, Triangulation [Coh04]and No Estimates5 .
Planning Poker The idea behind Planning Poker6 is to get all perspectives of all team
members into the size. The critical part is that we first estimate and then discuss the
differences in the estimates. Here is how we do Planning Poker:
1. Read out the story
2. Clarification questions get ask—no solution discussion
3. Everybody selects privately a card from the personal card deck
4. On the signal of the team coach (Scrum Master) cards gets turned
5. Discuss differences (highest and lowest card will present their reasons)
6. Re-estimate.
There are some rules in case of differences, if there are two or more units between
estimates, we re-estimate. If there is one unit in between we will go with the average of
all cards and round up to the next unit [Sut14].
Magic Estimation The magic estimation is another method for estimating. In this case
we put the cards in order using the same measure we would use in planning poker (how
much is unknown, complexity, etc.).
One card is placed on the floor and the next card is placed in the column below or above
that card, depending on how the person placing the card estimates. If a certain number
of cards have already been placed on the floor, someone may think that a particular card
no longer fits in the current order and place it in a different position in that row. The
Team Facilitator (Scrum Master) counts all the moves and has the moved cards discussed
after all the cards have been put in an order acceptable to all.
The Team Facilitator now opens the discussion for the cards that have been moved the
most. The team discusses the card with the highest count first and then all other cards in
descending order. All cards that have not been moved are not discussed, since the team
members have already agreed on the order before using the method.
2
These numbers are from the Fibonacci series (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 134, . . . ). But we could use
the powers of 2 (1, 2, 4, 8, 16, 32, . . . ) and then put a 4 or 8 on it.
3
This reference story might get replaced in the future, but for now it is the best we could get.
4
See video: Agile Estimating and Planning: Planning Poker [5:00] https://youtu.be/gE7srp2BzoM
5
[Dua16] and video: Vasco Duarte explains NoEstimates https://youtu.be/MhbT7EvYN0c[48:00]
6
James Greening. Planning Poker or How to avoid analysis paralysis while release planning
https://wingman-sw.com/papers/PlanningPoker-v1.1.pdf. 2002 and made popular in [Coh05]
118
11.1. Story Estimation
Then the planning poker cards can be used to subdivide the cards and determine the
estimation. The team facilitator asks for the boundaries of the individual value areas.
Triangulation If you have already estimated stories of different sizes you can easily
sort in new stories by using triangulation: “The story is bigger than . . . but smaller than
...”
No Estimates is an advanced method that might be used with mature teams. The
important part here is the story splitting (which we will see in the next section). All
stories have to be at an identical size, and we only count the number of stories we put into
our iteration (sprint) plan. Only the stories have a relevance for us as a team. [Dua16]
Release Planning All we need to know for release planning are the estimates of
the stories in the Product Backlog and our processing speed (velocity). After the first
iteration7 , we see how many stories we were able to complete and can now add up the
story points of those completed stories. This number gives us an idea of the team velocity.
Using this velocity, we can project the number of iterations we will need to complete the
current content of the backlog.
In our first iteration, we completed 5 stories with a total of 35 story points. There is a total of
350 story points in the backlog. So we will need about 10 iterations to complete the content of the
backlog. To determine the number of story points in the backlog, we will perform a quick estimate
(e.g., Magic Estimation) to get an initial idea. Since the backlog is never finished,8 and we are
always working on the most important things, we may finish earlier than planned. The value for
the customer/user might be available after 12 , 32 , . . . of the current backlog content is done.
If the backlog changes, we have to recalculate our forecast.
The release planning will give the team the opportunity to decide, whether they would
like to use the scope or the time as measure for the project.
There are a lot more estimation techniques available, e.g., T-Shirt Sizing9 , bucketing,
etc. but all follow the idea of relative estimation.
As the Scrum Master I would be able to use you different methods
to estimate, so that I am able to choose the appropriate one for the
current estimation round. In this exercise we will do Planning Poker
as well as Magic Estimation. After we clarified the method please
go to your break-out rooms. There is a section on the Conceptboard:
https://siemens.conceptboard.com/board/5qto-087y-36t1-gkio-h046 for
this exercise.In addition, we will create a release plan for our stories. We
do this exercise in the big room, all together.
7
In Scrum; the first Sprint.
8
Otherwise, the product development is completed
9
A Deep Dive Into T-Shirt Sizing
119
11. Story Handling

Which of the described method you would prefer and why? When do you think an alternative
method should be applied?
11.2. Story Splitting

Write a short newsletter article which discusses:
What are the characteristics of a story that is too big, and why should we
split it up?
Notes:
Reading to page The Product Owner has a vision of a product and will create initially story of any size.
121 Typical the story are complex or compound stories10 .
When we start talking about the story we might find out that the compound story
can be split in many stories that will be valuable for the user/customer. We will do that
accordingly but avoiding splitting the story in too small stories to reduce the overhead of
handling11 . If we run into this problem, we might want to combine the stories again, e.g.,
by looking for create, update and delete use cases.
On the other hand, they may be complex stories that can’t be easily broken down into
individual stories. In most cases, there is a big unknown around the story. In this case, it
10
[Coh04]
11
Transaction cost [Rei09].
120
11.3. Bibliography
may be useful to include a time-limited exploration section (called a spike) to provide

insights for estimating and dividing the story.
For splitting stories we will use some practices12 :
• Simple/Complex
• Variations in Data
• Operations (e.g., CRUD CReate, Update, Delete)
• Business Rule Variations
• Data Entry Methods
• Defer Performance
• Break Out a Spike

Let’s split some stories from out simulation.please go to your break-out
rooms.

Which of the described splitting method you would prefer and why? When do you think an
alternative method should be applied?
11.3. Bibliography
[Coh04] Mike Cohn. User Stories Applied: For Agile Software Development. Addison-
Wesley Professional, 2004.
[Coh05] Mike Cohn. Agile Estimating and Planning. Prentice Hall, 2005.
12
The full pattern list can be found in Story Splitting Cheat Sheethttps://agileforall.com/wp-
content/uploads/2009/10/Story-Splitting-Cheat-Sheet.pdf.
121
11. Story Handling
[Dua16] Vasco Duarte. No Estimates. OikosofySeries, 2016.
[Hum] Humanizing Work, LLC. Story Splitting Cheat Sheet. last visited: 2021-02-
09.

Publishing, 2009.
2019.
122
Part IV.
About Our Journey

12
As Healthineer I place team success before
my own.
Siemens Healthineers AG
Agile@Siemens Healthineers
12.1. Agile Working at Team Level

The development teams at Siemens Healthineers typically work with Scrum (see page
56) and Kanban (see page 90). Since we build hyper-physical solutions and therefore
many teams work together, we apply a scaling framework. The agreed framework is the
Scaled Agile Framework (SAFe) (see also page 98). Each business unit is free to decide
which framework to use1 .
We have many teams trying out working in an agile way, mostly Scrum leaned. It would
be nice if more teams try to apply Scrum as it is described and also try to understand the
ideas behind the framework.
In some business units, we also have portfolio management that drives all product
development with big business ideas.
Within Healthineers, there are very many manifestations of the SAFe framework. These
differ from each other more than the frameworks differ from each other. So, the question,
whether we have chosen the right framework is already irrelevant.
The introduction of SAFe has some nice sides, such as the low barrier to entry and
the good scalability, but also some not so nice sides, such as the use of already existing
role and work package designations, as this can lead to easy reuse. This is of course
not possible, rather each position has to be reassigned and each work package has to be
created anew.
According to the #10: “Organize around value” principle, we would first need to know
through which stations customer value is created. For this, a value stream mapping
would be important. This should not end at our own organizational boundaries, but
rather map the entire value flow from customer to customer. A value stream mapping
workshop (from HPS) or a value identification workshop (from SAFe) can be helpful
here.
In case you find some challenges in the organization, here are some ideas that might
work:
• Stick to the values.
• Create principles and practices for your domain. For the agile software develop-
ment you will find the principles in the Manifesto of Agile Software Development
1
Another framework are the fligthlevels described in [Leo18].
124
12.2. Agile Working at ART Level
and for agile hardware development you can use them as well and adapt them to
the hardware domain. Practices (eXtreme programming practices or MBSE2 ) are
also domain specific. I am pretty sure that the teams will already use many agile
practices even though they do not name it that way.
• Do reflection workshops (Retrospectives) often and regularly
• Test your improvement ideas, run experiments
• Collaborate with the management
• Use the methods as described, if they fail you found a symptom, look for the root
cause
• Ask: What are the reasons for ..., What have you tried to ...,
12.2. Agile Working at ART Level

As written in Accountability of the Scrum Master in SAFe the task of a Scrum Master
will be enriched by working in a scaled environment beyond the team level. She will
help with working on ART-Level by estimating Features and Capabilities, as well as
collaborate with the RTE for the Program Increment events, Inspect & Adapt and the PI
Planning in the IP Iteration.
Inspect & Adapt

The Scrum Masters together with the Release Train Engineer (RTE) prepares the PI
System Demo by ensuring that all increments from the team are integrated into the
solution, by providing the information for the quantitative and qualitative measurement,
and facilitating the retrospective and problem-solving workshop.
2
Model-Based-System-Engineering
125
12. Agile@Siemens Healthineers
Program Increment Planning (PIP)
If you already participated in a PI Planning, what are your observations

or if you did not take part in a PI Planning yet, you might want to watch
the video on the right side of the page: SAFe PI Planning. Take some
notes what you hear.
Notes:

• Please share your observations from the PI Planning? We do this
• Let’s create a list of things to try to fix Scrum or Agile. We do this

Notes:
126
12.3. Bibliography
12.3. Bibliography
[Leo18] Klaus Leopold. Rethinking Agile: Why Agile Teams Have Nothing To Do With
Business Agility. LEANability PRESS, 2018.
127
Part V.
Appendix
129
A
The main purpose of education isn’t just to
receive a certification that leads to a career,
but to become a well-rounded person in so
many aspects of life.
Edmond Mbiaka
Certification & Transfer into Practice
A.1. PSM I Certification

“People that have passed PSM I and achieved certification demonstrate a fundamental
understanding of the Scrum framework, and how to apply it to maximize the value
delivered with a product. They exhibit a dedication to continued professional develop-
ment, and a high level of commitment to their field of practice. Achieving PSM I is the
minimum demonstration of knowledge any Professional Scrum Mastershould be able to
make.”1
The cost of PSM I is $200 USD. Assessment passwords are valid for one attempt, do
not expire and remain valid until used.
Open Assessment
In preparation of the certification you can take as often as you like the open assessment.
The open assessment will take 15 questions from the pool of the certification questions
and gives you 30 min to answer the questions. A good practice time is having all questions
answered in about 23 of the time, since you will have 60 min for 80 questions in the real
certification test.
Now we would run an open assessment and please note that it is not allowed to take
pictures of the questions. You may want to take a note on a question you are insecure to
ask it later.
As additional preparation books like [?] might be useful.
Discussion of the results

What questions did arise during the work on the assessment?
A.2. Transfer in Practice

Browse through your workbook and put things you want to try or improve into the
section below:
Notes:
1
From: https://www.scrum.org/professional-scrum-product-owner-certifications
130
A.3. Bibliography
A.3. Bibliography
Books
Additional Reading
[1] Moritz Knueppel. The Definite Guide to PSM I and PSPO I. Kindle
131
B
In a bureaucracy, serving the internal systems
and processes takes precedence over serving
customers In Agile organizations, everyone in
the organization has a clear line of sight to the
ultimate customer or user and can see how
work is adding value to that customer or user–
Manifestos
or not
Stephen Denning
B.1. Manifesto of Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
©2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
132
B.1. Manifesto of Agile Software Development
We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
133
B. Manifestos
B.2. Manifesto of Agile Marketing

We are discovering better ways of creating value for our customers and for
our organizations through new approaches to marketing1
Through this work, we have come to value:
Validated learning over opinions and conventions
Customer focused collaboration over silos and hierarchy
Adaptive and iterative campaigns over Big-Bang campaigns
The process of customer discovery over static prediction
Flexible vs. rigid planning
Many small experiments over a few large bets
This declaration may be freely copied in any form, but only in its entirety through
this notice.
Principles
While we did not vote on the principles during Sprint Zero,
we did produce the following candidates. They
elaborate on the values.
#1 Our highest priority is to satisfy the customer through early and contin-
uous delivery of marketing that solves problems
#2 We welcome and plan for change. We believe that our ability to quickly
respond to change is a source of competitive advantage
#3 Deliver marketing programs frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale
#4 Great marketing requires close alignment with the business people, sales
and development
#5 Build marketing programs around motivated individuals. Give them
the environment and support they need, and trust them to get the job
done
#6 Learning, through the build-measure-learn feedback loop, is the primary
measure of progress
#7 Sustainable marketing requires you to keep a constant pace and pipeline
Don’t be afraid to fail; just don’t fail the same way twice
#9 Continuous attention to marketing fundamentals and good design en-
hances agility
#10 Simplicity is essentially
1
https://agilemarketingmanifesto.org
134
B.3. The Manifesto of Agile Hardware Development
B.3. The Manifesto of Agile Hardware Development

Joe Justice, an American Scrum Master, wrote the Agile Manifesto for Hardware2 . This
manifesto adapts the principles of the one for the software described above. To allow
changes to be made even late during the process and to reduce costs, it proposes four
principles3 :
• The project has to be modularized.
• The use of production tools that allow flexibility.
• The use of few materials and which are compatible with the fastest tools available
to us.
• The use of minimalist design (which is still elegant).
As a first step, the project should be modularized. Each module should be designed
independently of all others, this reduces the risk for the overall project. Teams can thus
develop independently of each other.
The interfaces and connections must ensure the independence of the modules. The
overall design must already address this. All modules are continuously integrated to
always have a look at the overall system. This integration should be highly automated.
Improvement of the product is ensured by continuous testing of the individual mod-
ules as well as the overall system. Joe Justice suggests using the method of test data
development and data-driven development, and using the Internet of Things (IOT) as
much as possible to analyze the projects.
The teams are constantly working to improve communication and collaborative work.
As also called for in the Agile Software Development Manifesto, at the end of each
sprint there must be a potentially deliverable product, which can be a working physical
or virtual prototype. This must be able to be demonstrated to (potential) customers
and tested by them. For example, augmented reality can facilitate this prototyping and
iteration scheme, reducing costs.
All teams involved in this are Scrum teams. Joe even worked with rolling POs on the
teams.
B.4. The Manifesto of Agile Sales

One of the most popular slides in Barkey’s presentations is a version of the Agile Mani-
festo4 , adapted for sales, thus:
• Our priority is to create value for the client through valuable insights and recom-
mendations
2
https://www.scruminc.com/scrum-in-hardware-guide/
3
Taken from: The 2008 Agile Manifesto for Hardware
4
Taken from https://resources.scrumalliance.org/Article/agile-in-sales
135
B. Manifestos
• We welcome changing requirements, even late in a sale. We harness change for

advantage.
• Sales teams deliver progression around the buying cycle frequently (weeks rather
than months)
• Clients and salespeople must work together, if possible daily, through the sale
• Motivated sales teams are given the environment and support they need and
trusted to act
• Face-to-face conversation is the most efficient and effective form of communication
• Progression around the buying cycle is the primary measure of progress
• Agile selling promotes sustainability, with teams able to maintain a constant pace
indefinitely
• Continuous attention to behavioral excellence and good sales strategy enhances

agility
• Simplicity—the art of maximizing the amount of work not done—is essential
• The best understanding of needs and positioning of solutions emerges from self-
organizing teams
• The team reflects regularly on how to become more effective, and adjusts accord-
ingly
B.5. Bibliography
2021-02-09.
136
C
Given the choice between an extremely skilled
loner and a competent-but-social programmer,
XP teams consistently choose the more social
candidate. The best interviewing technique is
to have the candidate work with the team for a
day. Pair programming provides an excellent
Team Development
test of technical and social skills.
Kent Beck
How to grow a team? There are many ideas out there, but there is one that resonates
best with me. That is the idea of communication paths, which are directly reflected in
the structure of our product.1
An agile team needs to be small and focused on delivering end-to-end functionality
that is visible to the user. The team must be composed of the right people and be careful
not to overload itself by dividing it between different topics.
C.1. Team Size

Amazon[Deu04] talks about team sizes in terms of pizza: A two-pizza team. The best
size is 7 ± 2 people per team since the number of communication paths will grow
exponentially with the team size.
People Communication Paths

1 0
2 1
3 3
4 6
5 10
6 15
7 21
8 28
9 36
10 45
Table C.1.: Communication Paths
We will often take over an existing team2 as Team Facilitator or Scrum Master. What
will first check is the size of the team (How many pizzas do I have to order?)? If we have
1
Conway’s Law (1968): Any organization that designs a system (defined broadly) will produce a design
whose structure is a copy of the organization’s communication structure. — Melvin E. Conway.
2
Growing team from scratch might happen only in a start-up environment.
137
C. Team Development
to order more than two pizzas we might want to split the team, so that the size of the
team will fit to our recommendation.
A good idea would be to form feature teams, teams that can work on any feature/user
story in our backlog, i.e. we have a cross-functional team. Secondly, we make sure that
the team members have all the skills needed to do all the necessary steps to build the
product, from analysis, implementation and testing to deployment in production. Does
that seem impossible for products at Siemens Healthineers? We will have a section on
scaling where we will talk about a team of teams.
There might be cases where we will use component teams, but this will be rare cases.
Team topologies are discussed in more detail in [SP19]. Nevertheless, there are some
occasional benefits (taken from [Coh09] (p. 186)) for having a component team:
• The component team will build something that will be used by multiple feature
teams.
• Using a component team will reduce sharing of specialists — reduction of frag-

menting their work time.
• Build a shared component — feature teams might build different solutions for one
common problem.
The decision how the team is structured will be done by the team according to the work
coming from the backlog. Nevertheless, since the team is working on technical decisions
they will need guidance from the team coach (Scrum Master) how to design its structure.
[Coh09]
The focus for the team structure should clearly be on getting the right people on the
team, i.e.,
• have developers, analysts, testers, etc. in the team
• have a mixture of skill set
• have a mixture of domain knowledge
• strive for diversity, e.g., age, cultural background, etc.
• strive for stable team setup
• strive for one-project assignment of people
C.2. Development Stages of a Team

In the year 1965 research about the sequence of development in small groups was
published [Tuc65]. Bruce Tuckman described in this paper a proposed sequence how
a group of people will be transformed into a team by going through 4 stages and get
dissolve in a fifth stage.
138
C.2. Development Stages of a Team
In the first stage orientation to the task the people in the group will identify the task and
figure out the way to finish the task by using the group experiences.
Next stage intragroup conflict is marked by hostility against everybody in and outside
the group and resistance towards group formation.
In the third stage development or group cohesion the group members start to accept each
other and their individual characteristics. The group is now becoming an entity and
creates norms to secure the existence of this group. Harmony is very important and
conflicts are mostly avoided.
The last stage in Tuckman’s model is functional role-relatedness, which shows that the
group formed in stage three now transform itself into a problem-solving instrument.
The members are now clearly focused on the objects since the relationship between each
member is already established. Tuckman call this team a “sounding board”.
The stage five is added to start the circle of team founding again. It is more or less a
reset to stage one.
There is a little drawback with the model, it is broadly used to tell about team growing,
but it was never approved that teams are going through all these stages3 and his test
objects were group-therapy participants who were seeking help with their personal
problems.
In Phil Jackson and Dave Logan’s books ([JD14], [LKF11]) describe how to form a
team or tribal.
Here are some of the major aspects by Phil Jackson:
• Lead from inside out
• Bench the ego
• Let each player discover his own destiny
• The road to freedom is a beautiful system
• Turn the mundane into the sacred
• One breath = one mind
• The key to success is compassion
• Keeping your eye on the spirit, not on the scoreboard
• Sometimes you have to pull out the big stick
• When in doubt, do nothing
• Forget about the ring
3
By the way: Tuckman himself wrote that this is a proposed sequence
139
C. Team Development
Dave Logan characterizes teams by these stages

Stage Theme Mood
1 “Life sucks!” Despaired hostility — a mind-set that creates
street gangs
2 “My life sucks!” Apathetic victim — the team members are
passively antagonistic, one cannot ignite pas-
sion in them
3 “I’m great (and you’re Lone warrior — knowledge counts and gets
not).” hoarded
4 “We’re great (and Tribal pride — No corporate cult here.
they’re not).”
5 “Life is great!” Innocent wonderment.
C.3. Introduce Agile with an Existing Team

Introducing agile values and principles to an existing team can be done the hard way
by being very dogmatic or just using the principles from the Kanban chapter (Kanban:
Start with what you have Now).
Many teams I worked with have already some ideas of agile working implemented, in
some cases they just don’t know that these are agile methods. The idea here is to enforce
already existing practices by creating a supporting environment and bring new things in
at suitable times.
E.g., I had the idea of train my team in reading cumulative flow diagramsCumulative
Flow Diagram and thought that a good starting point would be the iteration planning
(sprint planning) since there we needed the information most. By bringing the need and
the information together you can form an ideal match.
Always look for chances to bring in new ideas but not while you just read about some.
The team has to have time to reflect on the practice and must have a real benefit from
using it.
C.4. Role of the Management4

During the Agile Transition, which will often be triggered by the management all Agile
Teams learn, that they are self-managed/-organized. Teams might find the involvement
of the management not welcome (this is a big culture change5 ) but the manager are the
only persons in the organization to have the power to initiate this.6
The idea to “sustain a management function that can act from a position of power to
initiate, and take responsibility for, radical changes in the organization, and deal with
impediments that may be too weighty for the” Team Facilitator “or Product Owner in
4
Following the ¶6 from [SC+ 19].
5
See “Rule Number Four: Great People can Manage Themselves” in [Ham03]
6
Why Managers Matter: https://www.forbes.com/sites/jaysullivan/2018/04/12/why-managers-
matter/?sh=17db0c2c70fe
140
C.4. Role of the Management
the” Agile “Team” [SC+ 19] (p. 38) is currently the main approach. “Management can
play a key role in innovation: of thinking in directions that product management (PO)
might threaten to its own existence.” [SC+ 19] (pp. 38–39)
There is a list of things management can do in an agile organization:
Manager
• can be the last escalation step esp. for organizational impediments
• can facilitate and coordinate multiple products
• help by conflict of stakeholders with a team
• can lead a Community of Practice (CoP)
• can do radical redirection
• will work on the root causes instead letting the team working on the symptoms
Manager have skills that are necessary to grow and develop an organization, e.g., by
initiating a policy to remove product direction decisions from a sales and marketing
organization that has become to powerful, and shift the responsibility to the PO. Topics
that might be traditionally Team Facilitator (Scrum Master) responsibilities but effecting
the whole organization can be implemented effective because of the position and power.
When we look at the result of the Project Oxygen at Google [Gar13], we see that a
good manager
1. is a good coach
2. empowers the team and does not micromanage
3. expresses interest in and concern for team members’ success and personal well-
being
4. is productive and results-oriented
5. is a good communicator—listens and shares information
6. helps with career development
7. has a clear vision and strategy for the team
8. has key technical skills that help him or her advice the team.
Eric Ries [Rie17] sees it in that way, entrepreneurial success is often tied to the myth of
“perseverance, creative genius, and hand work,” whereas in reality “it’s the boring stuff
that matters the most . . . Entrepreneurship is a kind of management.”
Finally, management should respect the new responsibilities of the Product Owner
and Team Facilitator by using their power to support organizational development and
help the organization and its products flourish by acting in trust and openness.
141
C. Team Development
C.5. Bibliography
[App11] Jurgen Appelo. Management 3.0 — Leading Agile Developers, Developing Agile
Leaders. Addison-Wesley, 2011.

[Coh09] Mike Cohn. Succeeding with Agile: Software Development Using Scrum. Pearson
Education, 2009.
[DeM16] Tom DeMarco. Peopleware: Productive Projects and Teams. Addison-Wesley,

2016.
[Deu04] Alan Deutschmann. Inside the Mind of Jeff Bezos. Fast Company, 2004. last
visited: 2021-03-02.
[Gar13] David A. Garvin. How Google Sold Its Engineers on Management. Harvard
Business Review, 2013. last visited: 2021-03-09.
[Hac02] J. Richard Hackman. Leading Teams: Setting the Stage for Great Performances.
Harvard Business Review Press, 2002.
[Ham03] Keith H. Hammonds. How Google Grows and Grows and Grows. Fast
Company, 2003. last visited: 2021-03-09.
[JD14] Phil Jackson and Hugh Delehanty. Eleven Rings: The Soul of Success. Penguin
Books, 2014.
[KKSW18] Karen Kimsey-House, Henry Kimsey-House, Phillip Sandhal, and Laura

Whitworth. Co-Active Coaching. Nicholas Brealey, 2018.
[Len02] Patrick M. Lencioni. The Five Dysfunctions of a Team: A Leadership Fable.

Jossey-Bass, 2002.
[LKF11] Dave Logan, John King, and Halee Fischer-Wright. Tribal Leadership: Lever-
aging Natural Groups to Build a Thriving Organization. Harper Business, 2011.
2019.
[Sch16] Roger M. Schwarz. The Skilled Facilitator: A Comprehensive Resource for Con-
sultants, Facilitators, Coaches, and Trainers. Jossey-Bass, 2016.
142
C.5. Bibliography
[Tuc65] Bruce W. Tuckman. Developmental Sequence In Small Groups. Psychological

Bulletin 1965, Vol. 63, No. 6, p. 384-399, 1965. last visited: 2021-03-04.
Blogs and Webpages

[1] Guide Understand Team Effectiveness https://rework.withgoogle.com/guides/understanding-
team-effectiveness/steps/introduction/. Last accessed: 21.4.2021
[2] For an Agile Transformation, Choose the Right People https://hbr.org/2021/03/for-

an-agile-transformation-choose-the-right-people. Rob Cross, Heidi K. Gardner,
and Alia Crocker. HBR Magazine 2021-03
[3] Psychologische Sicherheit. Ralf Lethmate. Agile Review. Ausgabe 1/2021.

https://www.itagileshop.de/lesen/agile-review/2021-01-sag-nein/#cc-m-
product-12005932598
[4] Google project oxygen—8 point plan to help managers https://rapidbi.com/google-

project-oxygen-8-point-plan-to-help-managers/. 2012
143
D
We start from the presumption that our people
are talented and want to contribute. We accept
that, without meaning to, our company is stifling
that talent in myriad unseen ways. Finally, we
try to identify those impediments and fix them.
Ed Catmul - President of Pixar Animation
Infra- and Organizational Structure

Studio
D.1. Servant Leadership

1. Commitment to put yourself last
2. Focus on the greatness of others
3. Respect other people’s needs to be fully human
4. Courage to speak the truth
5. Openness about own vulnerability
https://www.scrum.org/resources/blog/what-servant-leadership
D.2. Self-Organizing Team

Self-management requires two critical ingredients:
• An absence of traditional management.
• A light set of constraints. Constraints help balance autonomy with accountability.

Constraints might be a Sprint, a Sprint Review, a social contract or a facilitated
meeting.
D.3. Team Facilitation

1. Ensure that everyone participating in the discussion understand its purpose. You
would need to set the context at the beginning and may have to reiterate once in a
while when you see that the discussions are digressing from the context.
2. Working agreement at the beginning will help. E.g., mobile/ electronics usage,
punctuality, participant expectations, etc. Listing the Scrum values, especially if
you are going to deal with conflict resolution may help the discussion.
3. If the event/ meeting is not interactive, you may want to spend some time take
some time to find the Root Cause.
144
D.4. How Agile is a Software Team?
4. Create a safe environment for people to speak by ensuring that people focus on
task at hand rather than pointing fingers. Immediately interject if there are any
personal attacks.
5. Use time-boxes to ensure that discussions are productive.
6. Balance the discussions so that introverts feel included in the discussions.
7. As a facilitator, you need to read the mood in the room to take breaks at regular
intervals to keep the energy level high for productive discussion.
8. Be neutral in your stance and do not take sides (beware of your implicit bias during
heated discussions
Liberating Structures
Liberating Structures1 inject tiny shifts in the protocols of how we meet, plan, decide and
relate to each other that put in the hands of everyone the facilitative power once reserved
for experts only.
D.4. How Agile is a Software Team?2

The team
• can introduce you to their stakeholders, who actively participate on the project.
• can show and run their regression test suite.
• produce working software on a regular basis.
• write high-quality code that is maintained under configuration management con-

trol.
• welcome and respond to changing requirements.
• take responsibility for failures as well as successes.
• automate the drudgery out of their work.
My experience is that if the team can’t immediately fulfill the first two criteria,
then there’s a 95% chance that they are not agile. — Scott Amber
1
http://www.liberatingstructures.com/ls
2
https://www.drdobbs.com/the-agile-edge-how-agile-are-you/184415445
145
D. Infra- and Organizational Structure
D.5. A Great Developer in a Scrum Team

• Pursues technical excellence.
• Applies team swarming.
• Uses spike solutions.
• Refines the product backlog as a team.
• Respects the Boy Scout Rule
• Criticizes ideas, not people
• Share experiences.
• Understands the importance of having some slack.
• Has fun with each other
• Don’t have any Scrum meetings
• Knows their customer
• Trust each other.
• Keep the retrospective fun
• Deliver features during the sprint
• Don’t need a sprint 0.
• Acts truly cross-functional.
• Updates the Scrum board themselves.
• Spends time on innovation
• Don’t need a Definition of Done.
• Knows how to give feedback.
• Manages their team composition.
• Practice collective ownership.
• Fix dependencies with other teams.
• Don’t need story points.
Boy Scout Rule: https://deviq.com/boy-scout-rule

Spike Solutions: http://www.extremeprogramming.org/rules/spike.html
146
D.6. A Great Product Owner in a Scrum Team
D.6. A Great Product Owner in a Scrum Team

• Embraces, shares and socializes the product vision
• Exceeds the customer’s expectation
• Is empowered
• Orders the product backlog
• Prefers face-to-face communication
• Knows modeling techniques
• Shares experiences
• Owns user story mapping
• Has a focus on functionality
• Is knowledgeable
• Understands the business domain
• Acts on different levels
• Knows the 5 levels of Agile planning (vision, product road map, release plans,
Sprint Planning, Daily Scrum)
• Is available
• Is able to say “no”
• Acts as a “Mini-CEO”
• Knows the different types of valid Product Backlog items
• Takes Backlog Refinement seriously
D.7. A Great Scrum Master in a Scrum Team

• Involves the team with setting up the process
• Understands team development
• Understands principles are more important than practices
• Recognizes and acts on team conflict
• Dares to be disruptive
147
D. Infra- and Organizational Structure
• Is aware of the smell of the place
• Is both dispensable and wanted
• Let his team fail (occasionally)
• Encourages ownership
• Has faith in self-organization
• Values rhythm
• Knows the power of silence
• Observes
• Shares experiences
• Has a backpack full of different retrospective formats
• Can coach professionally
• Has influence at organizational level
• Prevent impediments
• Isn’t noticed
• Forms a great duo with the Product Owner
• Allows leadership to thrive
• Is familiar with gamification
• Understands there’s more than just Scrum
• Leads by example
• Is a born facilitator
https://www.scrum.org/resources/blog/28-characteristics-great-scrum-master
D.8. A Day in the Life of a Scrum Master

1. How is my Product Owner doing?
• In which shape is the Product Backlog?
• How is she managing the stakeholders?
• What about delivering business value and return-on-investment?
148
D.9. Bibliography
2. How is the Development Team doing?

• How are they working together?
• What conflicts do we have and how do we resolve that?
• What decisions does the team make?
3. How are our engineering practices doing?

• What is the team caring about and currently improving?
• How is the test automation?
• What does the team add/remove to/from the Definition of Done?
4. How is my organization doing?

• How is the inter-team coordination working?
• What organizational impediments are in the way?
• What about the HR practices?
D.9. Bibliography
Videos
[1] Greatness, David Marquet: https://youtu.be/OqmdLcyES Q
[2] This is What Made Steve Jobs EXCEPTIONAL!: https://youtu.be/rQKis2Cfpeo
[3] Building Apple - Steve Jobs on hiring and organization: https://youtu.be/uejsAqV0RFY
149
E
Frameworks should be extracted from a collec-
tion of successful implementations, not built on
speculation.
Mary Poppendieck
Agile Frameworks
E.1. SCRUM
E.1.1. Definition
Scrum is a process framework used to manage product development and other knowledge
work. Scrum is empirical in that it provides a means for teams to establish a hypothesis
of how they think something works, try it out, reflect on the experience, and make
the appropriate adjustments. That is, when the framework is used properly. Scrum is
structured in a way that allows teams to incorporate practices from other frameworks
where they make sense for the team’s context1 .
E.1.2. A Kick-Start-Guide for Scrum

(taken from [Sut14] (p. 234))
1. Pick a Product Owner. This person is the one with the vision of what you are
going to do, make, or accomplish. They take into account risks and rewards, what
is possible, what can be done, and what they are passionate about.
2. Pick a Team. Who will be the people actually doing the work? This team needs to
have all the skills needed to take the Product Owner’s vision and make it reality.
Teams should be small, 3 to 9 people is the rule of thumb.
3. Pick a Scrum Master. This is the person who will coach the rest of the team through
the Scrum framework, and help the team eliminate anything that is slowing them
down.
4. Create and prioritize a Product Backlog. This is a list at a high level of everything
that needs to be built or done to make that vision reality. This backlog exists and
evolves over the lifetime of the product; it is the product road map. At any point,
the Product Backlog is the single, definitive view of “everything that could be done
by the team ever, in order of priority.” Only a single Product Backlog exists; this
means the Product Owner is required to make prioritization decisions across the
entire spectrum. The Product Owner should consult with all stakeholders and the
1
Taken from https://www.agilealliance.org/glossary/scrum/
150
E.1. SCRUM
team to make sure they are representing both what people want and what can be
built.
5. Refine and Estimate the Product Backlog. It is crucial that the people who are
actually going to complete items in the Product Backlog estimate how much effort
they will take. The team should look at each Backlog item, and see if it is actually
doable. Is there enough information to complete the item? Is it small enough
to estimate? Does a Definition of Done exist, and does everyone agree on what
standards must be met to call something “done”? Does it create visible value? Each
item must be able to be shown, to be demonstrated, hopefully to be potentially
shippable. Do not estimate the Backlog in hours, because people are absolutely
terrible at that. Estimate by relative size: Small, Medium, or Large. Or even better
use the Fibonacci sequence and estimate the point value for each item: 1, 2, 3, 5, 8,
13, 21, etc.
6. Sprint Planning. This is the first of the Scrum meetings. The team the Scrum
Master, and the Product Owner sit down to plan the Sprint. Sprints are always
a fixed length of time that is less than a month. Most people now run one- or
two-week Sprints. The team looks at the top of the Backlog and forecasts how
much of it they can complete in this Sprint. If the team has been going for a few
Sprints, they should take in the number of points they did in the last Sprint. That
number is known as the team’s Velocity. The Scrum Master and the team should
be trying to increase that number every Sprint. This is another chance for the team
and the Product Owner to make sure that everyone understands exactly how these
items are going to fulfill the vision. Also, during this meeting everyone should
agree on a Sprint Goal, what everyone wants to accomplish with the Sprint.
One of the pillars of Scrum is that once the team has committed to what they think
they can finish in one Sprint, that’s it. It cannot be changed, it cannot be added to.
The team must be able to work autonomously throughout the Sprint to complete
what they forecast they could.
7. Make Work Visible. The most common way to-do this in Scrum is to create a
Scrum Board with three columns: To Do, Doing, Done. Sticky notes represent the
items to be completed, and the team moves them across the Scrum board as they
completed, one by one.
Another way to make work visible is to create a Burndown Chart. On one axis is
the number of points the team has taken into the Sprint, on the other is the number
of days. Every day the Scrum Master tallies up the number of points completed
and graphs them on the Burndown chart. Ideally there will be a steep downward
slope leading to zero points left on the last day of the Sprint.
8. Daily Stand-up or Daily Scrum. This is the heartbeat of Scrum. Each day, at the
same time, for no more than fifteen minutes, the team and the Scrum Master meet
and answer these questions:
151
E. Agile Frameworks
• What did you do yesterday to help the team finish the Sprint?
• What will you do today to help the team finish the Sprint?
• Is there any obstacle blocking you or the team from achieving the Sprint Goal?
That’s it. That’s the whole meeting. If it takes longer than fifteen minutes, you’re
doing it wrong. This helps the whole team to know exactly where everything is in
the Sprint and whether all tasks are completed on time. Are there opportunities
to help other team members overcome obstacles? There’s no assigning of tasks
from above—the team is autonomous; they do that. There’s no detailed reporting
to management. The Scrum Master is responsible for making the obstacles to the
team’s progress, or impediments, go away.
9. Sprint Review or Sprint Demo. This is the meeting where the team shows what
they have accomplished during the Sprint. Anyone can come, not only the Product
Owner, the Scrum Master, and the team, but stakeholders, management, customers,
whoever. This is an open meeting where the team demonstrates what they were
able to move to Done during the Sprint.
The team should only demo what meets the Definition of Done. What is totally
and completely finished and can be delivered without any more work. It may not
be a completed product, but it should be a completed feature of one.
10. Sprint Retrospective. After the team has shown what they’ve accomplished dur-
ing the last Sprint—that thing that is “done” and can potentially be shipped to
customers for feedback—they sit down and think abaout what went right, what
could have gone better, and what can be made better in the next Sprint. What is
the improvement in the process that they, as a team, can implement right away?
To be effective, this meeting requires a certain amount of emotional maturity and
an atmosphere of trust. They key thing to remember is that you’re not seeking
someone to blame; you’re looking at the process. Why did that happen that way?
Why did we miss that? What could make us faster? It is crucial that people as a
team take responsibility for their process and outcomes., and seek solutions as a
team. At the same time, people have to have the fortitude to bring up the issues that
are really bothering them in a way that is solution oriented rather than accusatory.
And the rest of the team has to have the maturity to hear the feedback, take it in,
and look for a solution rather than getting defensive.
By the end of the meeting the team and the Scrum Master should agree on one
process improvement that they will implement in the next Sprint. That process
improvement, sometimes called the kaizen, should be put into the next Sprint’s
backlog, with acceptance tests. That way the team can easily see if they actually
implemented the improvement, and what effect it had on velocity.
11. Immediately start the next Sprint cycle, taking the Team’s experience with impedi-
ments and process improvements into account.
152
E.2. Nexus Framework
E.1.3. Seven Common Scrum Dysfunctions

Undone Scrum The team is not able to create a ”Done”Product
increment at the end of the Sprint
Zombie Scrum Just checking the boxes on the Scrum checklist
Dogmatic Scrum Team is following the best practices presented
by an expert
One-Size-Fits-All Scrum Standardize Scrum organization-wide
Water-Fall-Scrum Up-front requirements and later test cycles
Good Enough Scrum The team gets some benefits from regular plan-
ning but tolerates organizational impediments
Snowflake Scrum Adapt Scrum to fit their needs
E.2. Nexus Framework

[Bit17]
A Nexus is a group of approximately three to nine Scrum Teams that work together to
deliver a single product; it is a connection between people and things. A Nexus has a
single Product Owner who manages a single Product Backlog from which the Scrum
Teams work.
The Nexus framework defines the accountabilities, events, and artifacts that bind and
weave together the work of the Scrum Teams in a Nexus. Nexus builds upon Scrum’s
foundation, and its parts will be familiar to those who have used Scrum. It minimally
extends the Scrum framework only where absolutely necessary to enable multiple teams
to work from a single Product Backlog to build an Integrated Increment that meets a
goal.
The Nexus Guide2 describes the Nexus Framework in more detail.
E.3. LeSS
[LV08, LV10]
LeSS provides two different large-scale Scrum frameworks. Most of the scaling ele-
ments of LeSS are focused on directing the attention of all the teams onto the whole
product instead of ”my part”. Global and “end-to-end” focus are perhaps the dominant
problems to be solve in scaling. The two frameworks, which are basically single-team
Scrum scaled up are:
LeSS - Up to eight teams (of eight people each).
LeSS Huge - Up to a few thousand people on one product
For more detailed information see: https://less.works/
2
https://www.scrum.org/resources/online-nexus-guide
153
E. Agile Frameworks
E.4. SAFe
[KL20, Lef11]
“SAFe® for Lean Enterprises is a knowledge base of proven, integrated principles,
practices, and competencies for achieving business agility using Lean, Agile, and DevOps.
The latest version, SAFe 5, is built around the Seven Core Competencies of the Lean
Enterprise that are critical to achieving and sustaining a competitive advantage in an
increasingly digital age:
Lean-Agile Leadership Advancing and applying Lean-Agile leadership skills that

drive and sustain organizational change by empowering individuals and teams to reach
their highest potential
Team and Technical Agility Driving team Agile behaviors as well as sound technical
practices including Built-in Quality, Behavior-Driven Development (BDD), Agile testing,
Test-Driven Development (TDD), and more
Agile Product Delivery Building high-performing teams-of-teams that use design

thinking and customer-centricity to provide a continuous flow of valuable products
using DevOps, the Continuous Delivery Pipeline, and Release on Demand
Enterprise Solution Delivery Building and sustaining the world’s largest software
applications, networks, and hyper-physical solutions
Lean Portfolio Management Executing portfolio vision and strategy formulation, char-
tering portfolios, creating the Vision, Lean budgets and Guardrails, as well as portfolio
prioritization, and road-mapping
Organizational Agility Aligning strategy and execution by applying Lean and systems
thinking approaches to strategy and investment funding, Agile portfolio operations, and
governance
Continuous Learning Culture Continually increasing knowledge, competence, and

performance by becoming a learning organization committed to relentless improvement
and innovation” ©Scaled Agile, Inc.
For more information on SAFe goto the scaledagileframework web page3 or attend
one of the Scaled Agile training courses.
3
https://scaledagileframework.com
154
E.5. Other Frameworks
E.5. Other Frameworks

There are a lot more frameworks available, e.g. DSDM, Adaptive Software Develop-
ment, Crystal Clear, Feature-Driven Development, Pragmatic Programmingand Extreme
Programming.
All of these frameworks are part of the umbrella term “Agile”. They share the same
values, ideas and mostly the same principles.
E.6. Bibliography
[Bit17] Kurt Bittner. The Nexus Framework for Scaling Scrum: Continuously Delivering
an Integrated Product with Multiple Scrum Teams. Addison-Wesley Profes-
sional, 2017.

[KL20] Richard Knaster and Dean Leffingwell. SAFe® 5.0 Distilled. Addison-Wesley,
2020.

[LV08] Craig Larman and Bas Vodde. Scaling Lean & Agile Development: Thinking
and Organizational Tools for Large-Scale Scrum. Addison-Wesley Professional,
2008.
[LV10] Craig Larman and Bas Vodde. Practices for Scaling Lean & Agile Development:
Large, Multisite, and Offshore Product Development with Large-Scale Scrum.
Addison-Wesley Professional, 2010.
155
F
To be uncertain is to be uncomfortable, but to
be certain is to be ridiculous.
Chinese proverb
Estimation Methods
F.1. Planning Poker1

Planning poker, also called Scrum poker, is a consensus-based, gamified technique
for estimating, mostly used to estimate effort or relative size of development goals in
software development. In planning poker, members of the group make estimates by
playing numbered cards face-down to the table, instead of speaking them aloud. The
cards are revealed, and the estimates are then discussed. By hiding the figures in this
way, the group can avoid the cognitive bias of anchoring, where the first number spoken
aloud sets a precedent for subsequent estimates.
Planning poker is a variation of the Wideband delphi method. It is most commonly
used in agile software development, in particular in Scrum and eXtreme Programming.
The method was first defined and named by James Grenning in 20022 and later pop-
ularized by Mike Cohn in the book Agile Estimating and Planning [Coh05], whose
company trade marked the term3 and a digital online tool4 .
Rationale
The reason to use planning poker is to avoid the influence of the other participants. If a
number is spoken, it can sound like a suggestion and influence the other participants’
sizing. Planning poker should force people to think independently and propose their
numbers simultaneously. This is accomplished by requiring that all participants show
their cards at the same time.
Equipment
Planning poker is based on a list of features to be delivered, several copies of a deck of
cards and optionally, an egg timer that can be used to limit time spent in discussion of
each item.
The feature list, often a list of user stories, describes some software that needs to be
developed.
1
Take from https://en.wikipedia.org/wiki/Planning poker
2
https://wingman-sw.com/articles/planning-poker
3
http://tsdr.uspto.gov/#caseNumber=3473287&caseType=US REGISTRATION NO&searchType=statusSearch
4
https://www.mountaingoatsoftware.com/tools/planning-poker
156
F.1. Planning Poker
The cards in the deck have numbers on them. A typical deck has cards showing the
Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc. ; other decks use
similar progressions with a fixed ratio between each value such as 1, 2, 4, 8, etc.
The reason for using the Fibonacci sequence instead of simply doubling each subse-
quent value is because estimating a task as exactly double the effort as another task is
misleadingly precise. A task that is about twice as much effort as a 5, has to be evaluated
as either a bit less than double (8) or a bit more than double (13).
Several commercially available decks use the sequence: 0, 12 , 1, 2, 3, 5, 8, 13, 20, 40, 100,
and optionally ”?” (unsure), an infinity symbol (this task cannot be completed), and a
coffee cup (I need a break, and I will make the rest of the team coffee). The reason for not
exactly following the Fibonacci sequence after 13 is because someone once said to Mike
Cohn ”You must be very certain to have estimated that task as 21 instead of 20.” Using
numbers with only a single digit of precision (except for 13) indicates the uncertainty in
the estimation. [...]
When teams are not in the same geographical locations, collaborative software over
the internet can be used as replacement for physical cards. Several web applications and
mobile applications exist for the purpose, including open source software5 with a gratis
demo server available for everyone to use6 .
Procedure
At the estimation meeting, each estimator is given one deck of the cards. All decks have
identical sets of cards in them.
The meeting proceeds as follows:
A Moderator, who will not play, chairs the meeting.
1. The Product Owner provides a short overview of one user story to be estimated. The
team is given an opportunity to ask questions and discuss clarifying assumptions
and risks. A summary of the discussion is recorded, e.g. by the Moderator.
2. Each individual lays a card face down representing their estimate for the story.
Units used vary - they can be days duration, ideal days or story points. During
discussion, numbers must not be mentioned at all in relation to feature size to avoid
anchoring.
3. Everyone calls their cards simultaneously by turning them over.
4. People with high estimates and low estimates are given a soap box to offer their
justification for their estimate and then discussion continues.
5. Repeat the estimation process until a consensus is reached. The developer who was
likely to own the deliverable has a large portion of the ”consensus vote”, although
the Moderator can negotiate the consensus.
5
https://dalibornasevic.com/posts/75-playing-planning-poker-with-firepoker
6
https://firepoker.io/
157
F. Estimation Methods
To ensure that discussion is structured; the Moderator or the Product Owner may at any
point turn over the egg timer and when it runs out all discussion must cease and another
round of poker is played. The structure in the conversation is re-introduced by the soap
boxes.
The cards are numbered as they are to account for the fact that the longer an estimate
is, the more uncertainty it contains. Thus, if a developer wants to play a 6 he is forced to
reconsider and either work through that some perceived uncertainty does not exist and
play a 5, or accept a conservative estimate accounting for the uncertainty and play an 8.
Tip: To speed up the procedure, it can be agreed that at a distance of one unit, the
average of all cards is formed, e.g. the cards show 3 times an 8 and 5 times a 5, average
would be: 6.125, thus one would enter a 6 as estimation.
F.2. Magic Estimation7

©2015 wibas GmbH
Summary
Magic Estimation is an estimation technique that is quick. It is especially useful to quickly
estimate many items.
The benefits of Magic Estimation are the speed (due to only non-verbal communication)
and the subjectivity with which each team member can look at the process. Magic
Estimation provides the Product Owner with a good overview of the degree of complexity
of the Product Backlog entries and which still need to be broken down, so that they can
be delivered in a Sprint.
Description
The Setup
Initially, the moderator (e.g. the Scrum Master) places all Planning Poker cards on a
large table. All items that need to be estimated are placed on the table also.
First Step
In the first step, everyone places the item to be estimated next to the number he thinks it
belongs to. E.g. someone places a User Story next to the Planning Poker card ”8”, because
he estimates that the story has a complexity of ”8”. If someone estimates differently, he
moves the item to another Planning Poker card. Some items will stay where they initially
have been placed. Some items will move around between estimates. The moderator
keeps track of these items to discuss them in the second step. During the first step no
one is allowed to speak.
7
Taken from https://www.wibas.com/scrum/magic-estimation/en
158
F.3. Bibliography
Second Step
In the second step the moderator goes through the cards that have moved back and forth
between estimates. He asks the two people with the highest and the lowest estimate
to explain their reasoning. Planning Poker can be used to estimate these items more
precisely. There is no text description available, yet
Affinity Estimating
Affinity Estimating is variant of magic estimation. We start by reading out each User
Story to the entire team. The moderator then asks to arrange the stories horizontally on
a wall in order of size, without talking. The team places the largest stories on the left
and the smallest stories on the right. This only takes a few minutes. The moderator then
gives a final opportunity to make adjustments to the ordering, again without talking.
The moderator then places the Planning Poker numbers above the list of stories. He
asks the team to group the user stories around the nearest number.
Hints and Tips

Magic Estimation has the advantage that it is quick. It is especially useful for initially
estimating large amounts of items. However, it is less precise than Planning Poker. For
more precise estimates, e.g. in Sprint Planning, use Planning Poker. However, Planning
Poker is compared to Magic Estimation slower and takes much more time.
F.3. Bibliography
[Coh05] Mike Cohn. Agile Estimating and Planning. Prentice Hall, 2005.
[Dua16] Vasco Duarte. No Estimates. OikosofySeries, 2016.
159
G
When agile becomes a buzzword, then people
look for simplistic measures to judge agility.
Kent Beck
Measurement
G.1. Evidence-Based-Management
For the measurement in Scrum the Evidence-Based-Management1 (EBM) is the preferred
method.
First we have to understand what value really is. How do we measure value? In most
of the organizations activities and output get measured, e.g. the number of Story Points
per Sprint is output. How often do we do a retrospective, oh we had already hit the 100,
but nothing changed, since we are measured an activity.
Another example, working over-hours (activity) and thereby delivering more features
(output) will not result in higher customer satisfaction (outcome).
The approach of EBM, beside having hypothesis and running experiments, is to focus
on four Key Value Areas (KVA), unrealized value (the goal of the organization), current
value (the current state relative to the organization’s goals), time-to-market (the re-
sponsiveness in delivering value) and ability-to-innovate (the effectiveness of delivering
value).
Examples
1
scrum.org. Evidence-Based Management Guide. scrum.org. 2020:
https://www.scrum.org/resources/evidence-based-management
160
G.1. Evidence-Based-Management
Current Value
Revenue per Employee The ratio (gross revenue / # of
employees) is a key competitive
indicator within an industry. This varies
significantly by industry.
Customer Usage Index Measurement of usage, by feature, to
help infer the degree to which
customers find the product useful and
whether actual usage meets
expectations on how long users should
be taking with a feature.
Unrealized Value
Customer or User The difference between a customer or
user’s desired
Satisfaction Gap experience and their current experience.
Time-to-Market
Time to Restore The amount of time between the start of
a service outage and the
Service restoration of full availability of the
service (see DORA Report).
DORA Report2
2
https://www.devops-research.com/research.html#reports
161
G. Measurement
G.2. Team Dashboard
Sprint Burn-Down Diagram
Figure G.2.1.: Sprint Burn-Down
The Sprint burn-down (figure G.2.1) is an indicator of progress towards the Sprint Goal
(see 4.6). A cone can also be drawn to indicate the upper and lower limits at which
actions must be initiated. In the best case, the actual line is along the ideal line.
The sprint burn-down should never be given to anyone outside the team without
context and further information.
162
G.2. Team Dashboard
Velocity Diagram
Figure G.2.2.: Velocity
A team’s velocity (figure G.2.2) is the amount of value it can deliver in each sprint.
Whether your team is using story points, issue count, or hours to estimate their stories,
the chart will show how well you’re keeping up with your commitments. Over time,
you’ll be able to predict the amount of work you can realistically commit to and get done
in future Sprints (iterations) (see 4.5), making sure you’re not running around in panic.
163
G. Measurement
Cumulative Flow Diagram
Figure G.2.3.: Cumulative Flow Diagram
A Cumulative Flow Diagram (figure G.2.3) is an area chart that shows the various statuses
of work items for an application, version, or sprint. The horizontal x-axis indicates time,
and the vertical y-axis indicates cards (issues, amount of user stories, etc.). Each colored
area of the chart equates to a workflow status (i.e., a column on the team’s board).
It can be useful for identifying bottlenecks. If the chart contains an area that is widening
vertically over time, the column that equates to the widening area will generally be a
bottleneck.
164
G.3. Project Dashboard
G.3. Project Dashboard
Cumulative Flow Diagram
Figure G.3.1.: Cumulative Flow Diagram with WIP and cycle time
A Cumulative Flow Diagram (figure G.3.1) is an area chart that shows the various statuses
of work items for an application, version, or sprint. The horizontal x-axis indicates time,
and the vertical y-axis indicates cards (issues, amount of user stories, etc.). Each colored
area of the chart equates to a workflow status (i.e., a column on the team’s board).
It can be useful for identifying bottlenecks. If the chart contains an area that is widening
vertically over time, the column that equates to the widening area will generally be a
bottleneck.
In addition one can read the cycle time and the WIP.
165
G. Measurement
Value Burn-Up Diagram
Additional
Reading
[1] scrum.org. Evidence-Based Management Guide. scrum.org. 2020
Figure G.3.2.: Value Burn-Up Diagram
The Burn-up Chart (figure G.3.2)provides a visual representation of completed work

compared with its total scope. It offers insights on the project’s progress, as well as offers
warnings to help maintain the project’s health; one can instantly identify problems such
as scope creep or a deviation from the planned project path.
It helps to define the MMP as well as future releases.
G.4. Bibliography
[Vac15] Daniel S. Vacanti. Actionable Agile Metrics for Predictability: An Introduction.
Daniel S. Vacanti, Inc., 2015.
166
H
In a three-year period, we had 78 projects, and
77 of them were delivered on time, on budget,
and in scope. Then I surveyed the customers
and found out that none of them was happy!
Mary Poppendieck
Lean Software Development
H.1. Lean Principles

Principles are fundamental truths that do not change in time or space, while practice is
the application of principles to specific situations.[PP03]
H.1.1. Eliminate Waste
The Seven Wastes The Seven Wastes

of Manufacturing of Software Development
Inventory Partially Done Work
Extra Processing Extra Processes
Overproduction Extra Features
Transportation Task Switching
Waiting Waiting
Motion Motion
Defects Defects
Table H.1.: The seven Wastes
Partially Done Work As long as your work is not integrated into the product you do
not know if this will actually work.
Extra Processes How often do you ask; “is this paperwork really neces-
sary?”—Paperwork distracts from the real value creation and should therefore be
kept to a minimum, especially paperwork should not describe anything other than what
the product actually does.
Extra Features Every additional code adds complexity to the product and has to be
tested, maintained, documented, etc. An extra feature might become obsolete or never
used at all.
Task Switching Switching between projects eats up valuable development time. The
developer has to think about the current status of the code in the project and get back
167
H. Lean Software Development
into the flow of development. Stop working in parallel and start working serially, then
the projects will be finished faster.
Waiting There are delays in starting the project, in documentation, in reviews and
approvals, in testing, etc. These delays make the customers wait until their problem is
solved and they can then add value on their side.
Motion How much time does a developer need to spend to get an answer to a question
that arises during development time? Development is a mental task and therefore
concentration on the problem is required. Concentration is lost every time the developer
has to walk down the hall to get a question answered.
Defects How much time do you need to find defects in your product? Minutes, hours,
days, weeks? The longer the bigger the issue. Finding defects late in development will
raise the costs of fixing it.
Tools
• Seeing Waste
• Value Stream Mapping
H.1.2. Amplify Learning or Create Knowledge
Development Production
Design the Recipe Prepare the dish
Quality is fitness for use Quality is conformance to requirements
Variable results are good Variable results are bad
Iterations generate value Iterations generate waste (called rework)
Table H.2.: Development vs. Production
Quality is fitness for use If the customers can solve their problems in a easy-to-use
and cost-effective manner we delivered quality to them.
Variable results are good Software development is not intended to produce repeatable
results every time, every time the result is different since we try to solve individual
problems of the customers.
Iterations generate value Doing mistake once is not a big issue as long as we learn
from it. The customers might not be able to phrase their expectations in words we
understand and we might interpret the expectations differently. That not a problem,
that learning. In the end we know what the customers need. A failure rate is needed to
generate new information.[Rei97]
168
H.1. Lean Principles
Tools
• Feedback
• Iterations
• Synchronization
• Set-based Development
H.1.3. Decide as Late as Possible or Defer Commitment

Don’t wait until the specification is frozen, start in parallel with the specification devel-
opment the feature development and keep both in synchronization until the end of the
project.
Tools
• Options Thinking
• The Last Responsible Moment
• Making Decisions
H.1.4. Deliver as Fast as Possible

The customers wait for the problem getting solved and we need their feedback to create
the right solution for this problem. Without fast delivery we never know if the problem
is already solved.
Tools
• Pull Systems
• Queuing Theory
• Cost of Delay[Rei98]—get a good estimate from marketing about what the delay
will do to sales volumes and market shares. The model shows then what will
happen to revenue and profit.
H.1.5. Empower the Team or Respect People

“The key trust [of recent years] was delegation power down. It was like
magic! Improved quality, productivity, morale.” — Earl Wheeler, retired
head of IBM
169
H. Lean Software Development
Tools
• Self-Determination
• Motivation—Belonging, safety, competence, and progress
• Leadership
Managers Leaders
Cope with Complexity Cope with Change
Plan and Budget Set Direction
Organize and Staff Align People
Track and Control Enable Motivation
Table H.3.: Managers vs. Leaders
• Expertise
H.1.6. Build Integrity and Quality in

Perceived integrity is achieved by detailed information flow, from customers and users
to the developers. Conceptual integrity is achieved by up- and downstream technical
information flow.[3]
Tools
• Perceived Integrity—having the customer value constantly in mind while making

decisions
• Conceptual Integrity—the effectiveness of communication between different do-

mains in product development
• Refactoring
• Testing
H.1.7. See and Optimize the Whole

Think about your limits of growth and remove these. Look for problems caused by the
system’s setup. How many stages did Lance Amstrong1 win to win the Tour de France?
All, a few, none?
1999: won 4 out of 21 stages 2001: won 4 out of 21 stages
2000: won 1 out of 21 stages 2002: won 4 out of 21 stages
2003: won 1 out of 21 stages
1
Nevertheless he cheated, his strategy worked.
170
H.2. Bibliography
Tools
• Measurements—Austin’s Theory: People will try to optimize the measurement that

their performance is measured against. It is very hard to decide what is important
for the work of a knowledge worker.
“When you try to measure performance, particularly the performance of

knowledge workers, you’re positively courting dysfunction.”—Tom DeMarco
and Timothy Lister
• Contracts—Trust
“One party’s confidence that the other party . . . will fulfill its promises and
will not exploit its vulnerabilities.”—Jeffrey Dyer[4]
H.2. Bibliography
[PP03] Mary Poppendieck and Tom Poppendieck. Lean Software Development: An
Agile Toolkit. Addison-Wesley Professional, 2003.
[PP07] Mary Poppendieck and Tom Poppendieck. Implementing Lean Software De-
velopment: From Concept to Cash. Addison-Wesley Professional, 2007.
[PP10] Mary Poppendieck and Tom Poppendieck. Leading Lean Software Develop-
ment: Results are not the Point. Addison-Wesley Professional, 2010.
[PP13] Mary Poppendieck and Tom Poppendieck. The Lean Mindset: Ask the Right
Questions. Addison-Wesley Professional, 2013.
[Rei97] Donald Reinertsen. Managing the Design Factory. Free Press, 1997.
[Rei98] Donald Reinertsen. Developing Products in Half the Time. Van Nostrand
Reinhold, 1998.
Additional Reading
[1] The Product Development Performance: Strategy, Organization, and Management
in the World Auto Industry; Kim B. Clark and Takahiro Fujimoto, HBS Press,
1991
[2] Collaborative Advantage: Winning Through Extended Enterprise Supplier Network;

Jeffrey H. Dyer, Oxford University Press, 2000
171
I
All men dream: but not equally. Those who
dream by night in the dusty resses of their mind
wake up in the day to find that it was vanity: but
dreamers of the day are dangerous men, for
they act their dreams with open eyes, to make
it possible.
Additional Material
T. E. Lawrence, Seven Pillars of Wisdom
I.1. Famous Quotes
You don’t transition your project to agile projects; you have to transform your
people to think in agile ways. —Eric Olafson
Agile is delivering value to customers faster and minimizing bureaucracy.
—Alistair Cockburn
I.2. List of Learning Topics

Depending on your starting point, your location and your domain of work you may need
to learn in addition to the tools of a Scrum Master:
• Nonviolent communication
• Software development techniques
• Hardware development techniques
• Testing techniques
• DevOps techniques
• Healthineers Performance System (HPS) core and advanced methods
• User Experience techniques (UX) - design thinking
• Systems thinking
• Change management
• Workshop moderation
• Other agile frameworks
• Economic Framework
• Holding and Transaction Costs
• User Stories along [Coc06] (pp. 284–290)
172
I.3. Videos
I.3. Videos
You found a good explaining video? Drop me a note.
Nordstrom Innovation Lab https://youtu.be/2NFH3VC6LNs
Der Upstalsboom Weg https://youtu.be/culjElgNTmw
The Art of Innovation https://youtu.be/Mtjatz9r-Vc
’The Leader’s Guide to Radical Management’ by https://youtu.be/802PdPeS4ic
Steve Denning
Little’s Law https://youtu.be/lHQZcMRr2n0
I.4. Bibliography
[App11] Jurgen Appelo. Management 3.0 — Leading Agile Developers, Developing Agile
Leaders. Addison-Wesley, 2011.
[App14] Jurgen Appelo. #Workout: Games, Tools & Practices to Engage People, Improve
Work, and Delight Clients (Management 3.0). self, 2014.
[BD12] Steve Blank and Bob Dorf. The Startup Owner’s Manual: The Step-by-Step
Guide for Building a Great Company. Baker and Taylor, 2012.
[BO17] David J. Bland and Alexander Osterwalder. Testing Business Ideas: A Field
Guide for Rapid Experimentation. Wiley, 2017.

[Dem00] W. Edwards Deming. Out of the Crisis. The MIT Press, 2000.
[Edm18] Amy C. Edmondson. The Fearless Organization: Creating Psychological Safety

in the Workplace for Learning, Innovation, and Growth. Wiley, 2018.
[KBS18] Gene Kim, Kevin Behr, and George Spafford. The Phoenix Project: A Novel
About IT, DevOps, and Helping Your Business Win. IT Revolution Press, 2018.
[KHDW16] Gene Kim, Jez Humble, Patrick Debois, and John Willes. The DevOps Hand-
book — How to create world-class agility, reliability, & security in technology
organizations. IT Revolution Press, 2016.
[Kim19] Gene Kim. The Unicorn Project: A Novel about Developers, Digital Disruption,
and Thriving in the Age of Data. IT Revolution Press, 2019.
[KL16] Robert Kegan and Lisa Laskow Lahey. Everyone Culture: Becoming a Deliber-
ately Developmental Organization. Harvard Business Review Press, 2016.
173
I. Additional Material
[Lal14] Frederic Laloux. Reinventing Organizations: A Guide to Creating Organizations

Inspired by the Next Stage in Human Consciousness: A Guide to Creating Orga-
nizations Inspired by the Next Stage of Human Consciousness. Nelson Parker,
2014.
[Leo18] Klaus Leopold. Rethinking Agile: Why Agile Teams Have Nothing To Do With
Business Agility. LEANability PRESS, 2018.
[MCSF15] Stanley Gen. McChrystal, Tantum Collins, David Silverman, and Chris
Fussel. Team of Teams: New Rules of Engagement for a Complex World. Portfolio,
2015.
[MW09] Donella M. Meadows and Diana Wright. Thinking in Systems: A Primer.

Taylor & Francis, 2009.
[OP10] Alexander Osterwalder and Yves Pigneur. Business Model Generation: A

Handbook for Visionaries, Game Changers, and Challengers. Wiley, 2010.
[OPB+ 14] Alexander Osterwalder, Yves Pigneur, Gregory Bernarda, Alan Smith, and
Trish Papadakos. Value Proposition Design: How to Create Products and Services
Customers Want. Wiley, 2014.
[OPSE20] Alexander Osterwalder, Yves Pigneur, Alan Smith, and Frederic Etiemble.
The Invincible Company: How to Constantly Reinvent Your Organization with
Inspiration From the World’s Best Business Models. Wiley, 2020.
[PP03] Mary Poppendieck and Tom Poppendieck. Lean Software Development: An

Agile Toolkit. Addison-Wesley Professional, 2003.
[Sen06] Peter M. Senge. The Fifth Discipline: The Art & Practice of The Learning
Organization. Currency, 2006.
[SJ20] Lisette Sutherland and K. Janene-Nelson. Work Together Anywhere: A Hand-

book on Working Remotely—Successfully—for Individuals, Teams, and Managers.
Wiley, 2020.
[Vac15] Daniel S. Vacanti. Actionable Agile Metrics for Predictability: An Introduction.

Daniel S. Vacanti, Inc., 2015.
[WM15] Geoff Watts and Kim Morgan. The Coach’s Casebook: Mastering The Twelve
Traits That Trap Us. Inspect & Adapt Ltd, 2015.
174
Nomenclature
MMP The product with the smallest feature set that still addresses the user needs and
creates the right user experience.
team facilitator The team faciliator is a person.
WIP work that is currently progressed.
175
Glossary
Acceptance Test-Driven-Development Acceptance test-driven development is a develop-

ment methodology based on communication between
the business customers, the developers, and the
testers. ATDD encompasses many of the same prac-
tices as specification by example (SBE), behavior-
driven development (BDD), example-driven develop-
ment (EDD), and support-driven development also
called story test-driven development (SDD). All these
processes aid developers and testers in understand-
ing the customer’s needs prior to implementation
and allow customers to be able to converse in their
own domain language. ATDD is closely related to
test-driven development (TDD). It differs by the em-
phasis on developer-tester-business customer collab-
oration. ATDD encompasses acceptance testing, but
highlights writing acceptance tests before developers
begin coding..
accountability An obligation or willingness to accept responsibility
or to account for one’s actions.
accountable Being the one who must meet an obligation or suffer
the consequences for failing to do so. .
Agile Agile is the ability to create and respond to change.
It is a way of dealing with, and ultimately succeeding
in, an uncertain and turbulent environment.
ART Agile Release Train.
backlog An ordered list, containing all the work to bring a

product into the market. Also known as Product Back-
log.
Backlog Refinement Backlog refinement (formerly known as backlog
grooming) is when the product owner and some, or
all, of the rest of the team review items on the backlog
to ensure the backlog contains the appropriate items,
that they are prioritized, and that the items at the
top of the backlog are ready for delivery. This activ-
ity occurs on a regular basis and may be an officially
scheduled meeting or an ongoing activity..
176
Glossary
BDD In software engineering, behavior-driven develop-

ment (BDD) is an Agile software development pro-
cess that encourages collaboration among develop-
ers, QA and non-technical or business participants
in a software project. It encourages teams to use
conversation and concrete examples to formalize a
shared understanding of how the application should
behave. It emerged from test-driven development
(TDD). Behavior-driven development combines the
general techniques and principles of TDD with ideas
from domain-driven design and object-oriented anal-
ysis and design to provide software development and
management teams with shared tools and a shared
process to collaborate on software development. .
CD Continuous Deployment.
CI Continuous Integration.
CoD Cost of Delay.
consistency Firmness of constitution or character: persistency.
CoP Community of Practice.
Cost of Delay Cost of delay is the difference in the value of doing
something sooner vs. doing it later. The cost of delay
of a new product development project is the amount
of additional profit you would make by launching a
product at an earlier time ’X’ vs. launching at a later
time ’Y’. It is the total profit-dollars lost per unit of
time of delay, e.g., the total amount of dollars lost, per
month, per week, or per day of delay..
cross-functional team member Cross-functional teams consist of people, which have
all the skills necessary to create a product. In soft-
ware development they typicaly consists of design-
ers, developers, testers, and further necessary roles.
The team will deliver on regular cadence. They are
crusual for the success of Agile Development, since
they can provide value in the shortest possible time,
with higher quality, and without external dependen-
cies..
Cumulative Flow Diagram A cumulative flow diagram is a tool used in queuing
theory. It is an area graph that depicts the quantity of
work in a given state, showing arrivals, time in queue,
quantity in queue, and departure..
cycle time Latency between start of work and the completion.
(see also lead time).
177
Glossary
Daily Stand–up Each day at the same time, the team meets so as to
bring everyone up to date on the information that
is vital for coordination: each team members briefly
describes any “completed” contributions and any ob-
stacles that stand in their way. The meeting is nor-
mally held in front of the task board. This meeting
is normally timeboxed to a maximum duration of 15
minutes, though this may need adjusting for larger
teams. To keep the meeting short, any topic that starts
a discussion is cut short, added to a “parking lot” list,
and discussed in greater depth after the meeting, be-
tween the people affected by the issue..
Definition of Done The team agrees on, and displays prominently some-
where in the team room, a list of criteria which must
be met before a product increment “often a user story”
is considered “done”. Failure to meet these criteria
at the end of a sprint normally implies that the work
should not be counted toward that sprint’s velocity..
DevOps DevOps is a set of practices that combines software
development (Dev) and IT operations (Ops). It aims
to shorten the systems development life cycle and
provide CI with high software quality. DevOps is
complementary with Agile software development;
several DevOps aspects came from the Agile method-
ology.
DoD Definition of Done.
EBM Evidence-Based Management is a framework organi-

zations can use to help them measure, manage, and
increase the value they derive from their product de-
livery. EBM focuses on improving outcomes, reduc-
ing risks, and optimizing investments. It is developed
and sustained by Ken Schwaber and Scrum.org..
expert A person with a high level of knowledge or skill in a
field. .
eXtreme Programming eXtreme Programming (XP) is an agile software de-
velopment framework that aims to produce higher
quality software, and higher quality of life for the
development team. XP is the most specific of the
agile frameworks regarding appropriate engineer-
ing practices for software development. see http:
//www.extremeprogramming.org/.
178
Glossary
grooming see Backlog Refinement.
HPS Healthineers Performance System 1 .
iteration An iteration, in the context of an Agile project, is a

timebox during which development takes place, the
duration of which may vary from project to project,
usually between 1 and 4 weeks and is in most cases
fixed for the duration of a given project.
lead time A lead time is the latency between the initiation and
completion of a process..
mental models A mental model is an explanation of someone’s

thought process about how something works in the
real world. It is a representation of the surround-
ing world, the relationships between its various parts
and a person’s intuitive perception about his or her
own acts and their consequences. Mental models can
help shape behaviour and set an approach to solving
problems (similar to a personal algorithm) and doing
tasks (Wikipedia).
minimalism Ask yourself: “What is the smallest thing I can do
to solve the problem?” - a style or technique (as in
music, literature, or design) that is characterized by
extreme spareness and simplicity..
MMP Innovate successfully by creating a minimal mar-
ketable product, a product with just the right fea-
tures. This allows you to launch quicker, reduce time-
to-market, and start earning money sooner. Read
more at: https://www.romanpichler.com/blog/the-
minimal-marketable-product/ Copyright © Pichler
Consulting..
MVP Minimum Viable Product.
PBI Product Backlog Item.
1
https://healthineers.sharepoint.com/sites/HealthineersPerformanceSystem
179
Glossary
persona A persona, (also user persona, customer persona,

buyer persona) in user-centered design and market-
ing is a fictional character created to represent a user
type that might use a site, brand, or product in a simi-
lar way.[1] Marketers may use personas together with
market segmentation, where the qualitative personas
are constructed to be representative of specific seg-
ments. The term persona is used widely in online
and technology applications as well as in advertising,
where other terms such as pen portraits may also be
used. (Wikipedia).
PO Product Owner.
Product Owner The product owner is a role on a product develop-
ment team responsible for managing the product
backlog in order to achieve the desired outcome that
a product development team seeks to accomplish..
Program Increment A Program Increment (PI) is a timebox during which
an Agile Release Train (ART) delivers incremental
value in the form of working, tested software and
systems. PIs are typically 8–12 weeks long. The most
common pattern for a PI is four development Itera-
tions, followed by one Innovation and Planning (IP)
Iteration. ©Scaled Agile, Inc..
retrospective The team meets regularly, usually adhering to the

rhythm of its iterations, to explicitly reflect on the
most significant events to have occurred since the
previous such meeting, and take decisions aiming at
remediation or improvement.
RTE Release Train Engineer.
SAFe Scaled Agile Framework.

Scrum Scrum is a process framework used to manage prod-
uct development and other knowledge work. Scrum
is empirical in that it provides a means for teams to
establish a hypothesis of how they think something
works, try it out, reflect on the experience, and make
the appropriate adjustments. That is, when the frame-
work is used properly. Scrum is structured in a way
that allows teams to incorporate practices from other
frameworks where they make sense for the team’s
context..
180
Glossary
silo The standard competency breakdown structure in or-

ganizations, like marketing, sales, R&D departments..
SM Scrum Master.
SoS Scrum of Scrums.
SPC SAFe Program Consultant.
sustainability of, relating to, or being a method of harvesting or
using a resource so that the resource is not depleted
or permanently damaged.
task board In its most basic form, a task board can be drawn on a
whiteboard or even a section of wall. Using electrical
tape or a dry erase pen, the board is divided into three
columns labeled “To Do”, “In Progress” and “Done”.
Sticky notes or index cards, one for each task the team
is working on, are placed in the columns reflecting
the current status of the tasks..
TDD Test-driven development (TDD) is a software devel-
opment process relying on software requirements
being converted to test cases before software is fully
developed, and tracking all software development by
repeatedly testing the software against all test cases.
This is opposed to software being developed first and
test cases created later. American software engineer
Kent Beck, who is credited with having developed or
“rediscovered” the technique, stated in 2003 that TDD
encourages simple designs and inspires confidence.
Test-driven development is related to the test-first pro-
gramming concepts of extreme programming, begun
in 1999, but more recently has created more general
interest in its own right. Programmers also apply
the concept to improving and debugging legacy code
developed with older techniques (Wikipedia) .
181
Glossary
Team Coach In an Agile Team we have three roles, the cross-

functional team member, the PO and the Team Coach.
The Team Coach is a servant leader. The role is in
other frameworks also called: Scrum Master (SM),
project manager (XP), project team lead, team coach.
Every Agile Team needs servant leadership and thus
somebody is need to help the people build their ser-
vant leadership skills of facilitation, coaching and
impediment removal. If the organization could not
gain experience in Agile Development, yet, external
coaches migh help to develop servant leadership as
well as train internal coaches. .
TPS Toyota Production System.
UX User experience (UX or UE) is about how a user in-

teracts with, and experiences, a particular product,
system or service. It includes a person’s perceptions
of utility, ease of use, and efficiency. User experi-
ence is an important concern to many companies
when creating products, as negative user experience
may decay profitability. User experience is subjective.
(Wikipedia).
velocity At the end of each iteration, the team adds up ef-

fort estimates associated with user stories that were
completed during that iteration. This total is called
velocity. Knowing velocity, the team can compute (or
revise) an estimate of how long the project will take to
complete, based on the estimates associated with re-
maining user stories and assuming that velocity over
the remaining iterations will remain approximately
the same. This is generally an accurate prediction,
even though rarely a precise one. .
WIP Work-in-Progress.
XP eXtreme Programming.
182
Index
Scrum Master’s Learning Path, 7 collaboration, 107

3Cs, 108 commitment, 61
communication, 11, 18
absolute estimation, 43
confirmation, 107, 108
acceptance test, 152
consistency, 18, 43
Acceptance Test-Driven Development,
constraint, 91, 93
see ATDD
Continuous Delivery Pipeline, see CDP
accountability, 18
Continuous Deployment, see CD
accountable, 39, 176
Continuous Exploration, 98
activity, 160
Continuous Integration, see CI, see CI
adaption, 15, 60
conversation, 107, 108
Adaptive Software Development, 16
coordination, 178
agile, 8, 176, 178
agile development, 7, 11, 15, 107 cost of building, 44
agile frameworks, 172 Cost of Delay, 27, 30, 177
agile manifesto, 16, 132 cost of shipping, 44
agile marketing manifesto, 134 courage, 18, 61
Agile Mindset, 16 cross-functional, 39
Agile Team, 39, 182 cross-functional team member, 177
ART, 98 Cross-Team Refinement, 97
ATDD, 93, 176 cross–functional teams, 38
Crystal Clear, 16
backlog, 39, 42, 151 Cumulative Flow Diagram, 140, 177
backlog grooming, see Backlog customer, 152
Refinement
Backlog Refinement, 44, 176 Daily Scrum, 151
barriers, 39 Daily Stand–up, 178
batch size, 101 Daily Stand-up, 151
BDD, 176, 177 daily stand–up, 44
Behavior-Driven Development, see BDD
debriefing, see retrospective
bottleneck, 93
Definition of Done, see DoD, 76, see DoD
bugs, 43
Definition of Done, 98
Burndown Chart, 151
dependencies, 98
business agility, 98
design thinking, 172
card, 107, 108 Developer, 72
CD, 99 Developers, 65, 65
CDP, 98 development process, 44
certification, 8, 130 DevOps, 99, 172, 178
change management, 172 DoD, 45, 72, 73, 75, 93, 151, 152, 178
CI, 42, 98, 178 Done, 152
COGS, 30 DSDM, 16
183
INDEX
EBM, 160, 178 kano-model, 43

empirical measurement, 44
empiricism, 19 lead time, 179
epic, 111 Lean Portfolio Management, see LPM
estimate, 151, 182 learning, 107
Estimation, 43 LeSS, 96
estimation, 117 LPM, 99
Estimation Methods, 156
Magic Estimation, 118, 158, 159
Evidence-Based-Management, see EBM
management, 125, 141, 152
expert, 41, 178
market changes, 42
eXtreme Programming, see XP
maturity, 152
feature, 45, 152 measure, 43
Feature Driven Development, 16 Measurement, 44
feedback, 18, 92, 93, 107 minimalism, 18
Fibonacci, 151 MMP, 179
flow, 92 MVP, 100
focus, 43, 61
Nexus, 96, 96, 153
grooming, see Backlog Refinement Nexus Integration Team, 97
Nexus Sprint Backlog, 98
hardware development, 172 Nexus Sprint Goal, 98
Healthineers Performance System, see Nexus Sprint Planning, 97
HPS No Estimates, 118, 119
HPS, 172, 179 nonviolent communication, 172
Humphrey’s Law, 72
obstacle, 152, 178
I & A, 98 one-time order, 42
ideation, 11 openness, 61
improvement, 152 organization, 66
Increment, 73, 75, 76, 98 outcome, 43, 160
increment, 92 output, 160
incremental design, 42
information radiator, 44 Pair Programming, 45
Inspect & Adapt, see I & A pair programming, 41
inspection, 15, 60 performance, 43
Integrated Increment, 98 persona, 112, 180
IT Operations, 178 PI, 98, 180
Iteration, 98 Planning, 42
iteration, 19, 43, 44, 179, 182 Planning Poker, 118, 156, 158, 159
iteration length, 44 PO, see Product Owner
iteration retrospective, see retrospective PO, 72
policy, 92, 93
kaizen, 152 Portfolio Vision, 99
Kanban, 91, 98 post-mortem, see retrospective
184
INDEX
practices, 18 Scrum board, 151

Pragmatic Programming, 16 Scrum Events, 67
prediction, 44 Scrum framework, 57, 58, 150
prioritization, 150 Scrum Guide, 76
process improvement, 152 Scrum Master, 39, 65, 65, 66, 102, 118,
Product Backlog, 73, 74, 150, 151, 176 137, 138, 141, 150–152, 158, 172
Product Backlog, 71 Scrum Master, 71
Product Backlog, 98 Scrum Team, 64, 65, 98, 150–152
Product Backlog Item, 151 Scrum Team, 71, 72
Product Backlog refinement, 74 Scrum Values, 61, 61
product changes, 42 self-organization, 39
Product Goal, 73, 74 servant leader, 182
Product Goal, 98 servant leadership, 182
Product Management, 98 shipping, 44
Product Owner, 65, 65–67, 120, 140, silo, 181
150–152, 157, 158, 180 simplicity, 18
Product Vision, 98, 150, 151 single source of truth, 98
Program Backlog, 98 slack, 42
Program Board, 98 software development, 172, 177, 178
Program Increment, see PI Solution Architect, 99
project, 182 Solution Management, 99
project manager, 39 Solution Train, 98, 99
pull, 91 Solution Train Engineer, see STE
pull system, 91 spike, 111, 112, 121
Spotify Engineering Model, 96
quarterly cycle, 42
Sprint, 68, 97, 151, 152, 178
reference story, 43, 118 Sprint, 72
reflection, 94 Sprint Backlog, 73, 74, 152
Reflection Workshop, 44 Sprint Backlog, 71
reflection workshop, see retrospective Sprint Demo, 152
relative estimation, 43 Sprint Goal, 73, 75, 76, 98, 151, 152
relative sizing, 43 Sprint Goal, 71
Release on Demand, 99 Sprint Planning, 68, 151, 159
release planning, 119 Sprint Retrospective, 72
Release Train Engineer, see RTE Sprint Retrospective, 71, 72
respect, 61 Sprint Review, 71, 152
retrospective, 44, 125, 180 Sprint Review, 71
root cause, 125 stakeholder, 150, 152
stakeholder, 72
SAFe, 96, 98 stakeholder involvement, 72
Scrum, 7, 16, 57, 58, 98, 151, 156, 180 STE, 99
Scale, 96 stories, 41
Scrum Artifacts, 73 Story Point, 117
185
INDEX
Strategic Themes, 99 Transparency, 60

strategy, 99 transparency, 15, 42, 60
sustainability, 18 Triangulation, 118, 119
symptom, 125 trust, 152
System Architect, 98
System Demo, 98 user experience, see UX
system of systems, 98 user story, 159, 182
systems thinking, 172 UX, 172, 182
value, 124, 151

taskboard, 178, 181
value-based measurement, 44
TDD, 49, 176, 181
values, 18
Team Coach, 39, 182
Velocity, 151, 152, 182
Team Facilitator, 137, 138, 140, 141
velocity, 72
team wall, 44
visualize, 92
ten–minutes build, 42
Test-Driven Development, see TDD waterfall development, 15
Test-First Development, see TDD, see weekly cycle, 41
TDD WIP, 93
testing, 172 WIP limit, 72, 91, 92, 101
Test–First Programming, see TDD workshop moderation, 172
timebox, 43, 178
Toyota Production System, 90 XP, 13, 18, 39, 40, 108, 111, 156, 178
186

SM Workbook

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

SM Workbook

Uploaded by

Copyright:

Available Formats

Scrum Master Training

1. agile software development 11

2. agile hardware development 26

II. Agile Frameworks

5. scrum in software development 85

6. scrum in hardware development 86

7. scrum outside the software organization 89

III. User Stories

10. user stories 107

11. story handling 117

IV. About Our Journey

12. agile@siemens healthineers 124

A. certification & transfer into practice 130

C. team development 137

D. infra- and organizational structure 144

E. agile frameworks 150

F. estimation methods 156

H. lean software development 167

I. additional material 172

About the course

The Scrum Master’s Learning Path

Additional Learning Ideas

• hardware and software development techniques

• project management techniques

• product portfolio management

• system theory and thinking

• more starting with on page 172

Introduction of the Simulation

Agile Software Development

• rapid application development (RAD), from 1991;[Mar91][KH93]

• Scrum, from 1995;

• feature-driven development (FDD), from 1997.

1. The development of complex products is (predictable , unpre-

2. The practices of Agile Development are (context-specific , non-

3. We are more (efficient , effective ) by applying Agile Develop-

4. We (adapt , stick to ) our plans.

5. The development will have a (sustainable , unsteady ) pace.

6. Reflection workshops will happen (regularly , infrequently ).

Figure 1.2.1.: Cynefin Framework

Here the approach is Act—Sense—Respond, and we can discover innovative prac-

• Confused—It is not clear which of the other contexts applies. By definition, it is

correlating the problem, the solution, and further dimensions.

Figure 1.2.2.: Simplified Stacey Model

Waterfall Development The waterfall model12 originated in construction and man-

1.3. The Manifesto of Agile Software Development

We are uncovering better ways of developing

• Agile processes promote sustainable development. The sponsors, developers, and

• The best architectures, requirements, and designs emerge from self-organizing

• Welcome changing requirements, even late in development. Agile processes har-

• Deliver working software frequently, from a couple of weeks to a couple of months,

• Agile processes promote sustainable development. The sponsors, developers, and

Figure 1.3.1.: Phase-Gated Development

Figure 1.3.2.: Iterative Development

• Working software is the primary measure of progress. → there might be other

• Continuous attention to technical excellence and good design enhances agility. →

Practice [Timebox: 15 min]

Learning Log [5 min]

Fundamental Ideas of Agile Software Development23

1.4. Enlightened Approaches

1.4.1. The Heart of Agile24

• The world, however, is remarkably resistant to interventions.

These four words help you do it:

1.4.2. Modern Agile25