Patterns That Make Scrum Work

Exploring Scrum: Patterns that Make Scrum
Work
Understanding and Scaling Scrum
Dan Rawsthorne, PhD, PMP, CST

This book is for sale at http://leanpub.com/PPSAD
This version was published on 2013-12-29
This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.
©2013 Dan Rawsthorne, PhD, PMP, CST

Tweet This Book!
Please help Dan Rawsthorne, PhD, PMP, CST by spreading the word about this book on Twitter!
The suggested tweet for this book is:
I just bought the book Patterns that Make Scrum Work at Leanpub.com
The suggested hashtag for this book is #PPSAD.
Find out what other people are saying about the book by clicking on this link to search for this
hashtag on Twitter:
https://twitter.com/search?q=#PPSAD
To Mel… you will be missed
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Original Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Pattern: Well-Formed Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Pattern: Team Coach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Pattern: Business Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Pattern: Agile Product Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Original Scrum Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Modern Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Pattern: Team Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Pattern: Subject Matter Experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Pattern: Definition of Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Pattern: Forecast, don’t Commit (and others) . . . . . . . . . . . . . . . . . . . . . . . . . 38
Modern Scrum Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
What We Learn from Scrum - the Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Scaling Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Pattern: Generic Development Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Pattern: Distribution Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Pattern: Consolidation Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Pattern: Program Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Patterns for ‘Big’ Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Pattern: Management Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Pattern: Cross-Cutting Workgroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Pattern: Community of Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Pattern: Integration and Evaluation (I&E) Team . . . . . . . . . . . . . . . . . . . . . . . . 69
Evaluating Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Analysis of the LeSS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Analysis of the Scaled Agile Framework (SAFe) . . . . . . . . . . . . . . . . . . . . . . . . 75
Book Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Introduction
Scrum is the most common, and popular, Agile Development framework in the world. In this book
I will describe some of the basic Patterns that are used in, and with, Scrum. This will:
• Help you understand how Scrum works, and why it is what it is, and
• Introduce some basic Scaling Patterns, which allow us to extend Scrum to work in an
Organization.
Scrum’s People
Scrum is a very simple Framework, and it involves two types of people:
1. Developers: People who build, produce, develop, or do something. Since the things we do are
often complicated, these people are organized into Teams, and are called Team Members,
Developers, or just plain worker-bees.
2. Deciders: People who decide what needs to built, produced, developed, or done next. These
people are held Accountable for their decisions – they own their decisions – and I will refer
to them as Leaders or Owners.
Of course, Scrum is not that simple – this is not all of Scrum. There are Schedules and Costs to
manage, advice and guidance on what to build to give, and a simple Agile Process that surrounds
everything.
But the important stuff is about Teams and Deciders. What Teams do we need, and what do they do?
What Deciders do we need, and who should they be? Who helps the Deciders get the information
they need? And so on… these are the main questions in Scrum, and things the Patterns involve.
To put it bluntly: when we are thinking about Scrum we shouldn’t be thinking about Process, we
should be thinking about Decision-Makers; we need to have the right people in the right place at
the right time, making the right decisions – and being Accountable for those decisions.
Patterns and AntiPatterns

The advice in this book is largely presented in the form of Patterns and AntiPattern, so I better
explain them to you. :)
At its simplest, a Pattern is defined as a “solution to a problem in a context” and each Pattern I give
in this book has the following parts:
Introduction 2
• Pattern Name: a descriptive name…

• Problem: what needs to happen…
• Context: what is going on…
• Solution: short statement of solution…
• Discussion and Examples: often including non-software examples
Now, the Patterns in this book aren’t the Design Patterns you might be used to. Most Design
Patterns are solutions to tactical problems or low-level strategic problems. For example, you might
find many different Design Patterns describing different ways to run Daily Scrums, or you might
find a Design Pattern telling you that you should have Daily Scrums. People often try to use these
Design Patterns as recipes – as advice to follow more-or-less blindly.
The Patterns in this book are more like Architectural Patterns; they describe the “big ideas” that
form the “shape” of Scrum, whereas Scrum’s Design Patterns often describe how Scrum works,
or ways of making Scrum work… I hope you understand the difference… Architectural Patterns
describe why something is what it is – why Scrum is Scrum and not something else, for example –
while Design Patterns are used by a self-organizing Team to help them figure out how to solve a
particular problem they may have.
I may also have a few AntiPatterns (I’m not sure yet); AntiPatterns are things we see quite often,
but are not a good idea. One way to think of AntiPatterns is that they are “things that look like
they should work, but don’t.” when I present an AntiPattern, it will have the following parts:
• AntiPattern Name: a descriptive name…

• Reason it Exists: why people think it’s a good idea; why it happens…
• Discussion: why it’s not a good idea, additional caveats, etc…
So, it sounds like Patterns and AntiPattern encapsulate good advice you should just follow, right?
It’s not that simple, really. Patterns and AntiPatterns can’t be followed blindly and be expected to
work. Patterns and AntiPatterns contain some guidance and advice that will help you frame your
questions and manage your thoughts in order to deal with your situation. Patterns and AntiPatterns
help you understand what is important about a situation, and allows you to focus and analyze, rather
than thrash and panic. They allow you to reuse thoughts and analysis that other people have had,
but should not be followed blindly.
In fact, let’s think about that recipe thing…
Have you ever followed a recipe and the food was inedible? Who did you blame? – the yourself or
the recipe? Think about that for a minute, talk to your friends about it… I’ll wait.
* * *
Ahh, you’re back. So, now you understand that even recipes aren’t to be followed blindly. As I
hope to realize, the cook is Accountable for the results, not merely following the recipe. Same with
Patterns… just sayin’… it gets complicated :)
Introduction 3
Accountability
I’ve already used the work “Accountable” a couple of times, so I better make sure we have a common
understanding of what it means.
Accountability is a very important concept in Scrum. Most people don’t really understand what
Accountability is; they really don’t understand the notion of a person being Accountable. In fact,
there is not even a word for it in many languages. So, let me explain what it means for us when
we’re talking about it.
Here’s the basic definition (see Wikipedia): “Accountability is answerability, blameworthiness,
liability, and the expectation of account-giving… Accountability is the acknowledgment and
assumption of responsibility for actions, products, decisions, and policies…” It is frequently described
as a relationship between individuals; Person-A is Accountable to Person-B for Thing-C when
Person-A may be “held to account” for Thing-C to Person-B. The phrases “held to account” or
“make an accounting” both mean being able to explain yourself. Generally speaking, we usually
hold people Accountable for something being done, or a decision being made. Let me discuss each
of these cases:
• Person-A is “Accountable for something being done” means that Person-A needs to make
sure that the something gets done – Person-A doesn’t have to do it personally – and Person-A
needs to be able to explain ‘Why?’ if it doesn’t get done.
• Person-A is Accountable for a decision being made” means that Person-A makes sure the
decision is made, and that Person-A owns the decision. In other words, Person-A needs to
be able to explain the decision, and Person-A is also Accountable for all the consequences
(both intended and unintended) of that decision.
Generally speaking, only individual people can be held Accountable for things. Many people speak
of Team, Group, or Organizational Accountability, but this is a difficult concept – and we’ll see this
come up later.
Conventions
Most terms in bold will be defined in a glossary. Nouns (Product) are bold, Verbs (Review) are
bold-italic
In this book
Scrum has undergone almost constant change since the 1990’s when it was first named, imple-
mented, and described for software¹. There are two (significantly) different versions of Scrum that
have arisen: I will call them Original Scrum and Modern Scrum.
¹The first people to document Scrum for Software were Ken Schwaber and Jeff Sutherland. We owe them a big debt of thanks!
Introduction 4
In the first chapter I will show how Original Scrum arose from a simple application of a few
Patterns, and in the next chapter I will show how this morphs into Modern Scrum by applying
a few more. After that I will introduce Scaling Patterns and analyze some popular Agile Scaling
Frameworks by comparing them to these Patterns.
With these definitions and explanations, we are now ready to explore Scrum.
Original Scrum
I’m going to go through a few Patterns, and build Original Scrum one Pattern at a time.
I will describe these Patterns as we find them “outside” the software context, in order to show that
there is nothing special about these Patterns – they are not software-specific. What is interesting
is that we are (only recently) bringing them to mainstream Software Development.
After the Patterns are described, I will assembly them into a Software Development Scrum Team…
Original Scrum 6
Pattern: Well-Formed Team

The core of Scrum – its most basic idea – is the Well-Formed Team, so that’s where we start…
Problem:
There is an Item of Work to be done.
Context:
• The Item has one (or more) Stakeholders who want the work to be done, and these
Stakeholders can’t (or don’t want to) do the work themselves.
• Each Item has Acceptance Criteria; the Stakeholders have an idea about what the finished
result should look like, be, or do – and these Acceptance Criteria will be shared as part of
the Item.
Solution:
Use a Well-Formed Team (WFT) to do the work, which means:
• the WFT is Self-Organized: the Team Members determine what Tasks are necessary for
them to accomplish the work and complete the Item. The Team Members are co-located (if
not physically, then virtually) and have frequent Coordination Meetings to stay ‘synced-up’
while they are working. The WFT manages itself so that the Stakeholders don’t have to.
• the WFT is Self-Contained: the Team Members (collectively) have all the knowledge and
skills they need in order to accomplish the work and complete the Item. The Stakeholders
will not have to worry about delays based on waiting for outsiders to complete their part of
the work.
• the Team Members are Value-Driven: they value working together; they are constantly
working on Improvements of themselves, their Team, their environment, and their tools; and
they do their due diligence to complete Items to/with the Standard of Care they deserve.
Doing their due diligence often requires them to do Chores that are not directly involved in
working on the Items. The Stakeholders can trust that the WFT has Integrity – the Team
Members are Professionals – and will meet the Acceptance Criteria while meeting the
appropriate Standard of Care².
²In Software, this notion of Professionalism is captured in the Software Craftsmanship movement.
Original Scrum 7
The Well-Formed Team
Generally speaking, this Pattern specifies the following Accountabilities:
• The Well-Formed Team is Accountable to the Stakeholders for using the appropriate
Standard of Care and satisfying the Item’s Acceptance Criteria,
• The Well-Formed Team is Accountable to identify and carry out Improvements and Chores
that are required for the WFT’s successful continuation, and
• The Team Members are Accountable to each other to be good Team Members and live the
Values.
Discussion and Examples:

We find Well-Formed Teams everywhere, in all walks of life, doing all sorts of work. The range
from the Team of gardeners that maintains your yard and garden, to the team of mechanics that
works on your car, to the team of doctors and nurses that works on you in the hospital.
Well-Formed Teams are usually thought of as specialists, professionals, or experts, in a particular
domain. Well-Formed Teams can come in many sizes:
• A Well-Formed Team could be a 1-man Team, like my plumber Jerry.

• A Well-Formed Team could be a Small Team, like the collection of mechanics at a car repair
center, the members of a brick-laying team, cooks and other workers in a (small) restaurant
kitchen, or the truck-load of gardeners who come by to fix up your yard and garden.
• A Well-Formed Team could be Large, like a Construction Company, a Hospital, or the cooks
and other workers in a (large) restaurant kitchen. However,
• The internal organization of this large Well-Formed Team must consist of Well-Formed
Teams.
Original Scrum 8
• In other words, it is a recursive definition: a Team made up of Well-Formed Teams whose

governance is also done by Well-Formed Teams is a Well-Formed Team. This will be
explored in the scaling patterns later in this book.
Well-Formed Teams are Self-Contained and Self-Organized, which means that the Team Mem-
bers figure out how to work together, combining their skills, in order to get the work done. This can
take many different forms – here are just a few:
• The WFT could use an adaptable assembly line – like in a kitchen or brick-laying team. The
work, itself, follows a certain flow – and it is adapted as necessary. There is often a member
of the Team (like the sous-chef or Master Mason) who is orchestrating this flow.
• The WFT could normally work as individuals, but Pair and Swarm as needed. We see
this pattern of behavior on most WFTs, but it is very obvious with mechanics and medical
professionals.
• The WFT’s Team Members always work in pairs, sharing expertise (and looking out for each
other) while doing the work. This is often done when dangerous machinery is involved.
That being said, the third part of the definition (Value-Driven) is the most interesting, for a couple
of reasons.
The first reason is because Well-Formed Teams are constantly improving. This has many facets:
they need to increase their Knowledge, improve their Teamwork, and improve their Tools and
Environment. This takes time (in the form of internally-generated Items or Tasks), and it is time
that will not be spent working on the Items coming from the Stakeholders; it is just part of the cost
of doing work.
The second reason is because of the notions of Standard of Care and Acceptance Criteria…
A Well-Formed Team must have a Standard of Care that it adheres to in its work. This Standard
of Care is crucial and inviolate, because the Stakeholders are relying on it. The Stakeholders are
relying on the Professionalism and Integrity of the WFT; the Stakeholders want the work done
right, and they are trusting the WFT to know what that means – and to do it every time. We would
like Team Members to be Self-Motivated, and do the work to the Standard of Care without being
told, and this would be a very high level of Professionalism.
This is a very interesting concept. If we think of what it takes to get an Item Done, we can see that
a Done Item is one that meets the Acceptance Criteria and that the Team used the appropriate
Standard of Care while doing the Item. To make it simple, we say that a Done Item met both the
Acceptance Criteria and the Standard of Care.
On the one hand, the Acceptance Criteria come from the Stakeholders (as part of the Item), and
defines what the Stakeholders want, need, expect, or are hoping for. The Acceptance Criteria may
be either ambiguous or well-defined; they may be documented or undocumented; the idea is that
the Stakeholders have some idea about what the end result should be. Here are some examples:
Original Scrum 9
• “Large sirloin, medium-rare, substitute broccoli for the asparagus, blue cheese dressing on the
side”
• “I need a retaining wall set up right over here…”
• “My brakes don’t work! Fix them!”
• “My dad is sick… please help him…”
• “Just mow the grass and clean up those two garden beds today…”
Doing its due diligence to meet the appropriate Standard of Care often requires the WFT to do
Chores, which (like Improvements) are internally-generated Items or Tasks that are not directly
involved with completing an Item. For example, painters must clean their brushes, mechanics must
clean their tools and dispose of old oil appropriately, workers in a kitchen must clean the dishes and
equipment, and so on. In my book (Exploring Scrum: the Fundamentals), I refer to Improvements
and Chores, collectively, as simply Chores – which are defined there as Items that are needed, by
not requested by the Stakeholders.
The fact that the WFT is Self-Contained implies that the WFT has the knowledge to understand
and refine the Acceptance Criteria as needed. Part of the Team’s Standard of Care could be to ask
questions and carry on a dialogue with the Stakeholders in order to refine the Acceptance Criteria
along the way.
On the other hand, the Standard of Care is supplied by the WFT – they are the experts on how to
do the work… and they have the Integrity to do it the right way every time. The Standard of Care
influences and defines how the WFT will do the work – what their internal process looks like. The
Standard of Care could define what the end result has to look like, it could require certain process
steps, whatever. A WFT’s Standard of Care could be highly personalized, or it could be determined
by their Industry/Profession, or both.
In many Industries/Professions the notion of a minimum Standard of Care is enforced through
laws, standards, inspections, or codes of ethics. For example:
• a Medical Professional will lose his/her license to practice medicine if it is determined that he
or she did not meet the appropriate Standard of Care when practicing medicine;
• an electrician will lose his/her license if his/her work consistently fails inspections;
• a Restaurant Kitchen will be shut down if the staff does not meet the standards for cleanliness
and food preparation;
• a mechanic will lose his/her certifications if the work is consistently done incorrectly;
• and so on…
As you can see, the Well-Formed Team is an powerful thing.

Original Scrum 10
Pattern: Team Coach

The next thing to add to the Scrum Team we are building is the ScrumMaster, which is an example
of a Team Coach.
Problem:
You want to develop and maintain a Well-Formed Team.
Context:
You have a group of people who either are, you think they could be, a Well-Formed Team.
Solution:
Have a Team Member acting as a Team Coach who will:
• Facilitate the Well-Formed Team’s Self-Organization, assuring that they improve their
Practices and work together as a Team. This implies that the Team Coach should not have
Management Authority, as the Team needs to own their own Practices – and it is inevitable
that a Team Coach with Management Authority would wind up owning them… just sayin’…
• Make sure that the WFT’s Team Members get whatever Training and Coaching they need
to improve their knowledge and skills in order for the WFT to become more versatile and
Self-Contained.
• Have frequent Reflections with the WFT to make sure it is constantly working on Improve-
ments to its Teamwork, Tools and Environment.
• Work with the WFT’s Team Members to help them understand the requirements of the
Standard of Care they must use to do their work.
• Play a Regulatory role and make sure the Team has Integrity and does its due diligence
constantly and consistently in order to meet the appropriate Standard of Care every time.
In this Pattern the Team Coach is Accountable for turning the Team into a Well-Formed Team.
There may be more than one Team Coach, with Accountability for different facets of the Well-
Formed Team. For example, one Team Coach may focus on Knowledge and Tools, while another
focuses on Teamwork and Self-Organization.
Original Scrum 11
Team Coach
At any given moment the Team Coach can be ‘held to account’ and must be able to discuss,
enumerate, and explain what Improvements and Chores the Team is working on – what the Team
is doing to improve itself. This is the Accountability The Team Coach has.

This Pattern is almost obvious; it is simply saying that a Team that is doing something complicated,
or wants to change its behavior, needs a Coach. However, this pattern is evidenced in many different
ways in different industries.
• In the Building Trades, where people go through the progression of Apprentice to Journey-
man to Master as they mature and gain experience, all Journeymen and Masters are expected
to mentor and train the Apprentices. Their intended goal is to produce a Well-Formed Team
–- and it just happens organically as long as you have one or more Masters or Journeymen
on your team.
• In the Military, it is part of a Non-Commissioned Officer’s (NCO, Sergeant) fundamental set
of responsibilities to train and mentor the Troops that he or she works with in order to turn
them into a Well-Formed Team.
• In a restaurant kitchen, this is the sous-chef’s job; it is the sous-chef who make sure that the
people are trained and that the kitchen operates as a Well-Formed Team.
One thing that may not be obvious is that the Team Coach should be very wary of having Skin in
the Game; that is, the Team Coach should be focused on the Team and its Practices, and not on its
value-producing Goals. Here are some extreme examples, just to illustrate the concept:
• A Team Doctor must be focused on the health of the Players, and not winning games. It the
Team Doctor is a “Good Team Player” he/she can too easily put Players back in the game too
soon… just sayin’…
Original Scrum 12
• Having the Chief Mechanic as the owner of the shop can lead to problems, if the Chief
Mechanic is also the Team Coach and starts concentrating on making money rather than
due diligence. This is a constant challenge when it comes to this kind of work, and why it is
recommended that somebody else do the coaching…
As you can see, adding a Team Coach to a Well-Formed Team is usually a good idea.
Original Scrum 13
Pattern: Business Owner

So, we have the Development Team and the ScrumMaster taken care of; what we’re missing from
the Scrum Team is the Product Owner. The Business Owner I describe in this Pattern is the
simplest version of a Product Owner.
Problem:
There is too much work competing for your Well-Formed Team’s time.
Context:
You have a Team, with multiple Stakeholders (or one very conflicted Stakeholder) that have many
Items they’d like your Team to work on. Your Team cannot do them all at once, and there is
confusion about what to do next.
Solution:
Have a person, called the Business Owner (BO), who sits between the Stakeholders and the Team,
who:
• Prioritizes/orders the work the Stakeholders want into a single Value Backlog, and
• Moves the Items from this Stakeholder’s Value Backlog to the Team’s Work Backlog at a
rate that will not overload the Team.
Original Scrum 14
The Business Owner
In addition to being Accountable for the above, this Pattern also requires the Business Owner to
be Accountable for understanding the Acceptance Criteria for any Item that is put on the Team’s
Work Backlog. We say that the Business Owner Represents the Stakeholders and manages the
Value Backlog.
Discussion, including examples:

Let me discuss this Business Owner concept with some of the Well-Formed Teams I introduced
before:
• The Business Owner for my plumber Jerry is his Office Manager, who gets the calls from
Clients describing what work needs to be done, and schedules them on Jerry’s Work Backlog
(his ‘Job List’), hoping that Jerry is not overloaded on any given day. If Jerry can’t get it all
Done, then the Office Manager rearranges the ‘Job List’ and works with the Clients to ‘make
it work’.
• The Business Owner for the collection of mechanics at a car repair center is the person at
the front desk who asks the Car Owner’s what is wrong with their cars and schedules their
cars onto the Shop’s Work Backlog. the Business Owner also works with the Car Owners
to keep them notified of what is going on…
Original Scrum 15
• The Business Owner for the kitchen personnel in a Restaurant is actually a shared role. All
of the Waitstaff/Servers fill out meal tickets and deliver them to the kitchen, where they are
put on the Team’s Work Backlog, as shown here.
A Restaurant’s Work Backlog
• The Business Owner for a Hospital Emergency Room has three parts:
• the Admitting Desk, who checks in new walk-in patients and puts them in order on the ER’s
Work Backlog,
• the Chief Resident, who meets Ambulances at the door, and immediately places emergency
cases at (or near) the front of the ER’s Work Backlog, and
• a medical professional performing triage in the waiting room, which allows some walk-ins to
be moved up the ER’s Work Backlog if their problems are urgent enough.
The second part of the Business Owner’s job: “Move the Items from this Value Backlog to the
Well-Formed Team’s Work Backlog at a rate appropriate for the WFT to consume them” is very
interesting.
• Sometimes the Well-Formed Team asks the Business Owner for a new Item when they are
ready to start a new one,
• Sometimes the Business Owner monitors the Team’s Work Backlog and just replenishes it
when it looks a little low,
• Sometimes the Work Backlog is populated at a rate based on historical data from the Team
– like Jerry’s daily ‘Job List’, and
• Nomatter what, the rate the Well-Formed Team completes Items from the Work Backlog is
based on the difficulty of meeting the Standard of Care for the Items being worked on and
how many Improvements and Chores the Team is undertaking.
The Business Owner is Accountable for the prioritization of the Value Backlog and the Business
Owner is Accountable for knowing what Item is needed next. We say that the Business Owner
represents the Stakeholders and manages the Value Backlog. These three things (the Business
Owner, the Value Backlog, and the Stakeholders) go together. If I see a Value Backlog, I assume
there is a Business Owner and Stakeholders, if I see a Business Owner, I know there is a Value
Backlog. And there are always Stakeholders…
Original Scrum 16
As you can see, the Business Owner is a good person for the Well-Formed Team to have around,
because the BO both prioritizes and regulates the Items coming into the Well-Formed Team’s Work
Backlog – thus allowing the WFT to focus on its necessary Improvements, Chores, and meeting
the Standard of Care the Items deserve.
Original Scrum 17
Pattern: Agile Product Development

The Business Owner I just discussed is used when we have Value Backlogs that are simply a flow
of work, such as Backlogs of Bugs or service requests, for example. In these cases there is no need
for Agility as we usually think of it.
However, we are often building Products that require some sort of Feedback Loop with the Client;
in other words, we need some Agile Development. In this Pattern I will expand the Business
Owner’s role to include working with a Client to develop a Product in an Agile way. When the
Business Owner and Client have a Project Plan they are working with, I call the Business Owner
a Project Leader.
Problem:
A Client wants a Team to Build and Deliver a Product.
Context:
• There is a Client that wants a Product
• There is a Business Owner working with this Client
• There is a Well-Formed Team that will be building the Product
• Building the Product will be complex, for any of a number of reasons, such as:
– The Client does not have a firm grasp of the requirements, or
– The Well-Formed Team doesn’t know exactly what needs to be done, or
– The requirements are expected to change; they are volatile.
• There may (or may not) be Cost or Schedule constraints that “need to be met”. If there are,
then this effort is called a Project…
Solution:
There are two cases here: either there are Cost or Schedule constraints that “need to be met”, or there
are not. If there are, the Business Owner manages them by preparing and maintaining a Project
Plan, and we call the Business Owner a Project Leader. Basically, a Project Leader is a Business
Owner who is also maintaining a Project Plan. For shorthand purposes, I will refer to this Role as
the BO/PL.
In either case, follow the following Agile Process steps:
1. The Client and the BO/PL discuss what should be built next, put appropriate Items on the
Client’s Value Backlog, and [if applicable] negotiate (or re-negotiate) the Project Plan.
2. The BO/PL moves some of these Items to the Team’s Work Backlog at a rate that will not
overload the Team.
Original Scrum 18
3. The Team builds a Product Increment based on the Items on the Work Backlog.
4. The Client Reviews the Product Increment.
5. If the Product Increment is acceptable by the Client for delivery, then the Team Cleans It Up
and Delivers it.
6. If the Product Increment is not acceptable by the Client for delivery, then return to Step 1.
Agile Product Development

This type of process is Iterative, Incremental, and Agile:
• It is an Iterative process, since the overall process is repeated over and over – it is iterated,
• It is an Incremental process, since the Product is added to (incremented) every Iteration, and
• It is an Agile process, since the content of each Iteration is based on current knowledge.
This is a very simple Agile Development Process. During the Development, there is an ongoing
creation of a flow of new Items being placed on the Client’s Value Backlog, based on the Client’s
Review of the Product Increments and [if applicable] re-negotiations of the Project Plan. This
Value Backlog is represented (to the Team) by the BO/PO, and is forwarded to them via their
Work Backlog
Original Scrum 19
Simple Business Owner - no Cost or Schedule Constraints
Let me give a simple example for the case that the Agile Development is ad hoc, there were no
negotiated time or money constraints – we just got done when we got done. This example is when
my son and I (the Well-Formed Team ) built garden beds for my Wife (the Client ) one vacation.
Every morning my son and I would get up, eat some breakfast, and then spend a few hours working
on the garden. We would go inside to clean up for lunch, and my wife would come outside and
look at what had been done. After my wife had wandered around for a bit (Reviewing the work),
I (playing the role of Business Owner) would go out and talk with her to discuss what we should
work on next. Then we’d all eat lunch and enjoy the rest of the day. We went through this process
(Iterated) every day. After about 3-4 days, she liked what she saw, and the next day my son and I
Cleaned Up the area, took tools back to the rental place, took the detritus to the dump, and so on.
The day after that my wife took over the Garden (we Delivered) and started planting flowers. And
now we all have a garden.
Note that this simple Business Owner is not significantly different from the one we saw before, if
there is no Project Plan involved. Because of the Agile Process in use here, the Client is constantly
working with the Business Owner to figure out what to do next. As in the previous Pattern, the
Business Owner is merely forwarding these new Items to the Well-Formed Team’s Work Backlog
at an appropriate rate.
Business Owner as Project Leader
It is very common that the Business Owner is actually a Project Leader, and I’ll give a few
examples. The first one will be fleshed out in some detail, and the others are just suggestions for
Projects – you fill in the blanks.
1. Let’s say you want to have your kitchen re-modeled, so you hire a General Contractor to do
it for you. Then you are the Client and the General Contractor is your Project Leader. The
Project could go something like this:
• You and the General Contractor draw up blueprints and sketches; pick out some floors,
cabinets, counters, and appliances; and negotiate a price and schedule.
• The Contractor’s workmen (the Team) demolish the existing kitchen, dig into the walls,
and start re-plumbing and rewiring the new kitchen. The workmen find mold in the
walls, notify the Contractor, and the Contractor calls you in for a Review and potential
Re-Negotiation.
• It’s not the Team’s fault that there’s mold, so either the price goes up, or you cut some
corners. You choose to use less expensive flooring, and the price and schedule remain
unchanged.
• The next day you go visit a friend and see some real cool appliances – not the ones you
negotiated for – and you ask your Contractor about them. You do another Review of
the kitchen and discuss how it could look. You both agree the new appliances would
be great, and the Cost goes up $3000 and the Schedule pushes out 2 weeks because he
needs to order the new Appliances from Germany.
Original Scrum 20
• A week later the Contractor calls and offers you a stunning deal on some granite counter-
tops that he has left over from a Restaurant job. They’re not exactly the color you want,
so you go Review the kitchen and take a look at a sample of the counter-top. It’s not
what you really want, but you can’t turn it down as it saves you $2000 and it’s available
to be installed right now.
• Because of the new counter-tops, the tiles on the back-splash have to change as well as
the overall paint scheme. These changes are no-cost, so you go for it…
• Finally, you get a remodeled kitchen. It is about 20% different from the way you originally
envisioned it, it cost $1000 more than you originally thought, and it’s 2 weeks late. Believe
it or not, though, you’re really happy… you got the mold taken care of, and you were in
the loop every step of the way.
2. Fixing your car that was in an accident, where the Insurance Company has simply given you
a check for $8000 to fix it with.
3. Landscaping your new yard because all you got with the house is one little tree and some sod.
You have a self-imposed budget of $20,000.
The Project Leader (PL) role represents the ‘project management’ part of a Project Manager - it
does not include the ‘people management’ part of the Project Manager. The Project Leader role,
as I describe it, is based on the appropriate parts of the PMI’s PMBOK, which says that the Project
Leader has two main responsibilities:
1. To Develop a Project Plan, and

2. To Update/Maintain the Project Plan throughout the Project so that it accurately reflects
the Reality of the Project at all times.
And (to keep it simple) the Project Plan (the Plan) contains definitions and estimates for:
• Cost: The best, good-faith, estimate of what it will cost to Deliver an acceptable Product;
• Scope: The expected “content” of the Product’s Value Backlog; and
• Schedule: The best, good-faith, estimate of when the Team will Deliver an acceptable
Product.
Usually, the Cost, Scope, and Schedule are Planning Values that are derived from Planning
Assumptions that are made and monitored by the Project Leader. For example, the following might
be the initial Baseline Values for a Release Plan:
• (Assumption) Baseline ReleaseSize = 1000 StoryPoints, and

• (Assumption) Baseline ProductionRate = 10 hrs/SP, therefore,
• (Derived) Baseline TotalHours = 10,000 hours ∼ 5 person-years. Also,
• (Assumption) Baseline BurnRate = 1,000 hours/Iteration, so
Original Scrum 21
• (Derived) Baseline Duration = 10 Sprints = 20 Weeks. And

• (Assumption) Baseline HourlyRate = $150/Hour, so
• (Derived) Baseline Cost = $1,500,000.
As the Release/Project commences, the Project Leader monitors and updates the Planning
Assumptions to match the Reality being observed, derives new Planning Values, and adapts the
Plan as necessary. This process often summarized by saying that the Project Leader makes sure
that the Plan and Reality match. Using this formulation, we have:
• a bad Project Leader is one who tries to force Reality to match the Plan, and
• a good Project Leader is one who modifies the Plan to reflect Reality.
This Pattern requires good Project Leaders; that is, Project Leaders who update the Project Plan
rather than try to change Reality. This is not easy, by any means. The following things are discussed
and negotiated between the Project Leader and the Client:
• Contents of the Project Plan,

• Whether or not the current Product Increment is acceptable for Delivery, and
• What it will take for a future Product Increment to be acceptable for Delivery.
These negotiations often result in balancing trade-offs between the overall Scope versus the overall
Cost and the overall Schedule, and these changed values are what is contained in the current
Project Plan. If there is a contractual relationship between the Project Leader and the Client (with
the Project Leader representing the Contractor), the final decision-maker about these trade-offs
depends on the type of contract. Since the purpose of a contract is to balance the risks appropriately³,
this means:
• in a Fixed-Price contract, the decision-maker is the Project Leader, as it is the Contractor

who is absorbing the risk, and
• in a Time-and-Materials contract, the decision-maker is the Client, as it is the Client who
is absorbing the risk.
I will use the term Project Leader (PL) throughout this book to refer to the Business Owner who
manages the Product’s Value Backlog and is also accountable to develop and maintain the Project
Plan. Remember that “accountable” means “can be held to account” or “must be able to explain the
decisions involved” - it is not simply a blame-setting exercise.
Anyway, this Project Leader is a specific kind of Business Owner that we see…
³See the Federal Acquisition Regulation (FAR)
Original Scrum 22
Original Scrum Discussion

We finally have all we need to discuss Original Scrum. As you can imagine, Original Scrum is a
combination of all the Patterns we’ve seen so far, and is limited to a single, small, fixed-size, co-
located (at least virtually) Scrum Team Developing and Maintaining a single Product.
Scrum has a very simple set of rules:
1) There are three Roles: the Product Owner, the Scrum Master, and the Development Team
• The Product Owner is a strange amalgam of the Business Owner, Project Leader, and
Client (I’ll discuss this later),
• The Scrum Master is the Development Team’s Team Coach, and
• The Development Team is a small (5-9 people), fixed-size, Well-Formed Team that will be
doing the work.
Original Scrum
2) There are a small number of Practices:
• There is a Sprint, which is which is the length of the Development Iteration.

• There is a Backlog that consists of all Items of work for the Product.
Original Scrum 23
• The Backlog contains the Stakeholders’ Value Backlog, which is a list of Items (in the Stake-
holder’s language) that will provide value to the Stakeholders, and that the Stakeholders
want the Team to do. Typically, these consist of Features (Development work) and Defects
(Operations work)
• The Backlog contains the Team’s Work Backlog, which consists of a list of the Items that
have been passed through (approved by) the Product Owner to be actually done by the Team.
(Just because the Stakeholders want them does not mean the Product Owner wants the Team
to do them.)
• Each Sprint starts with Sprint Planning, which is when the Development Team and the
Product Owner discuss and negotiate the content of the upcoming Sprint. There are two
parts:
– In Part 1 the Product Owner and the Development Team discuss what should be done,
and the Development Team commits to which Items from the Backlog they will get
Done in the Sprint
– In Part 2 the Development Team decomposes these Items into Tasks, and these Tasks
are collectively called the Sprint Backlog
• As the Team does work in the Sprint,
– the Development Team has daily Standup meetings, which are a formalism of the Well-
Formed Team’s frequent Coordination Meetings,
– the Development Team produces a Product Increment by doing its due diligence and
completing the committed-to Items to the appropriate Standard of Care, and
– the Development Team does the Improvements and Chores they find necessary.
• At the completion of the Sprint,
– the Product Owner Reviews the Product Increment and determines if it is acceptable
for delivery. If the Product Increment is acceptable for delivery, then the Team cleans it
up and delivers it. If it is not acceptable for delivery, the Product Owner may advertise
predicted Delivery Dates to the Stakeholders.
– the Scrum Master has a Retrospective with the Development Team, which is a
formalism of the Reflections the Team Coach has with the Well-Formed Team.
The Product Owner is Complicated

I mentioned that the Product Owner is an amalgam of the Business Owner, Project Leader, and
Client. Here’s why I said that:
• the Product Owner “owns and manages” the Backlog, and this makes him the Business
Owner, as the Product’s Value Backlog is part of the Backlog, and the Business Owner
manages the Value Backlog…
• the Product Owner Reviews the Product Increment. This makes him the Client, as it is the
Client who Reviews the Product Increment to see if it is acceptable…
Original Scrum 24
• the Product Owner predicts and advertises Delivery Dates and, because the Team is fixed-
size, this determine both the Schedule and the Cost. Since the PO already manages the
Backlog (which defines Scope), this means the Product Owner determines the Project Plan
– which makes the Product Owner the Project Leader.
Here is the greatest quote I know about the Product Owner, from the first Scrum book, Agile
Software Development with Scrum, Schwaber and Beedle, 2002, pg 34: “For the Product Owner to
succeed, everyone in the organization has to respect his or her decisions. No one is allowed to tell
the Scrum Teams to work from a different set of priorities, and Scrum Teams aren’t allowed to
listen to anyone who says otherwise.” (emphases mine) This prioritization of the Backlog is the
defining characteristic of the Product Owner, even though there are all the other responsibilities
listed above.
Issues
The Original Scrum as defined here is a beautiful thing, and can be, and has been, used to great
effect. However, there are some issues – see if you recognize them…
Value Backlog and Work Backlog “don’t match”
A Value Backlog consists of Items that the Stakeholders can discuss and understand, while the
Work Backlog consists of Items that the Development Team understands and can implement. It
is the Product Owner’s job to convert the Stakeholders’ Value Backlog into the Team’s Work
Backlog, and they may be at different levels of abstraction, which can cause problems. For example,
Stakeholders may think about Use Cases or Features, while the Development Team needs to be
able to focus on small bits of Functionality, like Scenarios or other Items defined by Acceptance
Tests.
This issue will be addressed with the Team Leader Pattern.
Improvements and Chores
In a Scrum Team the Development Team is a Well-Formed Team that determines and works on
its own Improvements and Chores. The time spent doing this is not managed from outside the
Team. Many Organizations have problems with this, and want control over this work – and this can
cause problems with the Team’s Self-Organization.
Product Owner as Project Leader
The Product Owner (as Business Owner) Manages the Backlog, which defines the Scope of what
the Scrum Team is working on. When the Scrum Team is doing Project work, the Product Owner
Original Scrum 25
(in the Project Leader role) can project Delivery Dates. Many Product Owners are bad Project
Leaders, and try to force the Development Team to meet unrealistic Delivery Dates⁴, rather than
projecting Delivery Dates based on the Reality of the Team’s Production Rate. In fact, this is
such a problem that many Scrum Trainers have said that one of the Scrum Master’s primary
responsibilities is to protect the Development Team from these bad Project Leaders masquerading
as Product Owners.
Coercive Planning
In Original Scrum the Development Team commits to the work they will do in a Sprint, in spite
of the fact they they don’t know how much effort it will take to meet the appropriate Standard
of Care or how much work they will need to spend on Improvements and Chores. How can this
work? The Development Team is being set up to fail.
This issue is discussed in the Forecast, don’t Predict Pattern.
Predictive Planning
In Original Scrum the contents of the whole Sprint are determined at the beginning, during Sprint
Planning. This is a predictive process. How do the Team and Product Owner know what they will
need to be doing 2 weeks from now? Maybe there will be a show-stopper bug that turns up… maybe
the Stakeholders will realize that they’ve changed their minds… I don’t know. We would expect
Agile methods to avoid making predictions, wouldn’t we? We would expect the actual content of a
Sprint to evolve throughout the Sprint, wouldn’t we?
This issue is discussed in the Forecast, don’t Predict Pattern.
The ScrumMaster often becomes a Manager
When the Product Owner is separated from the Team, the Product Owner often wants to hold
someone on the Team accountable, or answerable, for what the Team is doing. If nothing else, the
Product Owner often wants a Point of Contact (POC) on the Team, and this POC winds up with
de facto Management Authority. So far, so good…
The problem is that this POC is often the ScrumMaster, who can be seen as “Second in Command”
or as a junior (or Proxy) Product Owner. As we say in the Team Coach Pattern, this is dangerous,
and could defeat the purpose of being a Team Coach - so don’t do it!!
⁴Ken Schwaber calls this the “Mother of all Problems” in his 2007 book: The Enterprise and Scrum, pg. 93.
Original Scrum 26
Misunderstanding of the phrase “Potentially Shippable”
This issue doesn’t show up because of the Patterns, but it has caused a lot of problems, so I’ll mention
it. It has always been a rule of Scrum that the Development Team produce a Potentially Shippable
Increment each Sprint, and some have read this to mean that they must Ship Product every
Sprint. This has led to some seriously hacked-out Code, and a complete disregard of any reasonable
Standard of Care. This is exactly the opposite of what is supposed to happen… the intention of of
the Potentially Shippable idea is that it should cause the Team to follow an appropriate Standard
of Care. Here is the quote⁵
“Scrum requires Teams to build an increment of product functionality every Sprint. This increment
must be potentially shippable, because the Product Owner might choose to immediately implement
the functionality. This requires that the increment consist of thoroughly tested, well-structured,
and well-written code that has been built into an executable and that the user operation of the
functionality is documented, either in Help files or in user documentation. This is the definition of
a “done” increment.”
As you can see, this definition of a Done Increment (Potentially Shippable) is about Quality – the
Standard of Care that must be followed. Unfortunately, many have seen it as required Releasable
Code, which means Code that the User can actually use, which has led to hacking our bad Code
that has a lot of features. The work that lives in the “Done but not yet actually Releasable” is often
called Undone work; a simple example of this is when my son and I cleanup of the Garden and took
the tools back to the Rental Place before actually “releasing” the Garden Beds to my wife.
Anyway, the entire point was missed by some people, and the idea was turned upside-down and
inside-out. Such a shame…
This issue will be addressed with the Definition of Done Pattern.
Development Teams write Bad Code
There are two reasons Development Teams write Bad Code:
1. Most Developers don’t know how to write Good Code (or Clean Code) – they don’t
understand their Craft.
2. A Team trying to meet unrealistic deadlines is often forced to write Bad Code – the “Mother
of all Problems” I mentioned above.
What is Clean Code? In many (if not most) professions there is the notion of due diligence to meet
a Standard of Care; not doing one’s due diligence is considered malpractice - and malpractice
will get you kicked out of the profession.
Not so with software.
⁵Agile Project Management with Scrum, pg. 12.
Original Scrum 27
There are no universal standards or requirements for software developers. We all want software to
satisfy the ‘-ilities’ (reliability, extensibility, maintainability, etc.), but there is no requirement for
software developers to do their due diligence to make this happen. There are some standards that
pertain to software in certain Industries or situations (FDA, FAA, Sarbanes-Oxley, etc.), but these
standards are usually considered part of the Acceptance Criteria rather than as part of the Standard
of Care. In software, the Standard of Care would be about how to write Clean Code (including
analysis, design, code, test, etc.), not how to satisfy the requirements.
In software there are documented Best Practices about Software Craftsmanship, as we see in
the eXtreme Programming (XP) practices, or in the books Clean Code by Bob Martin and Working
with Legacy Code by Michael Feathers, and many others; but there is no requirement for software
developers to either know, understand, or use them – there is no requirement to treat our vocation
in a Professional way. This is unfortunate, and the reason that Scrum brought the Well-Formed
Team pattern into software.
This issue will be addressed by the Definition of Done Pattern.
Project Management Pressures This is what Ken Schwaber calls the “Mother of All Problems”⁶,
where he talks about how Legacy Code becomes Legacy Code. The basic idea is simple:
• Trying to make dates causes the Team to take shortcuts,

• These shortcuts must compromise Code Quality, because there is no wiggle room in the other
variables (Cost, Scope, and Schedule),
• As the Quality decreases, the shortcuts become more and more drastic to keep up with
schedules, and
• The result is Dead Code (Code that can’t be extended or maintained) in just a few Sprints…
This can only be handled by having a Team do its due diligence and having good Project Leaders
– see the Agile Project Leader Pattern. If there are bad Project Leaders the only defense is the
Professionalism of the Team Members.
This issue will be addressed by the Definition of Done Pattern and the separation of the Project
Leader from the Team.
Basic Scaling Issues
And, finally, there are problems based on Scaling. There could be more than one Product involved,
there could be more than one Team involved, or the Team could be in more than one (virtual)
location. There’s not a lot we can do about this last one – it seems to be intractable – but We’ll
address multiple Teams and multiple Products issues later, when we talk about Scaling.
⁶The Enterprise and Scrum, pg. 93
Modern Scrum
Original Scrum works very well for mature Teams in good Organizations. Not surprisingly, less
good otherwise. Since 2004 (or so) several improvements/changes have been made to Scrum to make
it more useful. I will still assume there is a single Team working on a single Product, but I’ll introduce
the following Patterns that improve things:
• Team Leader,
• Subject Matter Experts,
• Definition of Done, and
• Forecast, don’t Commit (and others)
Modern Scrum 29
Pattern: Team Leader

Original Scrum is very powerful, but the fact that the Product Owner is outside the Scrum Team
can cause problems. We solve these problems by having a Team Leader.
Problem:
One or more of the following Statements is true:
1. The Business wants to make sure the Development Team’s Improvements and Chores get
prioritized “against” the Items coming from the Business Owner’s Value Backlog – the
Business doesn’t want the Development Team making these decisions as part of their Self
Organization.
2. The Development Team needs ongoing “tactical” advice – during the Sprint – about what is
most important about the Items that are being worked on as part of the Sprint Backlog.
3. The Items being prioritized from the Stakeholder’s Value Backlog are not well enough
understood for the Team to work on – they need to be Refined before they become
appropriate for the Team to work on them.
4. The Product Owner needs a Point of Contact on the Team to hold Accountable, or
answerable, for the Team’s actions.
Context:
There is a Original Scrum Team working on Items being prioritized by a Product Owner external
to the Team.
Solution:
Have a member of the Scrum Team, called the Team Leader, with the following Accountabilities:
• The Team Leader is Accountable to the Product Owner for the prioritization of all the work
done by the Scrum Team, including Improvements and Chores,
• The Team Leader is Accountable for Refining the Items coming from the Value Backlog
so that they are Ready for the Team to work on. Note that Refinement includes:
– decomposing “big” Items into “smaller” Items,
– extracting sub-Items from Items,
– improving Items so they are better understood,
– and so on…
Modern Scrum 30
You should be wary of making the Team Leader the same person as the Team Coach, because this
could impinge upon the Team Coach’s “regulatory” responsibilities. This is not a universal truth,
but certainly seems true for Scrum Teams doing Software Development.
Additionally, make sure it is understood that the whole Scrum Team is supposed to be a Well-
Formed Team (not just the Development Team), so that ScrumMastering and Product Ownership
responsibilities belong to the whole Team – the Self-Organization is not simply about Develop-
ment.
The Team Leader

This is a common pattern, and I’ll just give two simple examples:
1. In a Restaurant’s Kitchen, we know that the Kitchen’s Value Backlog consists of Food Orders
provided by the WaitStaff. Inside the kitchen, however, the Sous Chef is running the show, and
is accountable for “the kitchen’s inventory, cleanliness, organization and the ongoing training
of the entire staff”⁷. The Sous Chef prioritizes the work inside the kitchen; when to clean,
train, and so on. These Improvements and Chores are added to the Kitchen’s Work Backlog
along with the orders coming in.
⁷See Wikipedia.
Modern Scrum 31
1. Workmen working on site have a Foreman who works as the Team Leader. The Business
Owner assigns the Job to the Team, but the Foreman works with the Team to divide the Job
into sub-Jobs and Tasks, as well as determine what Chores need to be done.
In many writings about Scrum, this Team Leader is referred to as the Proxy Product Owner.
Modern Scrum 32
Pattern: Subject Matter Experts

Scrum Teams are supposed to be Self-Contained – but many of them aren’t.
Problem:
Many Scrum Teams aren’t Self-Contained; they lack some skills they need.
Context:
There is a Scrum Team working on Item from their Work Backlog. Some of the Items require
expertise the Team does not have. This expertise could be:
• Technical Expertise the Team needs to complete its work,

• Business Expertise to better understand the Item’s Acceptance Criteria, or
• Expertise in Refining the Value Backlog’s Items to be more appropriate for the Team to
work on.
Solution:
Have Subject Matter Experts (SMEs) join the Team, as honorary Team Members, when the Team
needs to use their expertise.
Modern Scrum 33
Subject Matter Experts

These SMEs come in many forms: they could be Stakeholders that are providing business-
knowledge help on specific Items; they could be technical SMEs, like Architects, Usability experts,
Business Analysts, or Technical Writers; they could be helping the Team working on Improvements
or Chores, they can be shared across several Scrum Teams, they can be just about anything.
Normally, the need for a SME is determined by the Development Team and the ScrumMaster, and
the ScrumMaster works with the Team Leader and Product Owner to find and acquire the SME.
Subject Matter Experts are usually with the Scrum Team for a short period of time, and are often
thought of as being extensions of the Team, I have heard of the Scrum Team, along with its SMEs,
referred to as the Sprint Team – indicating the fact that they are part of the Team for the duration
of the Sprint.
Often, it is a good idea to use SMEs as Mentors, rather than having them do the work themselves.
In this way, the Scrum Team Members become less reliant on them, which decreases the “lottery
metric”⁸ for the Team. My favorite pattern for using SMEs is the Buddy Up Pattern, which identifies
an existing Team Member to be the SME’s Buddy. This Buddy is Accountable to the Team for work
the Team needs the SME to do, or help do. The SME and the Buddy work together, with the SME in
⁸The number of people who have to “win the lottery” before your Organization is totally screwed.
Modern Scrum 34
a mentor role, in order to do the work. This both gets the work done, and makes the Buddy smarter,
decreasing future need for the SME.
Modern Scrum 35
Pattern: Definition of Done

Well-Formed Teams are supposed to have a Standard of Care that they follow, because they are
Professionals. Unfortunately, in software, most don’t seem to…
Problem:
The Scrum Team Members don’t use, or don’t know, an appropriate Standard of Care in their
work.
Context:
You have a Scrum Team doing work, and the work they are doing is not meeting an appropriate
Standard of Care.
Solution:
Attach a Definition of Done to each Item (augmenting the Item’s Acceptance Criteria) that assures
that the Item is developed with an appropriate Standard of Care. The ScrumMaster works with
the Team to assure that the Item meets this Definition of Done as the Item is being worked on.
Definition of Done
Modern Scrum 36

Well-Formed Teams are supposed to be Professionals, and come prepared with their own Standard
of Care that they do their due diligence to meet every time they do work. The Stakeholders are
relying on this when they use a Scrum Team. In software, an example of this is a Development
Team that diligently uses the XP Technical Practices and see themselves as Professional Software
Craftsmen when they develop their Code.
Often, the Team Members don’t have an appropriate Standard of Care – they’ve never been taught,
they’ve never learned, they’ve never used, they’ve never seen such a thing. So, we often have the
ScrumMaster (in the role of Technical Coach) help the Team develop, and continuously improve,
their own Standard of Care. In the Scrum Community, this is called “having a Definition of Done”.
Here is an example of an Item with both Acceptance Criteria and Definition of Done for an Item
involving an Airline website.
Definition of Done Example
When there is more than one Team working in the same Codebase, they each should use the same
Definition of Done, as they will be working with each others’ Code. Each Team needs to trust the
Modern Scrum 37
other Teams’ Code as much as they trust their own – they need to know that the other Teams used
their due diligence and met the same Definition of Done as they did.
Usually, each Item has its own Definition of Done, but some Teams have applied the concept to the
Product Increment, instead. Some Teams have used a common Definition of Done for all Items,
others have custom Definitions of Done for each Item. The Team could use different Definitions
of Done for different kinds of Items (this is called Storyotyping⁹. It really doesn’t matter, as long
as everybody trusts that the Results are as “good” as they need to be, all the time.
Sometimes the Team can’t meet its Definition of Done, either intentionally or unintentionally.
When they do this we say that they have Unfinished Work. This work may need to be Delivered
or Reviewed for perfectly valid business reasons (Trade Show, big Client, whatever), but the Team
may not pretend that the Work was Done – the Team Members may not pretend that the Work
met an appropriate Standard of Care. When this kind of stuff happens, they need to add a Cleanup
Item – one that promises to clean up, or finish the work – to the Backlog, so that nobody will forget
it; so that the Team will get the work Done as soon as possible.
Sometimes there is a delta between being Done and being Releasable – delta is called Undone
work. This is not a bad thing, but deciding what to leave Undone is a decision that needs to be
made. For example, deciding to leave off polishing the User Documentation until the end may be a
good decision, but deciding to delay collecting the information for the user documentation until the
end probably isn’t.
The Definition of Done can be extended to be a robust Standard, including standardizing
architectural and design patterns, providing necessary reviews and inspections, and so on. It is
something worth standardizing, in my opinion, as it provides an anchor for the Teams to Self-
Organize around – “this is what we’ve got to make it look like, how do we do that?”
Because not all ScrumMasters are technical, this could Lead to a Technical Owner or Coach role
on a Team, who would be a Team Member who was Accountable for the existence of, training on,
and use of, an appropriate Definition of Done.
⁹See chapter 3.10 of Exploring Scrum: the Fundamentals.
Modern Scrum 38
Pattern: Forecast, don’t Commit (and others)

There have been many changes in the way a Scrum Team plans its Sprints
Problem:
The Sprint Planning meeting in Original Scrum is both Coercive and Predictive, and each of these
is a bad thing, as is discussed in the discussion of Original Scrum.
Context:
You have a Scrum Team doing work, and you want to change the Sprint Planning so that it is less
coercive and/or predictive.
Solutions:
Each of these problems, as well as other planning problems, have been addressed in Modern Scrum;
in fact, there have been several improvements in Sprint Planning that we often see:
1. the notion of “committing” to a Sprint Backlog has been removed. Currently, Sprint Planning
produces a Forecast of what might get done, and this is called the Sprint Backlog. This makes
Sprint Planning less Coercive, but may not make it less Predictive – the Team Members are
still predicting what they will be doing later on in the Sprint.
2. The original ‘2-pass’ Sprint Planning has been largely replaced by ‘1-pass’ Sprint Planning,
which brings current reality into the planning, making the planning, itself, more agile and
correct¹⁰.
1. It is now recommended that Sprint Planning does not fill up the Sprint – planning is now
somewhat malleable, making it less predictive. In the more recent Scrum Guides, Ken and
Jeff have stated that the initial Sprint Backlog (the result of Sprint Planning) only fills up
about 80% of the effort available in the Sprint, with remaining Sprint Backlog Items arising
throughout the Sprint.
2. There is a move to doing a more kanban-ish version of Sprint Planning, where the Sprint
Planning meeting only selects the Sprint Backlog Items that will be started right now, and
additional Items will be brought into the Sprint as existing Items get Done¹¹.
¹⁰See the “Agreement-Based Planning” chapter of Exploring Scrum: the Fundamentals.
¹¹See the “Kanban(ish) Variant” chapter of Exploring Scrum: the Fundamentals.
Modern Scrum 39

Over the years, there was a realization that the Sprint is a feedback cycle, not a planning cycle or
a work cycle. Along with this realization came the idea that Sprint Planning was not the big deal
everybody thought it was. People realized that, logically, Sprint Planning is not actually necessary;
if there is a prioritized Work Backlog, and each Item on the Work Backlog has a well-defined
definition of Done (the combination of the Acceptance Criteria and the Definition of Done), then
the Scrum Team just has to work its way through the Work Backlog, in order, and Review whatever
is actually Done at the Product Review.
This is a tremendous refutation of the predictive planning we often see in non-Agile development.
This realization led to all sorts of innovations in Sprint Planning – including what is listed above.
My personal recommendation is that a Team should do kanban-ish planning once the Team has
become mentally agile. This type of planning is neither Coercive nor Predictive, seems to be the
right way to go in an Agile Development.
Modern Scrum 40
Modern Scrum Discussion

So, I finally have what I need to describe Modern Scrum, which is basically Original Scrum with
the modifications described in this Chapter:
• The addition of a Team Leader, the Team Member who is accountable to the Product Owner
for the value of the work performed;
• Making the whole Team (not just the Development Team) into a Well-Formed Team, and
adding the responsibility to Refine the Items on the Work Backlog in order to make them
Ready to work on;
• Inserting the Scrum Team’s Improvements and Chores directly into the Work Backlog,
where they are Refined and prioritized along with the other Items derived from the Value
Backlog;
• The addition of Subject Matter Experts who provide knowledge and expertise that the Team
needs, but does not have;
• Using the Definition of Done to impose the use of an appropriate Standard of Care by the
Team; and
• Changes to Sprint Planning to make it less Predictive and Coercive.
Product Owner Re-Definition

But, there’s one more thing; and it’s a big thing – we discussed (and argued) about this one a lot
in the Scrum Community. This Team Leader role was called the Proxy Product Owner for a
while, and then it was decided that, no, this Team Leader is actually the Product Owner – that the
Product Owner had to be a Scrum Team Member; a part of the Self-Organized Team – and this
decision was made in about 2005 or so.
Some are still fighting about this, but I agree with it whole-heartedly, and it is clearly assumed to
be true in The Enterprise and Scrum, which was published in 2007. For example:
• on page 73: “The Product Owner and ScrumMaster are the first people on a Scrum Team.”
• on pages 76-80 there are diagrams (figures 8-6 and 8-7) showing hierarchies of Scrum Teams
with Product Owners and ScrumMasters at each level. In fact, the definition of the Product
Owner in this book (pg. 114) is team-focused: The Product Owner is “the person who is
responsible for what the Scrum Team builds and for optimizing the value of it.”
So, it’s a done deal, as far as the “official” definition of Scrum is concerned – at least the way I
interpret it. But it causes us problems, because the Product Owner role in Original Scrum is not
the Product Owner role in Modern Scrum. Oops… so I’m going to go back to calling the original role
either the Business Owner or the Project Leader depending on whether or not the Stakeholder’s
Modern Scrum 41
Value Backlog is project-based – I tend to think of a Project Leader as the Business Owner of a
Project. Anyway, here’s my picture of Modern Scrum.
Modern Scrum
Now, one could argue, and many have, that the Business Owner and the Product Owner could be
one-and-the-same person. I agree, in principle. However, I don’t want the Product Owner to be the
Project Leader – the Development Team must be separated from the potential of a bad Project
Leader – a bad Project Leader can have a very coercive and damaging effect on the Team, and
thus the Product itself.
Review of the Accountabilities in Modern Scrum

Earlier I discussed how important a Role’s Accountabilities are. Because of the self-organization
inherent in Scrum, the Responsibilities are often smooshed around and shared amongst people.
Accountabilities are different; each Role can be defined by a single Accountability – I refer to this
as the Roles OBT (One Big Thing). Here they are:
• Team Member: Accountable to other Team Members for doing his/her due diligence and
using the appropriate Standard of Care to help Stories meet their Acceptance Criteria and
Definition of Done. Each Team Member must be able to explain to other Team Members
what he/she is working on, what issues issues are cropping up, what help is needed, and so
on.
Modern Scrum 42
• ScrumMaster: Accountable to Management to make the Team better through the use of
Scrum. Must be able to explain what Impediments the Team has, and what the Team is
doing to mitigate or remove them.
• Product Owner: Accountable to Management to optimize the value the Team produces;
accountable for optimizing the value represented by a Work Backlog. Must be able to explain
what work the Team is doing, why it’s important, and the status of it.
• Business Owner: Accountable to Management to optimize the value of a Product, Project,
Release, or similar externally-visible Results: accountable for optimizing the value repre-
sented by a Value Backlog. Must be able to explain the Items in a Value Backlog and why
they are important.
• Project Leader: A Business Owner who is also accountable for predicting Release Dates
and/or keeping a Project Plan in balance with Reality. Must be able to explain the rationale
for Planning Assumptions, the derivations of Planning Values, and the intended effects of
actions taken to balance the Project Plan.
Problems with Modern Scrum

As has been discussed throughout, Modern Scrum solves many of the problems that existed in
Original Scrum. In fact, I see Modern Scrum as a well-oiled machine – as a balanced collection of
Patterns. It is a very good thing. However, there are three issues that still remain:
1. the Project Leader (if there is one) must be a good Project Leader. There is no way we could
guarantee this, but at least we have both the Product Owner and ScrumMaster protecting
and shielding the Team from this potential bad Project Leader – as long as we keep the
Project Leader outside the Team.
2. Modern Scrum still assumes a single Product; and
3. Modern Scrum still assumes a single Scrum Team.
These last two Issues are Scaling Issues, which I will discuss in the next section.
What We Learn from Scrum - the
Principles
Well, so far we’ve seen the Patterns that Scrum is made up of – both Original Scrum and Modern
Scrum. In the rest of this book I’ll be exploring Patterns that are used to extend Scrum; to allow it
to Scale and work in other contexts. Remember that Scrum, as it is defined, is only applicable to a
single Scrum Team working out of a single Value Backlog, or Project.
So, what lessons have we learned that we can re-use when extending Scrum? Are there any
“universal truths” that we have learned? Any patterns? What Principles have we learned?
Well, here’s what I think are some of the Principles we’ve learned:
1. You should solve hard problems with Well-Formed Teams – this was our most basic Pattern,
and our fundamental Principle.
2. You shouldn’t dismantle existing Well-Formed Teams; it takes a long time for a WFT to gel
and become high-performing, and most of us believe that it is easier to change Domains than
it is to being a new Team up to speed. I will admit that this is not a universal Principle, but it
seems to be pretty good advice when it comes to Software Development Teams.
3. Here are some Principles we learned about decision-making, and that I like to learn:
• A Trivial Decision can be made by a Rule,
• An Easy Decision can be made by an individual Person, who must accept Accountabil-
ity for that Decision – I will call these People Leaders ro Owners, and
• A Hard Decision should be made by a Scrum Team.
– It is a hard problem to determine the available options, so this “staff work” requires
a WFT, and
– Somebody on that WFT must have Accountability for that Decision (a general rule
in Scrum) – and this Person would be a Product Owner, hence
– we have a Scrum Team.
• Since Easy Decisions often become Hard, I will always suggest that Scrum Teams make
all non-Trivial Decisions. My basic philosophy here is “Rules don’t make Decisions,
People do.”
• By the way, Rules are different from Rules of Thumb, which are guidance, not
directives. We often use Rules of Thumb to help our Decision-Making, but they are
merely advice or guidance… we make the Decisions, not the Rules of Thumb.
4. Don’t overload Decision-Makers in your Frameworks or Patterns. You can’t assume you
will get Heroic Decision-Makers when you instantiate the Framework or Pattern – you
may get one, so you can collapse your instance, but you can’t assume you will get one… just
sayin’…
What We Learn from Scrum - the Principles 44
I will use these Principles in order to describe and justify most of the Patterns I will introduce.
Scaling Patterns
As we have just seen, Modern Scrum is a wonderful Framework that is designed for one Team
producing one Product at one (virtual) Location. When doing real work, in a real Organization,
there are three different things that scale:
• when there’s more than one Team,

• when there’s more than one Product, and
• when there is more than one (virtual) Location
From now on, I’m going to restrict myself to Software, as these problems have too many variables
otherwise…
Multiple Locations
The last case – more than one (virtual) Location – is easily handled – it won’t work within the same
Software Development Scrum Team. You need to add technology so that the Team Members have
high-bandwidth communications with each other for at least 3-4 hours a day in order to get the
communications between the developers that is needed to develop software. This notion of having
3-4 hours a day to talk is what I mean when I say Virtual Co-Location - and it is necessary.
Backlogs
So, I will focus on the patterns for the first two Scaling Issues: multiple Teams and multiple Products.
And, I’m going to move away from talking about a single Backlog, and start talking about the Value
Backlog and Work Backlog. As we see in the picture of Modern Scrum, we have four different
Backlog-ey things when looking at a single Development Scrum Team:
• Value Backlog – Prioritized list of Items, represented by a Business Owner, that are up-
stream from the Scrum Team. The Scrum Team does not deal with them directly, they are
placed on the Team’s Work Backlog by the Business Owner.
• Work Backlog – Prioritized list of Items (including the Scrum Team’s own Improvements
and Chores) that are being Refined to become Ready for the Scrum Team to work on.
• Sprint Backlog – the actual Tasks that the Scrum Team is working on now, in the current
Sprint
Scaling Patterns 46
Basic Symbology
Let me explain the symbols on the right side of this diagram in more detail:
Value Backlog
A Value Backlog is a flow of Items from a “from” entity (the Stakeholders in this case) to a “to”
entity (The Business Owner / Project Leader (BO/PL) in this case). The “from” and “to” entities
collaborate on the ordering/prioritization of the Value Backlog, and the “to” entity is Accountable
for understanding and representing this Value Backlog to the Organization. Generally speaking,
the Items don’t change as they move through a Value Backlog.
Work Backlog
A Work Backlog is a flow of Items from a “from” entity (the BO/PL in this case) to a “to” entity
(The Product Owner (PO) in this case), with the following properties:
• The “from” Entity is Accountable for ordering/prioritizing, understanding and representing

the inputs of this Work Backlog to the “to” Entity.
• The “from” and “to” Entities work together to Refine the Work Backlog (with the “to” Entity
being Accountable for this work) so that:
– The Work Backlog accurately and appropriately represents its Inputs
– The Work Backlog is appropriate for use the “next level down”
– Note: This Refinement is represented by the tapered shape of the symbol
• The “to” Entity is Accountable for inserting appropriate Chores and Improvements into the
Work Backlog – these insertions are represented by the lighter-shaded entities in the symbol.
Scaling Patterns 47
– I often call both these things Chores in order to indicate that they were introduced to
the Work Backlog at this point, and were not inputs to the Work Backlog.
• The “to” Entity is Accountable for understanding and representing this Work Backlog to the
Organization, with particular attention on the down-stream Entities.
• I’m not showing the Tasks inside the Development Scrum Team, as they are simply a matter
of the Team’s Self-Organization.
Plan
As you can see, the BO/PL generates a Plan in this diagram. This symbol is used to indicate that a
Plan-like thing (Delivery Date, Project Plan, RoadMap, and so on) is being produced and updated
at this point – and that the entity it is attached to is Accountable for producing and maintaining it.
Scrum Team
At the bottom we see the Scrum Team, along with its Product and Sprint Backlog (the horizontal
lines on the left). For Teams other than Development Teams I will use this symbol to indicate the
Team’s Backlog because these Scrum Teams have a Backlog separate from the Work Backlog. For
example, as we’ll see, a Distribution Team’s job is to manipulate Backlogs, and its work is managed
by a separate Backlog.
Organization of this Section

Scaling often requires the existence of Teams that can be used more-or-less interchangeably, so the
first Pattern in this Section is the Generic Development Team Pattern. Once we have this Pattern,
there are three Scaling Patterns in this Section:
• Distribution Team – which is used when there are multiple Teams feeding from the same
Backlog, and
• Consolidation Team – which is used when multiple Backlogs are fuzed into one.
• Program Team – which is basically a combination of the first two Patterns, and is used when
multiple Backlogs are flowing to multiple Teams.
So, let’s get going…

Scaling Patterns 48
Pattern: Generic Development Teams

In order to use many of the Scaling Patterns effectively, you need to have Scrum Teams that can
share the work.
Problem
You have more work than one Development Scrum Team can do and still meet Schedule Goals.
Context
You have Multiple Development Scrum Teams in your Organization.
Solution
Have many (if not most) of your Development Scrum Teams be as Generic as possible, capable of
working in many different Domains. Specialize these Generic Teams with Subject Matter Experts
(SMEs) as required.
Discussion
Organizations often specialize most of their Development Teams – having them focus on a specific
Product, Functional Area, Customer, or Technology Area. The thinking is that this specialization
makes them more effective and efficient in their particular highly-focused Domain.
This may be true, but it comes at a cost.
The cost is a lack of flexibility, which often leads to de facto Rules determining which Work Items go
to what Teams. It often leads to Teams identifying themselves with the specific Product, Functional
Area, Customer, or Technology Area – they think of it as being “Our Stuff,” and it really might be
the only Stuff they’re good at.
This could be a problem when too many Teams are in this situation, as the Organization could be
too inflexible to adapt to certain realities it encounters. We want People to make the Hard Decisions,
and not Rules, but we also need tnough flexibility in the Organization to be able to make those
Hard Decisions.
Here is a simple example. If a particular Project runs into problems and needs some additional
horse-power to get it across the line, where is it going to get it? There must be some Teams out
there that can pick up some of the excess work, but the Organization’s Teams may have specialized
themselves so much that this won’t work… the correct Decisions can’t actually be made.
So, try to have most (though probably not all) of your Development Scrum Teams capable of
adapting to different things that might come up. It would be nice if all of them were completely
adaptable, but that’s probably not really necessary.
Scaling Patterns 49
Pattern: Distribution Team

This is the simplest Scaling Pattern, often used when there are multiple Scrum Teams working on
the same Product.
Problem:
You want to split a single Backlog into multiple sub-Backlogs.
Context:
This is a generic Pattern, and is applicable in many Contexts, including (but not limited to):
• There is a Value Backlog representing a Project that is going to be worked on by multiple

Development Scrum Teams, who each need their own Work Backlog.
• There is a Value Backlog being split into two Value Backlogs to be fed to two different
Entities; an example is splitting a big Value Backlog into two little Value Backlogs for
different Organizations to work on.
• We could have a Development Team split into two smaller Teams, and thus need to split its
Work Backlog into two different sub-Work-Backlogs.
Solution:
Assume that the “Parent” Backlog (Backlog-A) is represented by Owner-A, and that the “Child”
Backlogs (Backlog-1 through Backlog-n) will be represented by Owner-1 through Owner-n. Then,
assemble a Scrum Team, called the Distribution Team, with the following properties:
• Owner-A is the Distribution Team’s Product Owner,

• Owner-1 through Owner-n are members of the Distribution Team (they are probably Virtual
members)
• The primary purpose of the Distribution Team is to decide which Items from Backlog-A will
go to each of Backlog-1 through Backlog-2.
• (for each i) Owner-i is Accountable for representing and explaining Backlog-i’s Items to the
Organization.
• (for each i) If Backlog-i is a Work Backlog, then the Distribution Team will help Owner-A
and Owner-i Refine and Order the Work Backlog, and add any necessary Chores.
– Owner-i is Accountable for the Refinement and for adding the Chores.
– Owner-A is Accountable for explaining the Itemss from Backlog-A that are being
Ordered and Refined.
– The Distribution Team is merely helping…
Scaling Patterns 50
• If Owner-A is also a Project Leader, the Distribution Team will help Owner-A update his or
her Plan every Sprint.
• If Owner-i is also a Project Leader, being on the Distribution Team will provide useful
information for updating his or her Plan every Sprint.
• The Distribution Team has its own Backlog that describes how it will carry out these
Responsibilities.
Distribution Team

This Pattern is fairly straightforward, but here are some comments:
• Since this is a Scrum Team, there shouldn’t be more than 5 (or so) outgoing Backlogs;
otherwise the Distribution Team could get too large to be an effective Scrum Team. In other
words, this Distribution Team may have its own Scaling issues.
• Luckily, these Distribution Teams can be layered, allowing a Backlog to be split many
different times, solving the Scaling problem mentioned above.
• Since this is a Scrum Team, and thus a Well-Formed Team, the Distribution Team may need
additional Subject Matter Experts to help with the splitting of the Backlog. These SMEs could
be Architects, Business Analysts, experts in the Business Domain – whatever is needed.
• Since the Distribution Team is a Well-Formed Team, it must do its due diligence in its work,
making sure its results meet appropriate Standards of Care
– In particular, this means that this Team needs to be able to Develop and Maintain
any relevant Project Plans, and that any Project Leadership must be good Project
Leadership – there must be no coercive or predictive behavior.
Scaling Patterns 51
– I summarize this concept by saying the we must “value Predictability, not Predictions…”
• These Distribution Teams often turn into Management Teams because this splitting is an
implied hierarchy (see the Management Team Pattern).
This is a simple, but powerful, Pattern. It’s primary strength is that it brings the right People together
to Split the “parent” Backlog.
Scaling Patterns 52
Pattern: Consolidation Team

This is the second Scaling problem – the problem of combining two Backlogs into a single Backlog
Problem:
We want to consolidate multiple Backlogs into a single Backlog
Context:
This is a generic Pattern, and is applicable in many Contexts, including (but not limited to):
• Multiple Value Backlogs feeding directly into a single Development Team (A Team working
on multiple Projects, for example).
• Multiple Value Backlogs being collapsed into a single Value Backlog so that it can be
managed as a single entity.
Solution:
There are multiple cases here; however, the idea is the same in all cases. There will be a
Consolidation Team made up all the Owners of the Input and Output Backlogs, along with any
Subject Matter Experts that are needed, and this Consolidation Team will create the single Output
Backlog by appropriate combining, refining, and adding to the combined Input Backlogs.
Not only that, but this Consolidation Team is also Responsible for helping the appropriate Project
Leaders Develop and Maintain their Project Plans.

Unlike the Distribution Team Pattern, the kinds of Backlogs do matter. the Input Backlogs will
always just be passed through, but whether the Output Backlog is a Work Backlog or a Value
Backlog makes a difference, as a Work Backlog gets Refined and has Chores added to it.
Let’s look at the first, and very common, case. In this case there are multiple Projects (or Backlogs)
feeding directly into the same Development Scrum Team. The following picture shows a picture
for this case…
Scaling Patterns 53
Multiple Projects for Single Team
In this case, we must realize that the Team Leader is playing both the Product Owner and Business
Owner roles in Modern Scrum – we see this in the middle of the diagram. The next step is to
assemble the Consolidation Team, made up of the Team Leader (in Business Owner role) as the
Team’s Product Owner, along with the Project Leaders and any necessary SMEs in order to:
• Prioritize the Value Backlogs together in order to have a single prioritized list,
• Refine this List, as appropriate, to become the basis for a Work Backlog,
• Add appropriate Chores to this Work Backlog, and
• Help the Project Leaders develop and update their Project Plans, if applicable.
Another case is when we have multiple Backlogs flowing into a single Work Backlog via a Business
Owner. This is basically the same case, with the same responsibilities as listed above, but the
Business Owner plays the Product Owner role on the Consolidation Team, and the Team Leader
is a (virtual) member of the Consolidation Team. We see this Pattern in the following diagram.
Scaling Patterns 54
Multiple Projects Flowing Through a Business Owner
Finally, we have the third case, where multiple Value Backlogs come together to be a single Value
Backlog, as we see in the following diagram.
Consolidation Team
In this diagram I combine two cases in one.
1. The first case starts on the left, and is where there is a single Business Owner/Project Leader
representing all the Backlogs. Assuming that prioritizing across all of these Backlogs is a Hard
problem, there should be Business Owners representing each of the Backlogs (as we see in
Scaling Patterns 55
the middle of the diagram), and this then turns into the Consolidation Team we see on the
right, which has:
• The original Business Owner as the Product Owner of the Consolidation Team,
• The new Business Owners as Team Members, along with any required Subject Matter
Experts, and
• The original Business Owner as the representative of the resulting Value Backlog.
2. The second case is where all the required Business Owners exist, as in the middle of the
diagram. the result is the same, as we see on the right.
Summary of Cases
The main thing to realize, in all of these cases, is that the individual playing the Business Owner
of the Output Backlog is Accountable for the analysis and work that went into the development of
the Output Backlog. In particular, this Business Owner must be able to explain why the priorities
are what they are, as well as provide Subject Matter Experts to anybody who need more details.
And, of course, since the Consolidation Team is a Scrum Team and thus a Well-Formed Team,
must do its due diligence and meet an appropriate Standard of Care in all this work. In other words,
the Project Plans must be Developed and Maintained appropriately, and the Business Owner
(Product Owner of the Consolidation Team) is Accountable for the Prioritization Decisions that
affecting these Project Plans.
A Naive Argument about Projects
Why would you want to prioritize across Projects, you ask? Shouldn’t you just do one Project at a
time? Isn’t that the most effective thing to do? There is a common argument¹² that goes like this:
Assume your Team tries to work on 3 Projects at once. Then their progress could look something
like this, where all 3 Projects finish at the same time, after 20 weeks.
Unfocused Team
If, instead, your Team works on a single Project at a time, the worst case is that they will all be
finished in 20 weeks, but two of them will finish early, which increases potential benefits.
¹²Taken from: http://www.infoq.com/articles/multitasking-problems
Scaling Patterns 56
Focused Team, Worst Case
And, in fact, since there are costs having to do with context switching, it is very likely that they will
actually finish early, as we see here. What a savings, what a deal!
Focused Team, Expected Case
This is a good, logical argument, but it is naive. Why do I say that?

Because Project Leaders probably won’t stand for it. Assume you are the Project Leader for “Project
2” (abbreviated as PL-2) in the diagrams above. Then what do you know?
1. You know that PL-1’s Project Plan is pure garbage; that “Project 1” will never finish on time.
Why do you know that? Because you know that your Project Plan for “Project 2” is pure
garbage…
2. You know that “Project 2” is much more important than “Project 1”, so, if any Project was to
go first, it should be “Project 2”…
3. You know that if “Project 1” gets to go first (and thus is most important), it will never finish
– its Scope will expand to fill the universe. Where is PL-1’s incentive to finish? If PL-1 gets
that Team, he’ll never let it go…
So, PL-2 will fight this tooth and nail, and the result is that all the Projects will fight to share
the Team. Therefore, they Project Leaders won’t allow this (perfectly logical) approach to actually
happen.
Now, you can buy my argument or not. You can decide that doing one Project at a time is a good
idea or not. I really don’t care. But, we must agree that this is a Hard Problem. The Projects have
to share the Team somehow, and Deciding how the Projects share the Team is a Hard Decision
that needs to be made. That’s why we have a Consolidation Team do it – and that’s why all the
involved Project Leaders are on this Team to fight for their own Projects.
Scaling Patterns 57
Pattern: Program Team

Here’s a combination of the last two Patterns – both combining and splitting multiple Backlogs.
Problem:
We want to take multiple Backlogs and convert them into a different set of Backlogs. In other
words, we want to Combine them, and then Distribute the combination.
Context:
The most common version of this problem is to have multiple Projects that are being worked on
my multiple Teams. However, it can be used in other situations, as well.
Solution:
Let’s just keep this short and sweet. This is basically the combination of the previous two Patterns,
as we see in this diagram.
Program Team

There’s not too much to say here. Most of the comments are just duplicates of what you find in the
Distribution Team and Consolidation Team Patterns. However, this is one caveat to mention.
Scaling Patterns 58
The size of the Program Team can get large if there are many Input Backlogs and/or many Output
Backlogs. Therefore, try to keep the total low. If need be, divide it into separate Consolidation and
Distribution Teams, as see in the middle of the diagram.
Whatever you do, don’t try to replace the Program Team with a set of Rules – this is always wrong
– the Decisions a Program Team has to make are *always** Hard Decisions, and require a Scrum
Team to make them. The PO of the Program Team*8 (called the **Program Manager in standard
PM-speak) is absolutely necessary to be Accountable for these Decisions.
One simple example…
Say we have three Value Backlogs and three Development Scrum Teams, so we set up a Rule to
simply map Backlogs to Teams. Easy as pie, and done all the time.
What happens if Team-One/Project-One gets in trouble? Who can decide to offload some of its
Items onto the other two Teams in order to balance the load? Nobody. There’s a Rule, and the
Organization will typically just suffer with that Rule rather than make a Decision to fix things…
just sayin’…
Anyway, the Program Team is a very powerful Pattern.
Patterns for ‘Big’ Organizations
Scaling Patterns are very important, as they show us how an Organization can get big successfully.
Once an Organization is big, there are other Patterns that arise just from the ‘bigness’. When I think
of Big Organizations, I think of something like this:
A Typical ‘Big’ Organization
These are the Patterns I will explore in this Section. I will introduce the following Patterns:
• Management Team,
• Cross-Cutting Workgroup,
• Community of Practice (CoP), and
• Integration and Evaluation (I&E) Team
I hope you like them…

Patterns for ‘Big’ Organizations 60
Pattern: Management Team

When Organizations get large, their ‘bigness’ leads to actual (or implied) hierarchies, which can be
used to provide Management Teams
Problem:
Many Organizations rely on ‘Heroic’ Management, which I define has having single Individuals
make Hard Decisions and solve Hard Problems without a lot of support. This often leads to either
poor or no Decision-Making and Problem-Solving, which is not a good thing for the Organization.
Context:
You are in a Big Organization with an actual or implied Management Hierarchy.
Solution:
Create Management Scrum Team (MST)s ‘in between’ the Nodes of the Hierarchy, as in the
diagram below. This diagram shows 10 Management Teams, at all levels of the Hierarchy.
Each of these Management Scrum Team (MST)s has the following properties:
• The MST’s Team Members consist of the Senior Manager (the Manager in the ‘upper box’),
each of the Junior Managers (the Managers in the ‘lower boxes’), and any appropriate
members of the Senior Manager’s Organization that are needed to act as Subject Matter
Experts in order to make the Team Cross-Functional.
• This Management Team is responsible for helping the Senior Manager (the MST’s Product
Owner) make Decisions about the Hard Issues and Problems in the Senior Manager’s
Organization.
Management Teams

First of all, since Management Teams are Scrum Teams, they must be Self-Organized, Self-
Contained, and Value Driven. This means that they must be willing and able to make the Hard
Decisions that are necessary for their Organization, no matter how low (or high) they are in the
Hierarchy.
Daily Scrums
Each Management Team has a Daily Scrum when it discusses the Issues of the Day specific
to its part of the Hierarchy. Each of the Junior Managers shares what his or her Organization
did yesterday, what it planning to do today, and what Impediments and Issues it is facing.
Additionally, each member of the Management Team discusses what he or she has done towards
the Management Team’s Backlog. The Management Team then has a discussion, focusing on the
Impediments, Cross-Cutting Issues, and guidance for what to do today. The Daily Scrum should
result in Communication and Cooperation across Teams, as well as Decisions about dealing with
the Impediments.
• Because of the Hierarchy’s layers, the Management Teams may have a series of Daily
Scrums, so that each Manager can go from his or hers MST’s meeting (where he or she is
the PO/TL) to the next one of where he or she is a Team Member. This will allow Issues and
Problems to be escalated up the Hierarchy, and solved along the way, if possible. For example:
– Each of the “Dev Teams” could have their Daily Scrums at 9am,
– MSTs 6,7,8,9, and 10, could have their Daily Scrums at 9:30am,
– MSTs 3,4, and 5 could have their Daily Scrums at 10:00am,
– MST number 2 could have its Daily Scrum at 10:30am, and
– MST number 1 could have its Daily Scrum at 11am.
Note that this is different (in fact, completely upside-down), from what often happens, where
the higher-level Management Teams meet earlier in order to pass-down orders and guidance
to the Organization. This difference lies in the change from Command and Control thinking
to Agile thinking, where the Management Team’s job is to solve problems rather than issue
edicts.
In the structure I’m describing here, each Daily Scrum results in Issues being brought up, and
Decisions being made. These Decisions are then taken by the Junior Managers back down to
their Organizations to be implemented immediately.
Reality comes up the Hierarchy and Decisions flow down the Hierarchy on a Daily Basis.
• Each of the Managers (PO/TLs) must make Decisions about the Issues and Problems that come
up during his Daily Scrum (the one where he or she is the PO/TL). If the Issue is restricted
to his or her Organization, then the Manager has an obligation to solve the Issue before
bringing it to his or her Manager’s Daily Scrum. This solution may be to put the Issue on the
Backlog for later, it may be to defer the Issue to his or her Team to be solved through Self-
Organization (although the Manager will still be Accountable for the solution), it may be a
temporary work-around, or it may be a permanent solution, but a Decision about a solution
must be made.
• Because of the above, when a Junior Manager is discussing his Organization’s Impediments
and Issues at the Daily Scrum, he or she will be discussing the Decisions he or she just made
(in a Daily Scrum a few minutes ago) about them. This allows discussions about the Decisions,
and helps the Junior Managers become better Decision-Makers through these discussions. If
the Senior Manager disagrees with the Decision, it can be corrected quickly; if the Decision
was a good one, it is reinforced immediately.
The Management Team’s Backlog
If appropriate, this Management Scrum Team may also function as a Distribution Team, Con-
solidation Team, or Program Team. This means that the Management Team is Responsible for
managing Backlogs and Plans – there must be Backlog Items for these things…
The Management Team may also have other things it is working on; HR Issues (Hiring, Training,
etc.), setting up new Teams and Projects, Management Initiatives, and so on.
The Junior Managers on the Management Team should expect to spend some time working on
these Items. If the Junior Manager is also the Business Owner of some Backlog or other, he or
she must expect to spend some time with the Backlog’s Stakeholders. If the Junior Manager is a
Development Team’s Team Leader, he or she must spend a lot of time with his or her Team. In any
case, we can see that all of these Managers will be splitting their time among a number of different
groups:
• They are the Team Leader for some Team or other, which could be either a Development
Team or a Management Team;
• They are a Member of a Managment Team (not the Team Leader);
• They may be a Business Owner, and thus represent (and work with) a group of Stakeholders.
There is a lot of Coordination, Communication, and Decision-Making for these people to do. Try
not to overload them with other work.
Summary
The most important thing about the Management Team is that the Senior Manager has the
right people bringing (and helping to solve) the Hard Issues and Problems the Senior Manager
is Accountable for. This makes the Accountability clear, and it offers the best chance of making
good Decisions and getting buy-in for these Decisions.
Pattern: Cross-Cutting Workgroup

In ‘Big’ Organizations there are lots of smart people spread out all over the place. Sometimes these
people need to get together to solve Hard Problems.
Problem:
You have a Hard Problem to deal with, and the people you need (or want) to work on these problems
are spread out across the Organization. The reasons for this are probably one (or both) of the
following:
• The People with the Skills to solve the Problem are spread out across the Organization, or
• The Problem is of interest to People that are spread out across the Organization.
Context:
You have a ‘Big’ Organization, with large numbers of Teams, Projects, and People.
Solution:
Establish a Scrum Team, whose Team Members come from across the Organization, with the
following properties:
• The Team has the Charter to solve the Hard Problem (or category of Hard Problems),
• The Team has all the skills and knowledge necessary to solve the Problems,
• The Team’s Backlog is made up of the Hard Problems the Organization needs to have solved;
the Team is not an “Ivory Tower” Team solving Problems they want to solve,
• There may be a few Team Members who are full-timers that form the nucleus of the
Workgroup, but most (if not all) of the Workgroup’s Team Members should have real jobs
throughout the Organization – this is considered a part-time thing for most of them, and we
want them grounded in the Realities of current Development,
• The Team works with the originator(s) of the Hard Problem(s) to determine the Acceptance
Criteria for the Solution (what constitutes a solution, necessary time-frame for the solution,
and so on), and
• The Team’s is Accountable to the Organization to provide the solutions.
In other words, this Team is a real Scrum Team solving real Problems…
The following diagram shows some sample Workgroups, which I will discuss in the Discussion
Section…

First, let me give a real-life example, outside the software Domain. Think about an Army Base…
there are often many different tenant units on this Base, with no command structure connecting
them – they just happen to reside on the same Base. The Base, itself, has its own Unit that controls
the grounds, the PX, the Commissary, and so on. On the 4th of July it is traditional for all Army
Units to have a family picnic. There are a finite number of ball-fields and picnic areas on the base,
and some of them are more coveted than others.
Question: How do we determine who gets the ball-fields and picnic areas for the 4th of July picnics?
Answer: Bring together a Workgroup made up of one person from each Unit, with the person from
the Base’s Command Unit being the Product Owner. It is common for this Product Owner to
not be the most senior Team Member – this Workgroup is not managed with a typical command
structure. The purpose of this Workgroup is to determine how to apportion the ball-fields, picnic
areas, parking areas, and so on, to the tenant units. It also needs to arrange for Medical, Police,
Cleanup and PortaPotty support – there are many things to be considered. This is a Hard Problem
with lots of people and issues involved, including:
• The size of the Unit,

• The personality of the Unit (some units will focus on sports, others will focus on conversation,
some will focus on drinking… just sayin…),
• Who just got back from being deployed to a Combat Zone (you expect a higher number of
family members to come, medal ceremonies, more speechifying, …),
• How will we handle traffic control, injuries, cooking and fires, drinking, lost children, cleanup,
cars that won’t start, and a myriad of other issues,
• and so on…
This is a Hard Problem, and the Army has discovered the “use Scrum Teams to solve Hard Problems”
Pattern to solve it. It puts the right people together and gives them both the Mission of – and
Permission to – solve the Problem.
Now, let’s look at the Workgroups we see in the diagram, as they provide a good sampling of
Workgroups in a Software Development Organization.
Usability Workgroup: The purpose of the Usability Workgroup is to provide Usability advice,
training, standards, SMEs, and so on, to the Organization. It consists UX Experts, an Architect, a
DBA, and whatever other Experts it needs to do this work. Each of the Team Members has a real job
on some Development Scrum Team somewhere, but there may be a lead UX person, who works at
the Organization level, and acts as the PO. Each of these Team Members helps determine which
problems need to be worked on in order to provide value to the Organization.
Architecture Workgroup: This is very similar to the Usability Workgroup, except that probably
consists only of Architects, and maybe a Chief Architect at the Organization level. The main pur-
pose of the Architecture Workgroup is to provide nearly-instantaneous advice to the Development
Scrum Teams as they need it. This advice would be provided by the Architecture Workgroup’s
Team Members (in their capacity as Architects on Dev Teams), and after giving the advice the
could double-check it with the Architecture Workgroup. Since this Workgroup consists solely of
Architects, it can be seen as a Community of Practice (CoP) or a subset of a CoP. This is not an
Ivory Tower group of Architects developing Frameworks!
SME Management Workgroup: One of the major problems facing a large Organization is the
sharing of Subject Matter Experts (SMEs) across the Teams. One Pattern I like to use is the Buddy
Up Pattern, where each of the Teams that needs the SME assigns a Team Member to work as the
SME’s Buddy; this Buddy is Accountable to the Team for the SME’s support – either the Buddy
gets the SME to help, or the Buddy must do it himself. Then, aggregate all the Buddies onto a
Scrum Team (with the SME as Product Owner) that will determine how the SME supports the
various Teams. The SME Management Workgroup puts the people with skin in the game (the
Buddies), along with the SME in a group to work it out – true self-organization in action.
As you can see, the Cross-Cutting Workgroup Pattern is a good way to “tie together” the
Organization to solve Hard Cross-Cutting Problems. This Pattern is often combined with the
Communities of Practice (CoPs) Pattern, since they both involve Cross-Cutting groups, but there
are differences:
• Cross-Cutting Workgroups don’t have to contain people of the “same type”, while a
Community of Practice does, and
• Cross-Cutting Workgroups are about solving Hard Problems, while Communities of
Practice are (primarily) about Knowledge Transfer.
In any case, I’ll describe the Community of Practice Pattern next.

Pattern: Community of Practice

In a large Organization there are lots of different types of People that need to keep current in their
technical disciplines. One way to handle this problem is with Communities of Practice (CoP).
Problem:
In a large Organization there are lots of different types of People: Coders, Architects, Analysts,
Testers, Technical Writers, Project Leaders, and so on. These People are spread all over the place
working in Teams and on Projects. How do we keep these people current in their disciplines,
consistent in their practices, and so on?
Context:
You have a ‘Big’ Organization, with large numbers of Teams, Projects, and People.
Solution:
Have your People organize themselves into Communities based on technical areas of expertise.
Let the People in these Communities “hang out” together, separate from their Development and
Project work, so that they can share expertise and learn from each other.
This Pattern has many flavors: the Communities can be formal or informal, organized or
disorganized, and they may meet frequently or infrequently. What makes this a Pattern is that
the Organization allows the Communities to exist, which takes time away from the Project and
Development work the People are “being paid to do.”

Possibly the most ambitious, most extensive, and most expensive way to do this is the way the US
Army does it, which actually has three layers. The first, and more expensive, layer is formal training
at military schools. A soldier will spend between a third and a half of his or her career in training,
learning new techniques, new doctrine, and spending time with his or her peers. The second layer
is formal training within their units, which is offered by trainers affiliated with the appropriate
military schools. The third layer is informal training within their units that is facilitated by more
senior soldiers. And, of course, all soldiers are expected to work with each other and mentor all their
subordinates. The Army takes its Training, and its Communities of Practice, very seriously.
At the other end of the spectrum we have Organizations that sponsor “Brown Bag Lunches” for their
Communities of Practice. These “Brown Bags” are sometimes used for Book Discussion Groups,
or guest speakers, or whatever else makes sense.
I can imagine, in a large Organization, having a day or two between Sprints that could be used for
updating Plans, refining Value Backlogs, and having Communities of Practice work together. I can
imagine having small, internal, Open Space conferences, delivering technical papers and experience
reports, Code-a-thons to help improve coding techniques, and so on.
Somewhere in all of this is what you’ll do… you’ll have to figure it out yourself.
Some Organizations use these Communities of Practice to solve Problems, much the way you
would use Cross-Cutting Workgroups, and this seems a very reasonable combination of the two
Patterns. Just remember that the Patterns are actually different: the Cross-cutting Workgroups are
about solving Problems and could involve cross-functional Teams, while a Community of Practice
is about sharing knowledge and increasing learning within a group of people with the same basic
skill-set.
In any case, the Community of Practice is a very powerful Pattern that is very useful in a large
Organization.
Pattern: Integration and Evaluation (I&E) Team

Large Organizations may have Products that are the results of Integrating many Teams’ work.
Problem:
Integrated Products need to be Evaluated in many different ways, and these ways are not always
available to each of the Development Teams that are developing the Product.
Context:
The Organization has many Development Scrum Teams working on the same Product.
Solution:
Established an Integration and Evaluation (I&E) Team, which is a Scrum Team that does three
things:
1. It creates (or receives) an Integrated Product developed by multiple Development Scrum

Teams,
2. It Evaluates this Integrated Product using External Reviews and specialized Testing, and
3. It produces a Value Backlog of Items based on this Evaluation.
Integration and Evaluation (I&E) Team

This diagram shows a fairly large Product Developement Organization (a hierarchical Well-
Formed Team) with a Product Management Team managing a single primary Value Backlog.
The Integration and Evaluation (I&E) Team is a part of this Organization and its Team Leader
is a (virtual) member of the Product Management Team. The diagram shows that the I&E Team
produces its own Value Backlog, consisting of Defects, new Features, Change Requests, and so
on (resulting from the Evaluations), that is fed back into the Project Management Team for
Consolidation into the overall Value and Work Backlogs.

Basically, this is nothing more than a dedicated Test Team that also conducts external Reviews, but
there are some things to note:
• This Team is doing Validations, not Verifications. Every piece being Integrated meets its
Definition of Done; everything “meets spec”. This Team’s job is to do additional Validations
the Development Teams are either incapable of doing, or are not Responsible for doing.
These could include:
– Product Reviews with Stakeholders of the Integrated Product. Since they are Scrum
Teams, the individual Development Teams will also do Product Reviews of ‘their piece’
of the Product with appropriate Stakeholders.
– Specialized Testing, such as Usability Testing, Performance Testing, Exploratory Testing,
Acceptance Testing, and so on. This testing often requires specialized tools and/or
environments not available to the Development Teams.
• The I&E Team is often a permanent, dedicated Team. However, it could also be a Cross-
Cutting Workgroup made up of part-timers.
• The I&E TeaM Evaluates an Integrated Product. Sometimes the I&E Team is Accountable
for the Integration, but it is a better idea for each Development Team to be Accountable for
successful Integration of its piece – as part of its Definition of Done.
As you can see, this is a very useful Pattern for large Organizations with many Development
Teams.
Evaluating Frameworks
Now that we’ve got a bunch of Patterns and Principles to use, let’s see what they tell us. In
particular, I’d like to look at a couple of Agile Scaling Frameworks:
• Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde, and
• The Scaled Agile Framework (SAFe), by Dean Leffingwell et al.
What I will do is look at these Frameworks from the perspective of the Patterns and Principles I
have introduced, and analyze which of the Patterns are encapsulated in the Frameworks. Basically,
what I’m going to do is show how the Patterns can be used to replicate the Frameworks.
I hope you enjoy it.
Evaluating Frameworks 72
Analysis of the LeSS Framework

Craig Larmen and Bas Vodde have written a couple of books on Large Scale Scrum (LeSS):
• Scaling Lean & Agile Development, 2009, and

• Practices for Scaling Lean & Agile Development, 2010.
They also published a nice article entitled “Scaling Agile Development” summarizing their version
of Scaling in Crosstalk Online (May/June 2013)¹³. Their main purpose is was to extend the essence
of Scrum to large Organizations without becoming so prescriptive that the Scrum goes away.
This is a worthy goal, and I applaud their efforts. Unfortunately, from my perspective, the Scrum
they are extending is Original Scrum, so they are missing out on many of the improvements of
Modern Scrum. I’m looking forward to seeing what happens if (and when) they update things…
In any case, they give two simple frameworks showing how to expand Scrum beyond a single Team.
The first one is named LeSS-1, which is equivalent to a straightforward application of a single
Distribution Team – at least when you look at it from a Modern Scrum perspective.
LeSS-1 as Patterns
Basically, LeSS-1 is described as a big Scrum Team: it has a single Product Owner, a single Backlog,
and a single Product. It contains multiple sub-Teams (the Scrum Team minus the PO) that integrate
into a common CodeBase, and there is a single, joint Product Review. It’s quite nice, actually, and
I have very few issues with it, and they are the standard issues I have with Original Scrum:
¹³http://www.crosstalkonline.org/storage/issue-archives/2013/201305/201305-Larman.pdf
• The Product Owner is seen as a Product Expert rather than an Accountable Decision-maker,
and
• No Accountability at the sub-Team level for Improvements and Chores.
On the plus side, Craig and Bas note the need for Cross-Cutting Workgroups to solve issues that
cut across the internal Scrum Teams.
I think that LeSS-1 shows that there are different ways to Scale to this size: both the Distribution
Team I introduce and this large-scale self-organization that Craig and Bas introduce both do the job.
That being said, I think that the introduction of the Distribution Team on top of Modern Scrum is
a better solution, because it generalizes. I believe that their Scaling up to the next level doesn’t work
so well.
In order to Scale up to the next level Craig and Bas introduce LeSS-2, which is equivalent to a
layering of the Distribution Pattern, as shown in the following diagram.
LeSS-2 as Patterns
I’ll keep my objections short and sweet. In order to Scale LeSS-1 to LeSS-2, Craig and Bas introduce
Area Product Owners and a Rule that decides which Items on the Product Backlog flow to
the various Area Backlogs. I object to this, because “Rules don’t make Decisions, People do.” as
I mentioned a few chapters ago.
In other words, the large-scale Self-Organization that Craig and Bas espouse only Scales so far. I
love Self-Organization inside a single Scrum Team, which is why I like Hard Decisions to be made
by Scrum Teams such as the Distribution Team… just sayin’… :)

Analysis of the Scaled Agile Framework (SAFe)

Dean Leffingwell’s Scaled Agile Framework (SAFe) is a very ambitious Framework with a lot of
pieces. Among other things, it has the prettiest picture, as you see here:
The Scaled Agile Framework (SAFe)
I have drawn two “boxes” on this diagram, to show the two major pieces of the Framework:
• The “top” box is where the Backlog Development takes place, and
• The “bottom” box shows the Agile Release Train, which is where the actual Development
takes place.
The Backlog Development part of the Big Picture is about:
1. Creating a Portfolio Backlog whose Items are called Epics (either Business or Architec-
tural). These Items are very large, and their implementation will usually span multiple
Release Trains and Releases, and affect multiple Organizations. Each of these Epics
has an Epic Owner who is Accountable for developing the Epic’s Business Case and,
when approved, working directly with the appropriate Agile Release Trains to help get it
Developed.
2. Decomposing and Distributing these Portfolio Backlog Items to the individual ART’s
Program Backlogs, along with a Vision and Roadmap to help each ART with its Release
Planning.
Once the Agile Release Train has its Program Backlog, then its job is to Release Product:
1. It conducts a two-day Release Planning meeting every 8-12 weeks, which results in a
Release Plan, Release Objectives, and buy-in from everybody in the Release Train to these
Objectives. Note: the point of a Release is not necessarily to actually Release something,
but to produce a Potentially Releasable Increment (PSI) of Product. Basically, SAFe
acknowledges that Releasing something is a Decision (at can be done at any time the
Business thinks the Product is Releasable), but being Potentially Releasable is a State (the
Product meets both its Functional and Quality Goals – and that the Goal of a Release is
actually to reach the State of being Potentially Releasable.
2. The ART proceeds to work in 2-week Iterations, doing basic layered Scrum, inspecting and
adapting, progressing towards the Release.
3. Finally, the ART and the Business Review the Increment, and decide what to do next.
The following diagram shows what this Big Picture looks like in Patterns
SAFe as Patterns
The Agile Release Train

Let’s start with the Agile Release Train (ART). This is basically a large Well-Formed Development
Team whose input is the Program Backlog. There are two additional Teams inside the ART beyond
simply Development Teams:
• There is an added I&E Team called the System Team, which Integrates Product from Scrum
Development Teams, performing end-to-end System Testing, and demonstrating solutions
to Stakeholders at each iteration; and
• There is a Release Management Team, whose primary responsibility is to coordinate and
facilitate the delivery of the whole product solution, developed by the ART.
The Program Portfolio Management Team

The Program Portfolio Management Team is the highest-level fiduciary and content authority in
SAFe. It is both a Program Team and a Management Team, but it is not as well-defined as it could
be. Its responsibilities are relatively well-defined:
• Decide which Epics make it onto the Portfolio Backlog, and determine their Priority,
• Produce and Maintain the Portfolio Vision and Investment Themes,
• Decompose the Portfolio Backlog into Program Backlogs for the Agile Release Trains, and
• Work with the ART’s to Develop and Maintain the Roadmap, Vision, and Release Plans.
SAFe knows, and accepts, that the Program Portfolio Management Team is not well-defined. As
they put it: “Enterprises may use different titles and roles to fulfill these functions…” They do give
some guidance, though, which I have included on the diagram; the PPM Team may include:
• The Program/Project Management Office (PMO), which knows how to move large pro-
grams from development to deployment while providing status and financial reporting,
• Business analysts, for elaborating Epics, and
• Enterprise and System Architects, for defining technological visions and implementation
scenarios that support the business strategy.
In any case, the PPM Team will need a Product Owner to be Accountable for the Vision, Portfolio,
and so on; and this Product Owner will probably need to be an Executive that has the power and
influence to sponsor the effort.
Discussion and Comments

There are some very good ideas embodied in SAFe, and the diagram above captures many of them
as Patterns. However, there is a lot of documentation about SAFe, and some of it raises issues with
me… here are some of the issues I see, given in no particular order:
1. One general issue is that SAFe focuses on Artifacts and Practices, and there is little discussion
of Product Ownership. Since the Accountability inherent in Product Ownership is one of
the major contributions of Scrum, and one of the major foci of the Patterns, I had to make
assumptions about who actually makes the necessary Decisions and is Accountable for them.
2. The Product Manager is the Product Owner of the ART (the Product Manager prioritizes
the Program Backlog), but the Release Management Team is the governing authority for the
Release. I have been told that the Release Train Engineer (RTE) usually acts as the Product
Owner of the Release Management Team, but the RTE is the “uber-ScrumMaster” for the
ART. This is a tangled mess, in my opinion.
3. The Release is central to SAFe. There is Release Planning and a Release BurnDown, but no
Release Backlog. Huh?
4. “The Release Management Team (RMT) is responsible for managing and scheduling syn-
chronized releases (or PSI/Releases) across one or more Programs and/or Product Lines.”
It appears that any given Agile Release Train is about a single Program involving a single
Product (the ART’s Backlog is called a Program Backlog, and its Product Owner is its
single Product Manager). So, this implies some Portfolio-level management that I don’t
see described anywhere. And, I suspect, this management also involves the appropriate Epic
Owners. Just askin’…
5. Is it true that an Agile Release Train only involves one Product Manager? Is Product Man-
agement and Release Management actually part of an un-named Program Management
function that governs the ART? Just askin’…
6. There is a lot of discussion about the possible conflict between the Product Manager and the
Product Owners of the ART’s Development Teams. Maybe some discussion of the difference
between a role (Product Owner) and a position (Product Manager and Team Lead) is in
order?
7. The SAFe documentation says “The ScrumMaster role is well defined in Scrum and the
Scrum community provides specialty training that can be leveraged cost effectively…” This
is very true, but the ScrumMaster as described in the SAFe documentation is not the same
ScrumMaster that is defined in Scrum and is taught and certified by either Scrum.org or the
Scrum Alliance.
8. SAFe seems a little predictive and coercive. Here is the beginning of SAFe’s definition
of the ScrumMaster: “The Scrum/Agile Master is a dedicated team member who has a
primary responsibility to help the self-organizing, self-managing team meet its goals and
commitments…” Now, this wouldn’t be a problem if the “commitment” to be met was the
commitment to values and quality, but we also have the quotes “stories and acceptance criteria
committed to the sprint” and “commitment to PSI/Release objectives for the next PSI timebox”.
This leads me to believe that SAFe believes the ScrumMaster is there to enforce commitments,
not to be a real ScrumMaster. I’ll be generous and just assume that SAFe believes in the
Original, coercive and predictive, version of Scrum.
9. SAFe uses the Phrase “Developers & Testers” when referring to the members of a Scrum
Development Team. It would be better if it just used the word “Developers” and then defined
that terms to mean everybody you need to do your work, including Coders, Testers, Analysts,
Tech Writers, etc…
Anyway, that’s enough.

Book Versions
Here is the history of the major versions of this book.
V1: 2013-10-08
First release, the 10% release. Contains first cut of Patterns imbedded in Scrum itself.
New Improved Chapter Name
X Introduction
X Original Scrum
X –Pattern: Well-Formed Team
X –Pattern: Team Coach
X –Pattern: Business Owner
X –Pattern: Agile Product Development
X –Original Scrum Discussion
X Modern Scrum
X –Pattern: Team Leader
X –Pattern: Subject Matter Experts
X –Pattern: Definition of Done
X –Pattern: Forecast, don’t Commit (and others)
X –Modern Scrum Discussion
Book Versions 81
V2: 2013-11-07
Second major release, with first cut of Patterns for Scaling, updates of existing Chapters, improved
formatting, Evaluation of LeSS and SAFe, and addition of the Book Versions Chapter.

X Introduction
Original Scrum
–Pattern: Well-Formed Team
–Pattern: Team Coach
X –Pattern: Business Owner
X –Original Scrum Discussion
Modern Scrum
X –Pattern: Team Leader
X –Pattern: Subject Matter Experts
X –Pattern: Definition of Done
–Pattern: Forecast, don’t Commit (and others)
X What We Learn from Scrum - the Principles
X Scaling Patterns
X –Pattern: Generic Development Teams
X –Pattern: Distribution Team
X –Pattern: Consolidation Team
X –Pattern: Program Team
X Patterns for ‘Big’ Organizations
X –Pattern: Management Team
X –Pattern: Cross-Cutting WOrkgroup
X –Pattern: Community of Practice
X –Pattern: Integration and Evaluation (I&E) Team
X Evaluating Frameworks
X –Analysis of the LeSS Framework
X –Analysis of the Scaled Agile Framework (SAFe)
X Book Versions
Book Versions 82
V2.1 (minor improvements): 2013-12-29

Minor changes to Version 2; most significant changes being an emplasis on Accountabilities and
further explanation of what a Project Plan might look like.

X Introduction
Original Scrum
–Pattern: Well-Formed Team
X –Pattern: Team Coach
–Pattern: Business Owner
–Original Scrum Discussion
Modern Scrum
–Pattern: Team Leader
–Pattern: Subject Matter Experts
–Pattern: Definition of Done
–Pattern: Forecast, don’t Commit (and others)
What We Learn from Scrum - the Principles
Scaling Patterns
–Pattern: Generic Development Teams
–Pattern: Distribution Team
–Pattern: Consolidation Team
–Pattern: Program Team
Patterns for ‘Big’ Organizations
–Pattern: Management Team
–Pattern: Cross-Cutting WOrkgroup
–Pattern: Community of Practice
–Pattern: Integration and Evaluation (I&E) Team
Evaluating Frameworks
–Analysis of the LeSS Framework
–Analysis of the Scaled Agile Framework (SAFe)
X Book Versions

Patterns That Make Scrum Work

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

Patterns That Make Scrum Work

Uploaded by

Copyright:

Available Formats

Exploring Scrum: Patterns that Make Scrum

Dan Rawsthorne, PhD, PMP, CST

This version was published on 2013-12-29

©2013 Dan Rawsthorne, PhD, PMP, CST

What We Learn from Scrum - the Principles . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Patterns for ‘Big’ Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Patterns and AntiPatterns

• Pattern Name: a descriptive name…

• AntiPattern Name: a descriptive name…

Pattern: Well-Formed Team

The Well-Formed Team

Generally speaking, this Pattern specifies the following Accountabilities:

Discussion and Examples:

• A Well-Formed Team could be a 1-man Team, like my plumber Jerry.

• In other words, it is a recursive definition: a Team made up of Well-Formed Teams whose

As you can see, the Well-Formed Team is an powerful thing.

Pattern: Team Coach

Discussion and Examples:

Pattern: Business Owner

The Business Owner

Discussion, including examples:

A Restaurant’s Work Backlog

Pattern: Agile Product Development

Agile Product Development

Discussion and Examples:

Simple Business Owner - no Cost or Schedule Constraints

Business Owner as Project Leader

1. To Develop a Project Plan, and

• (Assumption) Baseline ReleaseSize = 1000 StoryPoints, and

• (Derived) Baseline Duration = 10 Sprints = 20 Weeks. And

• Contents of the Project Plan,

• in a Fixed-Price contract, the decision-maker is the Project Leader, as it is the Contractor

Original Scrum Discussion

2) There are a small number of Practices:

• There is a Sprint, which is which is the length of the Development Iteration.

The Product Owner is Complicated

Value Backlog and Work Backlog “don’t match”

Improvements and Chores

Product Owner as Project Leader

The ScrumMaster often becomes a Manager

Misunderstanding of the phrase “Potentially Shippable”

Development Teams write Bad Code

There are two reasons Development Teams write Bad Code:

• Trying to make dates causes the Team to take shortcuts,

Basic Scaling Issues

Pattern: Team Leader

The Team Leader

Discussion, including examples:

Pattern: Subject Matter Experts

• Technical Expertise the Team needs to complete its work,

Subject Matter Experts

Discussion, including examples:

Pattern: Definition of Done

Discussion, including examples:

Definition of Done Example

Pattern: Forecast, don’t Commit (and others)

Discussion, including examples:

Modern Scrum Discussion

Product Owner Re-Definition

Review of the Accountabilities in Modern Scrum

Problems with Modern Scrum

• when there’s more than one Team,

• The “from” Entity is Accountable for ordering/prioritizing, understanding and representing