Exploring Scrum: Patterns that Make ScrumWorkUnderstanding 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 Publishingprocess. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools andmany iterations to get reader feedback, pivot until you have the right book and build traction onceyou 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 thishashtag on Twitter:

https://twitter.com/search?q=#PPSAD

To Mel… you will be missed

Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Original Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Pattern: Well-Formed Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Pattern: Team Coach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Pattern: Business Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Pattern: Agile Product Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Original Scrum Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Modern Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Pattern: Team Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Pattern: Subject Matter Experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Pattern: Definition of Done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Pattern: Forecast, don’t Commit (and others) . . . . . . . . . . . . . . . . . . . . . . . . . 38Modern Scrum Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

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

Scaling Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Pattern: Generic Development Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Pattern: Distribution Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Pattern: Consolidation Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Pattern: Program Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Patterns for ‘Big’ Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Pattern: Management Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Pattern: Cross-Cutting Workgroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Pattern: Community of Practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Pattern: Integration and Evaluation (I&E) Team . . . . . . . . . . . . . . . . . . . . . . . . 69

Evaluating Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Analysis of the LeSS Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Analysis of the Scaled Agile Framework (SAFe) . . . . . . . . . . . . . . . . . . . . . . . . 75

Book Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

IntroductionScrum is the most common, and popular,Agile Development framework in the world. In this bookI 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 anOrganization.

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 areoften 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. Thesepeople are held Accountable for their decisions – they own their decisions – and I will referto them as Leaders or Owners.

Of course, Scrum is not that simple – this is not all of Scrum. There are Schedules and Costs tomanage, advice and guidance on what to build to give, and a simple Agile Process that surroundseverything.

But the important stuff is aboutTeams andDeciders.WhatTeams dowe need, andwhat do they do?What Deciders do we need, and who should they be? Who helps the Deciders get the informationthey 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, weshould be thinking about Decision-Makers; we need to have the right people in the right place atthe 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 betterexplain them to you. :)

At its simplest, a Pattern is defined as a “solution to a problem in a context” and each Pattern I givein 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 DesignPatterns are solutions to tactical problems or low-level strategic problems. For example, you mightfind many different Design Patterns describing different ways to run Daily Scrums, or you mightfind a Design Pattern telling you that you should have Daily Scrums. People often try to use theseDesign 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” thatform 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 Patternsdescribe 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 aparticular 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 likethey 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 towork. Patterns and AntiPatterns contain some guidance and advice that will help you frame yourquestions andmanage your thoughts in order to deal with your situation. Patterns andAntiPatternshelp you understandwhat is important about a situation, and allows you to focus and analyze, ratherthan 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 orthe 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 Ihope to realize, the cook is Accountable for the results, not merely following the recipe. Same withPatterns… 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 commonunderstanding of what it means.

Accountability is a very important concept in Scrum. Most people don’t really understand whatAccountability 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 whenwe’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 andassumption of responsibility for actions, products, decisions, and policies…” It is frequently describedas a relationship between individuals; Person-A is Accountable to Person-B for Thing-C whenPerson-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 usuallyhold people Accountable for something being done, or a decision being made. Let me discuss eachof these cases:

• Person-A is “Accountable for something being done” means that Person-A needs to makesure that the something gets done – Person-A doesn’t have to do it personally – and Person-Aneeds 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 thedecision is made, and that Person-A owns the decision. In other words, Person-A needs tobe 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 speakof Team, Group, or OrganizationalAccountability, but this is a difficult concept – and we’ll see thiscome up later.

Conventions

Most terms in bold will be defined in a glossary. Nouns (Product) are bold, Verbs (Review) arebold-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 thathave arisen: I will call them Original Scrum andModern 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 fewPatterns, and in the next chapter I will show how this morphs into Modern Scrum by applyinga few more. After that I will introduce Scaling Patterns and analyze some popular Agile ScalingFrameworks by comparing them to these Patterns.

With these definitions and explanations, we are now ready to explore Scrum.

Original ScrumI’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 thatthere is nothing special about these Patterns – they are not software-specific. What is interestingis that we are (only recently) bringing them to mainstream Software Development.

After the Patterns are described, I will assembly them into a Software Development ScrumTeam…

Original Scrum 6

Pattern: Well-Formed Team

The core of Scrum – its most basic idea – is theWell-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 theseStakeholders can’t (or don’t want to) do the work themselves.

• Each Item has Acceptance Criteria; the Stakeholders have an idea about what the finishedresult should look like, be, or do – and these Acceptance Criteria will be shared as part ofthe Item.

Solution:

Use aWell-Formed Team (WFT) to do the work, which means:

• the WFT is Self-Organized: the Team Members determine what Tasks are necessary forthem to accomplish the work and complete the Item. The Team Members are co-located (ifnot physically, then virtually) and have frequent Coordination Meetings to stay ‘synced-up’while they are working. TheWFT manages itself so that the Stakeholders don’t have to.

• the WFT is Self-Contained: the Team Members (collectively) have all the knowledge andskills they need in order to accomplish the work and complete the Item. The Stakeholderswill not have to worry about delays based on waiting for outsiders to complete their part ofthe work.

• the Team Members are Value-Driven: they value working together; they are constantlyworking on Improvements of themselves, their Team, their environment, and their tools; andthey 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 inworking on the Items. The Stakeholders can trust that the WFT has Integrity – the TeamMembers are Professionals – and will meet the Acceptance Criteria while meeting theappropriate 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 appropriateStandard of Care and satisfying the Item’s Acceptance Criteria,

• TheWell-Formed Team isAccountable to identify and carry out Improvements andChoresthat are required for theWFT’s successful continuation, and

• The Team Members are Accountable to each other to be good Team Members and live theValues.

Discussion and Examples:

We find Well-Formed Teams everywhere, in all walks of life, doing all sorts of work. The rangefrom the Team of gardeners that maintains your yard and garden, to the team of mechanics thatworks 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 particulardomain.Well-Formed Teams can come in many sizes:

• AWell-Formed Team could be a 1-man Team, like my plumber Jerry.• AWell-Formed Team could be a Small Team, like the collection of mechanics at a car repaircenter, the members of a brick-laying team, cooks and other workers in a (small) restaurantkitchen, or the truck-load of gardeners who come by to fix up your yard and garden.

• AWell-Formed Team could be Large, like a Construction Company, a Hospital, or the cooksand other workers in a (large) restaurant kitchen. However,

• The internal organization of this large Well-Formed Team must consist of Well-FormedTeams.

Original Scrum 8

• In other words, it is a recursive definition: a Team made up of Well-Formed Teams whosegovernance is also done by Well-Formed Teams is a Well-Formed Team. This will beexplored 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 cantake many different forms – here are just a few:

• TheWFT could use an adaptable assembly line – like in a kitchen or brick-laying team. Thework, itself, follows a certain flow – and it is adapted as necessary. There is often a memberof 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 seethis pattern of behavior on most WFTs, but it is very obvious with mechanics and medicalprofessionals.

• TheWFT’s TeamMembers always work in pairs, sharing expertise (and looking out for eachother) 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 coupleof 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 andEnvironment. This takes time (in the form of internally-generated Items or Tasks), and it is timethat will not be spent working on the Items coming from the Stakeholders; it is just part of the costof doing work.

The second reason is because of the notions of Standard of Care and Acceptance Criteria…

AWell-Formed Team must have a Standard of Care that it adheres to in its work. This Standardof Care is crucial and inviolate, because the Stakeholders are relying on it. The Stakeholders arerelying on the Professionalism and Integrity of the WFT; the Stakeholders want the work doneright, and they are trusting theWFT to know what that means – and to do it every time. We wouldlike Team Members to be Self-Motivated, and do the work to the Standard of Care without beingtold, 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 thata Done Item is one that meets the Acceptance Criteria and that the Team used the appropriateStandard of Care while doing the Item. To make it simple, we say that a Done Item met both theAcceptance Criteria and the Standard of Care.

On the one hand, the Acceptance Criteria come from the Stakeholders (as part of the Item), anddefines what the Stakeholders want, need, expect, or are hoping for. The Acceptance Criteriamaybe either ambiguous or well-defined; they may be documented or undocumented; the idea is thatthe 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 theside”

• “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 doChores, which (like Improvements) are internally-generated Items or Tasks that are not directlyinvolved with completing an Item. For example, painters must clean their brushes, mechanics mustclean their tools and dispose of old oil appropriately, workers in a kitchen must clean the dishes andequipment, and so on. In my book (Exploring Scrum: the Fundamentals), I refer to Improvementsand Chores, collectively, as simply Chores – which are defined there as Items that are needed, bynot requested by the Stakeholders.

The fact that the WFT is Self-Contained implies that the WFT has the knowledge to understandand refine the Acceptance Criteria as needed. Part of the Team’s Standard of Care could be to askquestions and carry on a dialogue with the Stakeholders in order to refine theAcceptance Criteriaalong the way.

On the other hand, the Standard of Care is supplied by theWFT – they are the experts on how todo the work… and they have the Integrity to do it the right way every time. The Standard of Careinfluences and defines how theWFT will do the work – what their internal process looks like. TheStandard of Care could define what the end result has to look like, it could require certain processsteps, whatever. AWFT’s Standard of Care could be highly personalized, or it could be determinedby their Industry/Profession, or both.

In many Industries/Professions the notion of a minimum Standard of Care is enforced throughlaws, standards, inspections, or codes of ethics. For example:

• a Medical Professional will lose his/her license to practice medicine if it is determined that heor 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 cleanlinessand food preparation;

• a mechanic will lose his/her certifications if the work is consistently done incorrectly;• and so on…

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

Original Scrum 10

Pattern: Team Coach

The next thing to add to the Scrum Teamwe are building is the ScrumMaster, which is an exampleof a Team Coach.

Problem:

You want to develop and maintain aWell-Formed Team.

Context:

You have a group of people who either are, you think they could be, aWell-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 theirPractices and work together as a Team. This implies that the Team Coach should not haveManagement Authority, as the Team needs to own their own Practices – and it is inevitablethat a TeamCoachwithManagement Authoritywould wind up owning them… just sayin’…

• Make sure that the WFT’s Team Members get whatever Training and Coaching they needto improve their knowledge and skills in order for the WFT to become more versatile andSelf-Contained.

• Have frequent Reflections with theWFT 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 theStandard of Care they must use to do their work.

• Play a Regulatory role and make sure the Team has Integrity and does its due diligenceconstantly 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 anotherfocuses 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 Teamis doing to improve itself. This is the Accountability The Team Coach has.

Discussion and Examples:

This Pattern is almost obvious; it is simply saying that a Team that is doing something complicated,or wants to change its behavior, needs aCoach. However, this pattern is evidenced in many differentways in different industries.

• In the Building Trades, where people go through the progression of Apprentice to Journey-man toMaster as theymature and gain experience, all Journeymen andMasters are expectedto mentor and train theApprentices. Their intended goal is to produce aWell-Formed Team–- and it just happens organically as long as you have one or moreMasters or Journeymenon your team.

• In the Military, it is part of a Non-Commissioned Officer’s (NCO, Sergeant) fundamental setof responsibilities to train and mentor the Troops that he or she works with in order to turnthem into aWell-Formed Team.

• In a restaurant kitchen, this is the sous-chef’s job; it is the sous-chef who make sure that thepeople are trained and that the kitchen operates as aWell-Formed Team.

One thing that may not be obvious is that the Team Coach should be very wary of having Skin inthe Game; that is, the Team Coach should be focused on the Team and its Practices, and not on itsvalue-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 theTeam Doctor is a “Good Team Player” he/she can too easily put Players back in the game toosoon… just sayin’…

Original Scrum 12

• Having the Chief Mechanic as the owner of the shop can lead to problems, if the ChiefMechanic is also the Team Coach and starts concentrating on making money rather thandue diligence. This is a constant challenge when it comes to this kind of work, and why it isrecommended that somebody else do the coaching…

As you can see, adding a Team Coach to aWell-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 fromthe Scrum Team is the Product Owner. The Business Owner I describe in this Pattern is thesimplest version of a Product Owner.

Problem:

There is too much work competing for yourWell-Formed Team’s time.

Context:

You have a Team, with multiple Stakeholders (or one very conflicted Stakeholder) that have manyItems they’d like your Team to work on. Your Team cannot do them all at once, and there isconfusion 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 arate 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 tobe Accountable for understanding the Acceptance Criteria for any Item that is put on the Team’sWork Backlog. We say that the Business Owner Represents the Stakeholders and manages theValue Backlog.

Discussion, including examples:

Let me discuss this Business Owner concept with some of the Well-Formed Teams I introducedbefore:

• The Business Owner for my plumber Jerry is his Office Manager, who gets the calls fromClients describing what work needs to be done, and schedules them on Jerry’sWork Backlog(his ‘Job List’), hoping that Jerry is not overloaded on any given day. If Jerry can’t get it allDone, then the Office Manager rearranges the ‘Job List’ and works with the Clients to ‘makeit work’.

• The Business Owner for the collection of mechanics at a car repair center is the person atthe front desk who asks the Car Owner’s what is wrong with their cars and schedules theircars onto the Shop’s Work Backlog. the Business Owner also works with the Car Ownersto 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. Allof the Waitstaff/Servers fill out meal tickets and deliver them to the kitchen, where they areput on the Team’sWork 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’sWork Backlog,

• the Chief Resident, who meets Ambulances at the door, and immediately places emergencycases at (or near) the front of the ER’sWork Backlog, and

• a medical professional performing triage in the waiting room, which allows some walk-ins tobe moved up the ER’sWork Backlog if their problems are urgent enough.

The second part of the Business Owner’s job: “Move the Items from this Value Backlog to theWell-Formed Team’s Work Backlog at a rate appropriate for theWFT to consume them” is veryinteresting.

• Sometimes theWell-Formed Team asks the Business Owner for a new Item when they areready to start a new one,

• Sometimes the Business Owner monitors the Team’s Work Backlog and just replenishes itwhen it looks a little low,

• Sometimes theWork Backlog is populated at a rate based on historical data from the Team– like Jerry’s daily ‘Job List’, and

• Nomatter what, the rate theWell-Formed Team completes Items from theWork Backlog isbased on the difficulty of meeting the Standard of Care for the Items being worked on andhow many Improvements and Chores the Team is undertaking.

The Business Owner is Accountable for the prioritization of the Value Backlog and the BusinessOwner is Accountable for knowing what Item is needed next. We say that the Business Ownerrepresents the Stakeholders and manages the Value Backlog. These three things (the BusinessOwner, the Value Backlog, and the Stakeholders) go together. If I see a Value Backlog, I assumethere is a Business Owner and Stakeholders, if I see a Business Owner, I know there is a ValueBacklog. And there are always Stakeholders…

Original Scrum 16

As you can see, the Business Owner is a good person for theWell-Formed Team to have around,because theBO both prioritizes and regulates the Items coming into theWell-Formed Team’sWorkBacklog – thus allowing the WFT to focus on its necessary Improvements, Chores, and meetingthe 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 flowof work, such as Backlogs of Bugs or service requests, for example. In these cases there is no needfor Agility as we usually think of it.

However, we are often building Products that require some sort of Feedback Loopwith the Client;in other words, we need some Agile Development. In this Pattern I will expand the BusinessOwner’s role to include working with a Client to develop a Product in an Agile way. When theBusiness Owner and Client have a Project Plan they are working with, I call the Business Ownera 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 aWell-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– TheWell-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 areCost or Schedule constraints that “need to bemet”, or thereare not. If there are, the Business Owner manages them by preparing and maintaining a ProjectPlan, and we call the Business Owner a Project Leader. Basically, a Project Leader is a BusinessOwner who is also maintaining a Project Plan. For shorthand purposes, I will refer to this Role asthe 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 theClient’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 notoverload the Team.

Original Scrum 18

3. The Team builds a Product Increment based on the Items on theWork 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

Discussion and Examples:

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 ongoingcreation of a flow of new Items being placed on the Client’s Value Backlog, based on the Client’sReview of the Product Increments and [if applicable] re-negotiations of the Project Plan. ThisValue Backlog is represented (to the Team) by the BO/PO, and is forwarded to them via theirWork 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 nonegotiated time or money constraints – we just got done when we got done. This example is whenmy 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 workingon the garden. We would go inside to clean up for lunch, and my wife would come outside andlook 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 shouldwork 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 ICleaned 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. Andnow we all have a garden.

Note that this simple Business Owner is not significantly different from the one we saw before, ifthere is no Project Plan involved. Because of the Agile Process in use here, the Client is constantlyworking with the Business Owner to figure out what to do next. As in the previous Pattern, theBusiness Owner is merely forwarding these new Items to theWell-Formed Team’sWork Backlogat 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 fewexamples. The first one will be fleshed out in some detail, and the others are just suggestions forProjects – you fill in the blanks.

1. Let’s say you want to have your kitchen re-modeled, so you hire a General Contractor to doit for you. Then you are the Client and the General Contractor is your Project Leader. TheProject 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 thewalls, notify the Contractor, and the Contractor calls you in for a Review and potentialRe-Negotiation.

• It’s not the Team’s fault that there’s mold, so either the price goes up, or you cut somecorners. You choose to use less expensive flooring, and the price and schedule remainunchanged.

• The next day you go visit a friend and see some real cool appliances – not the ones younegotiated for – and you ask your Contractor about them. You do another Review ofthe kitchen and discuss how it could look. You both agree the new appliances wouldbe great, and the Cost goes up $3000 and the Schedule pushes out 2 weeks because heneeds to order the new Appliances from Germany.

Original Scrum 20

• Aweek 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 notwhat you really want, but you can’t turn it down as it saves you $2000 and it’s availableto be installed right now.

• Because of the new counter-tops, the tiles on the back-splash have to change as well asthe 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 theway you originallyenvisioned it, it cost $1000more than you originally thought, and it’s 2 weeks late. Believeit or not, though, you’re really happy… you got the mold taken care of, and you were inthe loop every step of the way.

2. Fixing your car that was in an accident, where the Insurance Company has simply given youa 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 - itdoes 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 ProjectLeader has two main responsibilities:

1. To Develop a Project Plan, and2. 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 acceptableProduct.

Usually, the Cost, Scope, and Schedule are Planning Values that are derived from PlanningAssumptions that are made andmonitored by the Project Leader. For example, the followingmightbe 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 PlanningAssumptions to match the Reality being observed, derives new Planning Values, and adapts thePlan as necessary. This process often summarized by saying that the Project Leader makes surethat 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 Planrather than try to change Reality. This is not easy, by any means. The following things are discussedand 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 overallCost and the overall Schedule, and these changed values are what is contained in the currentProject Plan. If there is a contractual relationship between the Project Leader and the Client (withthe Project Leader representing the Contractor), the final decision-maker about these trade-offsdepends 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 Contractorwho is absorbing the risk, and

• in a Time-and-Materials contract, the decision-maker is the Client, as it is the Client whois absorbing the risk.

I will use the term Project Leader (PL) throughout this book to refer to the Business Owner whomanages the Product’s Value Backlog and is also accountable to develop and maintain the ProjectPlan. Remember that “accountable” means “can be held to account” or “must be able to explain thedecisions 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 acombination 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, andClient (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 bedoing 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 Stakeholderswant 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 thathave 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 ProductOwnerwants theTeamto do them.)

• Each Sprint starts with Sprint Planning, which is when the Development Team and theProduct Owner discuss and negotiate the content of the upcoming Sprint. There are twoparts:

– In Part 1 the Product Owner and theDevelopment Team discuss what should be done,and the Development Team commits to which Items from the Backlog they will getDone in the Sprint

– In Part 2 the Development Team decomposes these Items into Tasks, and these Tasksare collectively called the Sprint Backlog

• As the Team does work in the Sprint,– theDevelopment Team has daily Standupmeetings, which are a formalism of theWell-Formed Team’s frequent Coordination Meetings,

– the Development Team produces a Product Increment by doing its due diligence andcompleting 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 acceptablefor delivery. If the Product Increment is acceptable for delivery, then the Team cleans itup and delivers it. If it is not acceptable for delivery, the Product Owner may advertisepredicted Delivery Dates to the Stakeholders.

– the Scrum Master has a Retrospective with the Development Team, which is aformalism of the Reflections the Team Coach has with theWell-Formed Team.

The Product Owner is Complicated

I mentioned that the Product Owner is an amalgam of the Business Owner, Project Leader, andClient. Here’s why I said that:

• the Product Owner “owns and manages” the Backlog, and this makes him the BusinessOwner, as the Product’s Value Backlog is part of the Backlog, and the Business Ownermanages the Value Backlog…

• the Product Owner Reviews the Product Increment. This makes him the Client, as it is theClient 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 theBacklog (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, AgileSoftware Development with Scrum, Schwaber and Beedle, 2002, pg 34: “For the Product Owner tosucceed, everyone in the organization has to respect his or her decisions. No one is allowed to tellthe Scrum Teams to work from a different set of priorities, and Scrum Teams aren’t allowed tolisten to anyone who says otherwise.” (emphases mine) This prioritization of the Backlog is thedefining characteristic of the Product Owner, even though there are all the other responsibilitieslisted above.

Issues

The Original Scrum as defined here is a beautiful thing, and can be, and has been, used to greateffect. 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 theWork Backlog consists of Items that the Development Team understands and can implement. Itis the Product Owner’s job to convert the Stakeholders’ Value Backlog into the Team’s WorkBacklog, 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 beable to focus on small bits of Functionality, like Scenarios or other Items defined by AcceptanceTests.

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 onits own Improvements and Chores. The time spent doing this is not managed from outside theTeam. Many Organizations have problems with this, and want control over this work – and this cancause problems with the Team’s Self-Organization.

This issue will be addressed with the Team Leader Pattern.

Product Owner as Project Leader

The Product Owner (as Business Owner) Manages the Backlog, which defines the Scope of whatthe 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 ProjectLeaders, and try to force the Development Team to meet unrealistic Delivery Dates⁴, rather thanprojecting Delivery Dates based on the Reality of the Team’s Production Rate. In fact, this issuch a problem that many Scrum Trainers have said that one of the Scrum Master’s primaryresponsibilities is to protect theDevelopment Team from these bad Project Leadersmasqueradingas Product Owners.

This issue will be addressed with the Team Leader Pattern.

Coercive Planning

In Original Scrum the Development Team commits to the work they will do in a Sprint, in spiteof the fact they they don’t know how much effort it will take to meet the appropriate Standardof Care or how much work they will need to spend on Improvements and Chores. How can thiswork? 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 SprintPlanning. This is a predictive process. How do the Team and Product Owner know what they willneed to be doing 2 weeks from now? Maybe there will be a show-stopper bug that turns up… maybethe Stakeholders will realize that they’ve changed their minds… I don’t know. We would expectAgile methods to avoid making predictions, wouldn’t we? We would expect the actual content of aSprint 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 holdsomeone on the Team accountable, or answerable, for what the Team is doing. If nothing else, theProduct Owner often wants a Point of Contact (POC) on the Team, and this POC winds up withde 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!!

This issue will be addressed with the Team Leader Pattern.

⁴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 mentionit. It has always been a rule of Scrum that theDevelopment Team produce a Potentially ShippableIncrement each Sprint, and some have read this to mean that they must Ship Product everySprint. This has led to some seriously hacked-out Code, and a complete disregard of any reasonableStandard of Care. This is exactly the opposite of what is supposed to happen… the intention of ofthe Potentially Shippable idea is that it should cause the Team to follow an appropriate Standardof Care. Here is the quote⁵

“Scrum requires Teams to build an increment of product functionality every Sprint. This incrementmust be potentially shippable, because the Product Owner might choose to immediately implementthe 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 thefunctionality is documented, either in Help files or in user documentation. This is the definition ofa “done” increment.”

As you can see, this definition of a Done Increment (Potentially Shippable) is about Quality – theStandard of Care that must be followed. Unfortunately, many have seen it as required ReleasableCode, which means Code that the User can actually use, which has led to hacking our bad Codethat has a lot of features. The work that lives in the “Done but not yet actually Releasable” is oftencalled Undonework; a simple example of this is when my son and I cleanup of the Garden and tookthe 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 andinside-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’tunderstand their Craft.

2. A Team trying to meet unrealistic deadlines is often forced to write Bad Code – the “Motherof all Problems” I mentioned above.

What is CleanCode? Inmany (if notmost) professions there is the notion of due diligence tomeeta Standard of Care; not doing one’s due diligence is considered malpractice - and malpracticewill 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 tosatisfy the ‘-ilities’ (reliability, extensibility, maintainability, etc.), but there is no requirement forsoftware developers to do their due diligence to make this happen. There are some standards thatpertain to software in certain Industries or situations (FDA, FAA, Sarbanes-Oxley, etc.), but thesestandards are usually considered part of theAcceptance Criteria rather than as part of the Standardof Care. In software, the Standard of Care would be about how to write Clean Code (includinganalysis, design, code, test, etc.), not how to satisfy the requirements.

In software there are documented Best Practices about Software Craftsmanship, as we see inthe eXtreme Programming (XP) practices, or in the books Clean Code by Bob Martin and Workingwith Legacy Code by Michael Feathers, and many others; but there is no requirement for softwaredevelopers to either know, understand, or use them – there is no requirement to treat our vocationin a Professional way. This is unfortunate, and the reason that Scrum brought the Well-FormedTeam 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 shortcutsmust compromiseCode Quality, because there is nowiggle room in the othervariables (Cost, Scope, and Schedule),

• As the Quality decreases, the shortcuts become more and more drastic to keep up withschedules, 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 theProfessionalism of the Team Members.

This issue will be addressed by the Definition of Done Pattern and the separation of the ProjectLeader 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’lladdress multiple Teams and multiple Products issues later, when we talk about Scaling.

⁶The Enterprise and Scrum, pg. 93

Modern ScrumOriginal Scrum works very well for mature Teams in good Organizations. Not surprisingly, lessgood otherwise. Since 2004 (or so) several improvements/changes have been made to Scrum to makeit more useful. I will still assume there is a singleTeamworking on a single Product, but I’ll introducethe 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 Teamcan 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 getprioritized “against” the Items coming from the Business Owner’s Value Backlog – theBusiness doesn’t want the Development Team making these decisions as part of their SelfOrganization.

2. The Development Team needs ongoing “tactical” advice – during the Sprint – about what ismost 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 enoughunderstood for the Team to work on – they need to be Refined before they becomeappropriate for the Team to work on them.

4. The Product Owner needs a Point of Contact on the Team to hold Accountable, oranswerable, for the Team’s actions.

Context:

There is a Original Scrum Team working on Items being prioritized by a Product Owner externalto the Team.

Solution:

Have a member of the Scrum Team, called the Team Leader, with the following Accountabilities:

• The Team Leader isAccountable to the Product Owner for the prioritization of all the workdone by the Scrum Team, including Improvements and Chores,

• The Team Leader is Accountable for Refining the Items coming from the Value Backlogso 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 thiscould 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 theDevelopment Team), so that ScrumMastering and ProductOwnershipresponsibilities belong to the whole Team – the Self-Organization is not simply about Develop-ment.

The Team Leader

Discussion, including examples:

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 Ordersprovided by theWaitStaff. Inside the kitchen, however, the Sous Chef is running the show, andis accountable for “the kitchen’s inventory, cleanliness, organization and the ongoing trainingof 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’sWork Backlogalong 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 BusinessOwner assigns the Job to the Team, but the Foreman works with the Team to divide the Jobinto 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 requireexpertise 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 towork on.

Solution:

Have Subject Matter Experts (SMEs) join the Team, as honorary Team Members, when the Teamneeds to use their expertise.

Modern Scrum 33

Subject Matter Experts

Discussion, including examples:

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 theTeamworking on Improvementsor Chores, they can be shared across several Scrum Teams, they can be just about anything.

Normally, the need for a SME is determined by theDevelopment Team and the ScrumMaster, andthe 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 oftenthought 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 durationof 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 “lotterymetric”⁸ for the Team. My favorite pattern for using SMEs is the Buddy Up Pattern, which identifiesan existingTeamMember to be the SME’sBuddy. ThisBuddy isAccountable to theTeam for workthe Team needs the SME to do, or help do. The SME and the Buddywork 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 areProfessionals. 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 theirwork.

Context:

You have a Scrum Team doing work, and the work they are doing is not meeting an appropriateStandard of Care.

Solution:

Attach aDefinition ofDone to each Item (augmenting the Item’sAcceptanceCriteria) that assuresthat the Item is developed with an appropriate Standard of Care. The ScrumMaster works withthe Team to assure that the Item meets this Definition of Done as the Item is being worked on.

Definition of Done

Modern Scrum 36

Discussion, including examples:

Well-Formed Teams are supposed to be Professionals, and come preparedwith their own Standardof Care that they do their due diligence to meet every time they do work. The Stakeholders arerelying on this when they use a Scrum Team. In software, an example of this is a DevelopmentTeam that diligently uses theXP Technical Practices and see themselves as Professional SoftwareCraftsmen when they develop their Code.

Often, the TeamMembers 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 theScrumMaster (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 aDefinition of Done”.Here is an example of an Item with both Acceptance Criteria and Definition of Done for an Iteminvolving an Airline website.

Definition of Done Example

When there is more than one Team working in the same Codebase, they each should use the sameDefinition 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 usedtheir due diligence and met the same Definition of Done as they did.

Usually, each Item has its ownDefinition of Done, but some Teams have applied the concept to theProduct 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 Definitionsof Done for different kinds of Items (this is called Storyotyping⁹. It really doesn’t matter, as longas 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 Deliveredor Reviewed for perfectly valid business reasons (Trade Show, big Client, whatever), but the Teammay not pretend that the Work was Done – the Team Members may not pretend that the Workmet an appropriate Standard of Care. When this kind of stuff happens, they need to add a CleanupItem – one that promises to clean up, or finish the work – to the Backlog, so that nobody will forgetit; 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 Undonework. This is not a bad thing, but deciding what to leave Undone is a decision that needs to bemade. For example, deciding to leave off polishing the User Documentation until the end may be agood decision, but deciding to delay collecting the information for the user documentation until theend probably isn’t.

The Definition of Done can be extended to be a robust Standard, including standardizingarchitectural and design patterns, providing necessary reviews and inspections, and so on. It issomething 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 roleon 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 Planningmeeting in Original Scrum is both Coercive and Predictive, and each of theseis 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 lesscoercive and/or predictive.

Solutions:

Each of these problems, as well as other planning problems, have been addressed inModern 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 Planningproduces a Forecast of whatmight get done, and this is called the Sprint Backlog. This makesSprint Planning less Coercive, but may not make it less Predictive – the Team Members arestill 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 andcorrect¹⁰.

1. It is now recommended that Sprint Planning does not fill up the Sprint – planning is nowsomewhat malleable, making it less predictive. In the more recent Scrum Guides, Ken andJeff have stated that the initial Sprint Backlog (the result of Sprint Planning) only fills upabout 80% of the effort available in the Sprint, with remaining Sprint Backlog Items arisingthroughout the Sprint.

2. There is a move to doing a more kanban-ish version of Sprint Planning, where the SprintPlanning meeting only selects the Sprint Backlog Items that will be started right now, andadditional 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

Discussion, including examples:

Over the years, there was a realization that the Sprint is a feedback cycle, not a planning cycle ora work cycle. Along with this realization came the idea that Sprint Planning was not the big dealeverybody 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-defineddefinition of Done (the combination of theAcceptance Criteria and theDefinition of Done), thenthe ScrumTeam just has to work its way through theWork Backlog, in order, and Review whateveris 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 hasbecome mentally agile. This type of planning is neither Coercive nor Predictive, seems to be theright 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 withthe modifications described in this Chapter:

• The addition of a Team Leader, the TeamMemberwho is accountable to the Product Ownerfor the value of the work performed;

• Making the whole Team (not just the Development Team) into a Well-Formed Team, andadding the responsibility to Refine the Items on the Work Backlog in order to make themReady 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 ValueBacklog;

• The addition of Subject Matter Expertswho provide knowledge and expertise that the Teamneeds, but does not have;

• Using the Definition of Done to impose the use of an appropriate Standard of Care by theTeam; 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 lotin the Scrum Community. This Team Leader role was called the Proxy Product Owner for awhile, and then it was decided that, no, this Team Leader is actually the Product Owner – that theProduct Owner had to be a Scrum Team Member; a part of the Self-Organized Team – and thisdecision 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 tobe 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 Teamswith Product Owners and ScrumMasters at each level. In fact, the definition of the ProductOwner in this book (pg. 114) is team-focused: The Product Owner is “the person who isresponsible 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 Iinterpret it. But it causes us problems, because the Product Owner role in Original Scrum is notthe Product Owner role inModern Scrum. Oops… so I’m going to go back to calling the original roleeither 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 aProject. 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 beone-and-the-same person. I agree, in principle. However, I don’t want the Product Owner to be theProject Leader – the Development Team must be separated from the potential of a bad ProjectLeader – a bad Project Leader can have a very coercive and damaging effect on the Team, andthus the Product itself.

Review of the Accountabilities in Modern Scrum

Earlier I discussed how important a Role’s Accountabilities are. Because of the self-organizationinherent 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 thisas the Roles OBT (One Big Thing). Here they are:

• Team Member: Accountable to other Team Members for doing his/her due diligence andusing the appropriate Standard of Care to help Stories meet their Acceptance Criteria andDefinition of Done. Each Team Member must be able to explain to other Team Memberswhat he/she is working on, what issues issues are cropping up, what help is needed, and soon.

Modern Scrum 42

• ScrumMaster: Accountable to Management to make the Team better through the use ofScrum. Must be able to explain what Impediments the Team has, and what the Team isdoing to mitigate or remove them.

• Product Owner: Accountable to Management to optimize the value the Team produces;accountable for optimizing the value represented by aWork Backlog. Must be able to explainwhat work the Team is doing, why it’s important, and the status of it.

• Business Owner: Accountable toManagement 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 whythey are important.

• Project Leader: A Business Owner who is also accountable for predicting Release Datesand/or keeping a Project Plan in balance with Reality. Must be able to explain the rationalefor Planning Assumptions, the derivations of Planning Values, and the intended effects ofactions taken to balance the Project Plan.

Problems with Modern Scrum

As has been discussed throughout, Modern Scrum solves many of the problems that existed inOriginal Scrum. In fact, I seeModern Scrum as a well-oiled machine – as a balanced collection ofPatterns. 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 couldguarantee this, but at least we have both the Product Owner and ScrumMaster protectingand shielding the Team from this potential bad Project Leader – as long as we keep theProject Leader outside the Team.

2. Modern Scrum still assumes a single Product; and3. 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 - thePrinciplesWell, so far we’ve seen the Patterns that Scrum is made up of – both Original Scrum andModernScrum. In the rest of this book I’ll be exploring Patterns that are used to extend Scrum; to allow itto Scale and work in other contexts. Remember that Scrum, as it is defined, is only applicable to asingle 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 withWell-Formed Teams – this was our most basic Pattern,and our fundamental Principle.

2. You shouldn’t dismantle existingWell-Formed Teams; it takes a long time for aWFT to geland become high-performing, and most of us believe that it is easier to changeDomains thanit is to being a new Team up to speed. I will admit that this is not a universal Principle, but itseems 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, whomust 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” requiresaWFT, and

– Somebody on thatWFTmust haveAccountability for that Decision (a general rulein 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 makeall 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, notdirectives. We often use Rules of Thumb to help our Decision-Making, but they aremerely 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 youwill get Heroic Decision-Makers when you instantiate the Framework or Pattern – youmay get one, so you can collapse your instance, but you can’t assume you will get one… justsayin’…

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 PatternsAs we have just seen, Modern Scrum is a wonderful Framework that is designed for one Teamproducing 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 variablesotherwise…

Multiple Locations

The last case – more than one (virtual) Location – is easily handled – it won’t work within the sameSoftware Development Scrum Team. You need to add technology so that the Team Members havehigh-bandwidth communications with each other for at least 3-4 hours a day in order to get thecommunications between the developers that is needed to develop software. This notion of having3-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: multipleTeams andmultiple Products.And, I’m going to move away from talking about a single Backlog, and start talking about the ValueBacklog and Work Backlog. As we see in the picture of Modern Scrum, we have four differentBacklog-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 areplaced on the Team’sWork Backlog by the Business Owner.

• Work Backlog – Prioritized list of Items (including the Scrum Team’s own Improvementsand 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 currentSprint

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” entitiescollaborate on the ordering/prioritization of the Value Backlog, and the “to” entity is Accountablefor 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 representingthe inputs of thisWork Backlog to the “to” Entity.

• The “from” and “to” Entities work together to Refine theWork Backlog (with the “to” Entitybeing Accountable for this work) so that:

– TheWork Backlog accurately and appropriately represents its Inputs– TheWork 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 theWork 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 totheWork Backlog at this point, and were not inputs to theWork Backlog.

• The “to” Entity is Accountable for understanding and representing thisWork Backlog to theOrganization, with particular attention on the down-stream Entities.

• I’m not showing the Tasks inside theDevelopment Scrum Team, as they are simply a matterof 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 aPlan-like thing (Delivery Date, Project Plan, RoadMap, and so on) is being produced and updatedat 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 horizontallines on the left). For Teams other than Development Teams I will use this symbol to indicate theTeam’s Backlog because these Scrum Teams have a Backlog separate from theWork Backlog. Forexample, as we’ll see, aDistribution Team’s job is to manipulate Backlogs, and its work is managedby a separate Backlog.

Organization of this Section

Scaling often requires the existence of Teams that can be used more-or-less interchangeably, so thefirst Pattern in this Section is theGeneric 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 sameBacklog, 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 whenmultiple 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 canshare 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 ofworking in many different Domains. Specialize these Generic Teams with Subject Matter Experts(SMEs) as required.

Discussion

Organizations often specializemost of their Development Teams – having them focus on a specificProduct, Functional Area, Customer, or Technology Area. The thinking is that this specializationmakes 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 determiningwhichWork Items goto what Teams. It often leads to Teams identifying themselves with the specific Product, FunctionalArea, Customer, or Technology Area – they think of it as being “Our Stuff,” and it really might bethe only Stuff they’re good at.

This could be a problem when too many Teams are in this situation, as the Organization could betoo 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 thoseHard Decisions.

Here is a simple example. If a particular Project runs into problems and needs some additionalhorse-power to get it across the line, where is it going to get it? There must be some Teams outthere that can pick up some of the excess work, but theOrganization’s Teams may have specializedthemselves 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 ofadapting to different things that might come up. It would be nice if all of them were completelyadaptable, 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 onthe 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 multipleDevelopment Scrum Teams, who each need their ownWork Backlog.

• There is a Value Backlog being split into two Value Backlogs to be fed to two differentEntities; an example is splitting a big Value Backlog into two little Value Backlogs fordifferent Organizations to work on.

• We could have a Development Team split into two smaller Teams, and thus need to split itsWork 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 theDistribution Team (they are probably Virtualmembers)

• The primary purpose of the Distribution Team is to decide which Items from Backlog-Awillgo to each of Backlog-1 through Backlog-2.

• (for each i) Owner-i is Accountable for representing and explaining Backlog-i’s Items to theOrganization.

• (for each i) If Backlog-i is a Work Backlog, then the Distribution Team will help Owner-Aand Owner-i Refine and Order theWork 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 beingOrdered 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 orher Plan every Sprint.

• If Owner-i is also a Project Leader, being on the Distribution Team will provide usefulinformation for updating his or her Plan every Sprint.

• The Distribution Team has its own Backlog that describes how it will carry out theseResponsibilities.

Distribution Team

Discussion, including examples:

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 otherwords, this Distribution Team may have its own Scaling issues.

• Luckily, these Distribution Teams can be layered, allowing a Backlog to be split manydifferent times, solving the Scaling problem mentioned above.

• Since this is a Scrum Team, and thus aWell-Formed Team, theDistribution Teammay needadditional SubjectMatter Experts to helpwith the splitting of theBacklog. These SMEs couldbe Architects, Business Analysts, experts in the Business Domain – whatever is needed.

• Since theDistribution Team is aWell-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 Maintainany relevant Project Plans, and that any Project Leadership must be good ProjectLeadership – 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 animplied hierarchy (see theManagement Team Pattern).

This is a simple, but powerful, Pattern. It’s primary strength is that it brings the right People togetherto 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 singleDevelopment Team (A Teamworkingon multiple Projects, for example).

• Multiple Value Backlogs being collapsed into a single Value Backlog so that it can bemanaged as a single entity.

Solution:

There are multiple cases here; however, the idea is the same in all cases. There will be aConsolidation Team made up all the Owners of the Input and Output Backlogs, along with anySubject Matter Experts that are needed, and thisConsolidation Teamwill create the single OutputBacklog 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 ProjectLeaders Develop and Maintain their Project Plans.

Discussion, including examples:

Unlike the Distribution Team Pattern, the kinds of Backlogs do matter. the Input Backlogs willalways just be passed through, but whether the Output Backlog is a Work Backlog or a ValueBacklog makes a difference, as aWork 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 picturefor 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 BusinessOwner roles in Modern Scrum – we see this in the middle of the diagram. The next step is toassemble the Consolidation Team, made up of the Team Leader (in Business Owner role) as theTeam’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 aWork Backlog,• Add appropriate Chores to thisWork Backlog, and• Help the Project Leaders develop and update their Project Plans, if applicable.

Another case is whenwe havemultipleBacklogs flowing into a singleWorkBacklog via aBusinessOwner. This is basically the same case, with the same responsibilities as listed above, but theBusiness Owner plays the Product Owner role on the Consolidation Team, and the Team Leaderis 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 ValueBacklog, 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 Leaderrepresenting all theBacklogs. Assuming that prioritizing across all of theseBacklogs is aHardproblem, 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 theright, which has:

• The original Business Owner as the Product Owner of the Consolidation Team,• The new Business Owners as TeamMembers, along with any required Subject MatterExperts, 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 Ownerof the Output Backlog is Accountable for the analysis and work that went into the development ofthe Output Backlog. In particular, this Business Owner must be able to explain why the prioritiesare 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 andmeet 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 thataffecting 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 atime? 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 somethinglike 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 befinished 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 willactually 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 probablywon’t stand for it. Assume you are theProject Leader for “Project2” (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 puregarbage…

2. You know that “Project 2” is much more important than “Project 1”, so, if any Project was togo 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 getsthat 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 sharethe Team. Therefore, they Project Leaders won’t allow this (perfectly logical) approach to actuallyhappen.

Now, you can buy my argument or not. You can decide that doing one Project at a time is a goodidea or not. I really don’t care. But, we must agree that this is a Hard Problem. The Projects haveto share the Team somehow, and Deciding how the Projects share the Team is a Hard Decisionthat needs to be made. That’s why we have a Consolidation Team do it – and that’s why all theinvolved 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 otherwords, 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 onmy 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

Discussion, including examples:

There’s not too much to say here. Most of the comments are just duplicates of what you find in theDistribution 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 OutputBacklogs. Therefore, try to keep the total low. If need be, divide it into separate Consolidation andDistribution Teams, as see in the middle of the diagram.

Whatever you do, don’t try to replace the Program Teamwith a set of Rules – this is always wrong– the Decisions a Program Team has to make are *always** Hard Decisions, and require a ScrumTeam to make them. The PO of the Program Team*8 (called the **Program Manager in standardPM-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 tosimply 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 itsItems onto the other two Teams in order to balance the load? Nobody. There’s a Rule, and theOrganization 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’ OrganizationsScaling Patterns are very important, as they show us how anOrganization can get big successfully.Once anOrganization is big, there are other Patterns that arise just from the ‘bigness’. When I thinkof 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 beused to provideManagement Teams

Problem:

Many Organizations rely on ‘Heroic’ Management, which I define has having single Individualsmake Hard Decisions and solve Hard Problems without a lot of support. This often leads to eitherpoor 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 thediagram below. This diagram shows 10Management Teams, at all levels of the Hierarchy.

Each of theseManagement Scrum Team (MST)s has the following properties:

• TheMST’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 appropriatemembers of the Senior Manager’s Organization that are needed to act as Subject MatterExperts in order to make the Team Cross-Functional.

• ThisManagement Team is responsible for helping the Senior Manager (theMST’s ProductOwner) make Decisions about the Hard Issues and Problems in the Senior Manager’sOrganization.

Patterns for ‘Big’ Organizations 61

Management Teams

Discussion, including examples:

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 HardDecisions that are necessary for their Organization, no matter how low (or high) they are in theHierarchy.

Daily Scrums

Each Management Team has a Daily Scrum when it discusses the Issues of the Day specificto its part of the Hierarchy. Each of the Junior Managers shares what his or her Organizationdid 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 towardstheManagement Team’s Backlog. TheManagement Team then has a discussion, focusing on theImpediments, Cross-Cutting Issues, and guidance for what to do today. The Daily Scrum shouldresult in Communication and Cooperation across Teams, as well as Decisions about dealing withthe Impediments.

• Because of the Hierarchy’s layers, the Management Teams may have a series of DailyScrums, so that each Manager can go from his or hers MST’s meeting (where he or she is

Patterns for ‘Big’ Organizations 62

the PO/TL) to the next one of where he or she is a Team Member. This will allow Issues andProblems 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, wherethe higher-levelManagement Teams meet earlier in order to pass-down orders and guidanceto theOrganization. This difference lies in the change fromCommand and Control thinkingto Agile thinking, where theManagement Team’s job is to solve problems rather than issueedicts.

In the structure I’m describing here, eachDaily Scrum results in Issues being brought up, andDecisions being made. These Decisions are then taken by the Junior Managers back down totheir Organizations to be implemented immediately.

Reality comes up the Hierarchy and Decisions flow down the Hierarchy on a Daily Basis.• Each of theManagers (PO/TLs)must makeDecisions about the Issues and Problems that comeup during his Daily Scrum (the one where he or she is the PO/TL). If the Issue is restrictedto his or her Organization, then the Manager has an obligation to solve the Issue beforebringing it to his or herManager’s Daily Scrum. This solution may be to put the Issue on theBacklog for later, it may be to defer the Issue to his or her Team to be solved through Self-Organization (although theManager will still be Accountable for the solution), it may be atemporary work-around, or it may be a permanent solution, but a Decision about a solutionmust be made.

• Because of the above, when a Junior Manager is discussing hisOrganization’s Impedimentsand Issues at the Daily Scrum, he or she will be discussing the Decisions he or she just made(in aDaily Scrum a fewminutes ago) about them. This allows discussions about the Decisions,and helps the Junior Managers become better Decision-Makers through these discussions. Ifthe Senior Manager disagrees with the Decision, it can be corrected quickly; if the Decisionwas 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 formanaging 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 onthese Items. If the Junior Manager is also the Business Owner of some Backlog or other, he orshe must expect to spend some time with the Backlog’s Stakeholders. If the Junior Manager is a

Patterns for ‘Big’ Organizations 63

Development Team’s Team Leader, he or shemust spend a lot of time with his or her Team. In anycase, we can see that all of theseManagers will be splitting their time among a number of differentgroups:

• They are the Team Leader for some Team or other, which could be either a DevelopmentTeam or aManagement Team;

• They are a Member of aManagment Team (not the Team Leader);• Theymay be aBusiness Owner, and thus represent (andwork with) a group of Stakeholders.

There is a lot of Coordination, Communication, and Decision-Making for these people to do. Trynot to overload them with other work.

Summary

The most important thing about the Management Team is that the Senior Manager has theright people bringing (and helping to solve) the Hard Issues and Problems the Senior Manageris Accountable for. This makes the Accountability clear, and it offers the best chance of makinggood Decisions and getting buy-in for these Decisions.

Patterns for ‘Big’ Organizations 64

Pattern: Cross-Cutting Workgroup

In ‘Big’ Organizations there are lots of smart people spread out all over the place. Sometimes thesepeople 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 problemsare spread out across the Organization. The reasons for this are probably one (or both) of thefollowing:

• 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 thefollowing 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 theOrganization 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 theWorkgroup, but most (if not all) of theWorkgroup’s Team Members should have real jobsthroughout the Organization – this is considered a part-time thing for most of them, and wewant them grounded in the Realities of current Development,

• The Team works with the originator(s) of the Hard Problem(s) to determine the AcceptanceCriteria 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 DiscussionSection…

Patterns for ‘Big’ Organizations 65

Discussion, including examples:

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 connectingthem – they just happen to reside on the same Base. The Base, itself, has its own Unit that controlsthe grounds, the PX, the Commissary, and so on. On the 4th of July it is traditional for all ArmyUnits 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 aWorkgroupmade up of one person from each Unit, with the person fromthe Base’s Command Unit being the Product Owner. It is common for this Product Owner tonot be the most senior Team Member – thisWorkgroup is not managed with a typical commandstructure. The purpose of this Workgroup is to determine how to apportion the ball-fields, picnicareas, 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 Problemwith 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 offamily members to come, medal ceremonies, more speechifying, …),

• Howwill 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…

Patterns for ‘Big’ Organizations 66

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 – andPermission to – solve the Problem.

Now, let’s look at the Workgroups we see in the diagram, as they provide a good sampling ofWorkgroups 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, aDBA, and whatever other Experts it needs to do this work. Each of the TeamMembers has a real jobon some Development Scrum Team somewhere, but there may be a lead UX person, who works atthe Organization level, and acts as the PO. Each of these Team Members helps determine whichproblems 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 probablyconsists only of Architects, and maybe a Chief Architect at the Organization level. The main pur-pose of theArchitectureWorkgroup is to provide nearly-instantaneous advice to theDevelopmentScrum Teams as they need it. This advice would be provided by the Architecture Workgroup’sTeam Members (in their capacity as Architects on Dev Teams), and after giving the advice thecould double-check it with the Architecture Workgroup. Since thisWorkgroup consists solely ofArchitects, it can be seen as a Community of Practice (CoP) or a subset of a CoP. This is not anIvory Tower group of Architects developing Frameworks!

SME Management Workgroup: One of the major problems facing a large Organization is thesharing of Subject Matter Experts (SMEs) across the Teams. One Pattern I like to use is the BuddyUp Pattern, where each of the Teams that needs the SME assigns a Team Member to work as theSME’s Buddy; this Buddy is Accountable to the Team for the SME’s support – either the Buddygets the SME to help, or the Buddy must do it himself. Then, aggregate all the Buddies onto aScrum Team (with the SME as Product Owner) that will determine how the SME supports thevarious Teams. The SME Management Workgroup puts the people with skin in the game (theBuddies), 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” theOrganization to solve Hard Cross-Cutting Problems. This Pattern is often combined with theCommunities of Practice (CoPs) Pattern, since they both involve Cross-Cutting groups, but thereare differences:

• Cross-Cutting Workgroups don’t have to contain people of the “same type”, while aCommunity of Practice does, and

• Cross-Cutting Workgroups are about solving Hard Problems, while Communities ofPractice are (primarily) about Knowledge Transfer.

In any case, I’ll describe the Community of Practice Pattern next.

Patterns for ‘Big’ Organizations 67

Pattern: Community of Practice

In a large Organization there are lots of different types of People that need to keep current in theirtechnical 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 placeworking 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 andProject 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 ordisorganized, and they may meet frequently or infrequently. What makes this a Pattern is thatthe Organization allows the Communities to exist, which takes time away from the Project andDevelopment work the People are “being paid to do.”

Discussion, including examples:

Possibly the most ambitious, most extensive, and most expensive way to do this is the way the USArmy does it, which actually has three layers. The first, and more expensive, layer is formal trainingat 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 layeris formal training within their units, which is offered by trainers affiliated with the appropriatemilitary schools. The third layer is informal training within their units that is facilitated by moresenior soldiers. And, of course, all soldiers are expected to work with each other and mentor all theirsubordinates. The Army takes its Training, and its Communities of Practice, very seriously.

At the other end of the spectrumwe haveOrganizations that sponsor “Brown Bag Lunches” for theirCommunities of Practice. These “Brown Bags” are sometimes used for Book Discussion Groups,or guest speakers, or whatever else makes sense.

Patterns for ‘Big’ Organizations 68

I can imagine, in a large Organization, having a day or two between Sprints that could be used forupdating Plans, refiningValue Backlogs, and havingCommunities of Practicework together. I canimagine having small, internal,Open Space conferences, delivering technical papers and experiencereports, 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 youwould use Cross-Cutting Workgroups, and this seems a very reasonable combination of the twoPatterns. Just remember that the Patterns are actually different: theCross-cuttingWorkgroups areabout solving Problems and could involve cross-functional Teams, while a Community of Practiceis about sharing knowledge and increasing learning within a group of people with the same basicskill-set.

In any case, the Community of Practice is a very powerful Pattern that is very useful in a largeOrganization.

Patterns for ‘Big’ Organizations 69

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 alwaysavailable 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 threethings:

1. It creates (or receives) an Integrated Product developed by multiple Development ScrumTeams,

2. It Evaluates this Integrated Product using External Reviews and specialized Testing, and3. It produces a Value Backlog of Items based on this Evaluation.

Integration and Evaluation (I&E) Team

Patterns for ‘Big’ Organizations 70

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 Leaderis a (virtual) member of the Product Management Team. The diagram shows that the I&E Teamproduces its own Value Backlog, consisting of Defects, new Features, Change Requests, and soon (resulting from the Evaluations), that is fed back into the Project Management Team forConsolidation into the overall Value andWork Backlogs.

Discussion, including examples:

Basically, this is nothing more than a dedicated Test Team that also conducts external Reviews, butthere are some things to note:

• This Team is doing Validations, not Verifications. Every piece being Integrated meets itsDefinition of Done; everything “meets spec”. This Team’s job is to do additional Validationsthe 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 ScrumTeams, the individualDevelopment 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/orenvironments 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 Accountablefor the Integration, but it is a better idea for each Development Team to be Accountable forsuccessful 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 DevelopmentTeams.

Evaluating FrameworksNow that we’ve got a bunch of Patterns and Principles to use, let’s see what they tell us. Inparticular, 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 Ihave 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 versionof Scaling in Crosstalk Online (May/June 2013)¹³. Their main purpose is was to extend the essenceof 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 Scrumthey are extending is Original Scrum, so they are missing out on many of the improvements ofModern 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 singleDistribution Team – at least when you look at it from aModern Scrum perspective.

LeSS-1 as Patterns

Basically, LeSS-1 is described as a big ScrumTeam: it has a single Product Owner, a singleBacklog,and a single Product. It contains multiple sub-Teams (the Scrum Teamminus the PO) that integrateinto a common CodeBase, and there is a single, joint Product Review. It’s quite nice, actually, andI 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

Evaluating Frameworks 73

• The Product Owner is seen as a Product Expert rather than anAccountableDecision-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 thatcut across the internal Scrum Teams.

I think that LeSS-1 shows that there are different ways to Scale to this size: both the DistributionTeam 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 isa better solution, because it generalizes. I believe that their Scaling up to the next level doesn’t workso well.

In order to Scale up to the next level Craig and Bas introduce LeSS-2, which is equivalent to alayering 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 introduceArea Product Owners and a Rule that decides which Items on the Product Backlog flow tothe various Area Backlogs. I object to this, because “Rules don’t make Decisions, People do.” asI mentioned a few chapters ago.

In other words, the large-scale Self-Organization that Craig and Bas espouse only Scales so far. Ilove Self-Organization inside a single Scrum Team, which is why I like Hard Decisions to be made

Evaluating Frameworks 74

by Scrum Teams such as the Distribution Team… just sayin’… :)

Evaluating Frameworks 75

Analysis of the Scaled Agile Framework (SAFe)

Dean Leffingwell’s Scaled Agile Framework (SAFe) is a very ambitious Framework with a lot ofpieces. 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 Developmenttakes 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 multipleRelease Trains and Releases, and affect multiple Organizations. Each of these Epicshas 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 itDeveloped.

Evaluating Frameworks 76

2. Decomposing and Distributing these Portfolio Backlog Items to the individual ART’sProgram Backlogs, along with a Vision and Roadmap to help each ART with its ReleasePlanning.

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 aRelease Plan, Release Objectives, and buy-in from everybody in the Release Train to theseObjectives. Note: the point of a Release is not necessarily to actually Release something,but to produce a Potentially Releasable Increment (PSI) of Product. Basically, SAFeacknowledges that Releasing something is a Decision (at can be done at any time theBusiness thinks the Product is Releasable), but being Potentially Releasable is a State (theProduct meets both its Functional and Quality Goals – and that the Goal of a Release isactually to reach the State of being Potentially Releasable.

2. The ART proceeds to work in 2-week Iterations, doing basic layered Scrum, inspecting andadapting, 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

Evaluating Frameworks 77

The Agile Release Train

Let’s start with theAgile Release Train (ART). This is basically a largeWell-FormedDevelopmentTeamwhose input is the Program Backlog. There are two additional Teams inside theART beyondsimply Development Teams:

• There is an added I&E Team called the System Team, which Integrates Product from ScrumDevelopment Teams, performing end-to-end System Testing, and demonstrating solutionsto Stakeholders at each iteration; and

• There is a Release Management Team, whose primary responsibility is to coordinate andfacilitate 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 inSAFe. It is both a Program Team and aManagement Team, but it is not as well-defined as it couldbe. Its responsibilities are relatively well-defined:

• Decide which Epics make it onto the Portfolio Backlog, and determine their Priority,• Produce andMaintain the Portfolio Vision and Investment Themes,• Decompose the Portfolio Backlog into Program Backlogs for theAgile Release Trains, and• Work with the ART’s to Develop andMaintain the Roadmap, Vision, and Release Plans.

SAFe knows, and accepts, that the Program Portfolio Management Team is not well-defined. Asthey put it: “Enterprises may use different titles and roles to fulfill these functions…” They do givesome 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 implementationscenarios that support the business strategy.

In any case, the PPMTeamwill need a Product Owner to beAccountable for theVision, Portfolio,and so on; and this Product Owner will probably need to be an Executive that has the power andinfluence to sponsor the effort.

Evaluating Frameworks 78

Discussion and Comments

There are some very good ideas embodied in SAFe, and the diagram above captures many of themas Patterns. However, there is a lot of documentation about SAFe, and some of it raises issues withme… here are some of the issues I see, given in no particular order:

1. One general issue is that SAFe focuses onArtifacts and Practices, and there is little discussionof Product Ownership. Since the Accountability inherent in Product Ownership is one ofthe major contributions of Scrum, and one of the major foci of the Patterns, I had to makeassumptions about who actually makes the necessaryDecisions and isAccountable for them.

2. The Product Manager is the Product Owner of the ART (the Product Manager prioritizesthe Program Backlog), but the ReleaseManagement Team is the governing authority for theRelease. I have been told that the Release Train Engineer (RTE) usually acts as the ProductOwner of the Release Management Team, but the RTE is the “uber-ScrumMaster” for theART. This is a tangled mess, in my opinion.

3. The Release is central to SAFe. There is Release Planning and a Release BurnDown, but noRelease 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 singleProduct (the ART’s Backlog is called a Program Backlog, and its Product Owner is itssingle Product Manager). So, this implies some Portfolio-level management that I don’tsee described anywhere. And, I suspect, this management also involves the appropriate EpicOwners. 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 Managementfunction that governs the ART? Just askin’…

6. There is a lot of discussion about the possible conflict between the Product Manager and theProduct Owners of theART’sDevelopment Teams. Maybe some discussion of the differencebetween a role (Product Owner) and a position (Product Manager and Team Lead) is inorder?

7. The SAFe documentation says “The ScrumMaster role is well defined in Scrum and theScrum community provides specialty training that can be leveraged cost effectively…” Thisis very true, but the ScrumMaster as described in the SAFe documentation is not the sameScrumMaster that is defined in Scrum and is taught and certified by either Scrum.org or theScrum Alliance.

8. SAFe seems a little predictive and coercive. Here is the beginning of SAFe’s definitionof the ScrumMaster: “The Scrum/Agile Master is a dedicated team member who has aprimary responsibility to help the self-organizing, self-managing team meet its goals andcommitments…” Now, this wouldn’t be a problem if the “commitment” to be met was thecommitment to values and quality, but we also have the quotes “stories and acceptance criteriacommitted to the sprint” and “commitment to PSI/Release objectives for the next PSI timebox”.

Evaluating Frameworks 79

This leadsme 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 theOriginal, coercive and predictive, version of Scrum.

9. SAFe uses the Phrase “Developers & Testers” when referring to the members of a ScrumDevelopment Team. It would be better if it just used the word “Developers” and then definedthat terms to mean everybody you need to do your work, including Coders, Testers, Analysts,Tech Writers, etc…

Anyway, that’s enough.

Book VersionsHere 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 IntroductionX Original ScrumX –Pattern: Well-Formed TeamX –Pattern: Team CoachX –Pattern: Business OwnerX –Pattern: Agile Product DevelopmentX –Original Scrum DiscussionX Modern ScrumX –Pattern: Team LeaderX –Pattern: Subject Matter ExpertsX –Pattern: Definition of DoneX –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, improvedformatting, Evaluation of LeSS and SAFe, and addition of the Book Versions Chapter.

New Improved Chapter Name

X IntroductionOriginal Scrum–Pattern: Well-Formed Team–Pattern: Team Coach

X –Pattern: Business OwnerX –Pattern: Agile Product DevelopmentX –Original Scrum Discussion

Modern ScrumX –Pattern: Team LeaderX –Pattern: Subject Matter ExpertsX –Pattern: Definition of Done

–Pattern: Forecast, don’t Commit (and others)X –Modern Scrum Discussion

X What We Learn from Scrum - the PrinciplesX Scaling PatternsX –Pattern: Generic Development TeamsX –Pattern: Distribution TeamX –Pattern: Consolidation TeamX –Pattern: Program TeamX Patterns for ‘Big’ OrganizationsX –Pattern: Management TeamX –Pattern: Cross-Cutting WOrkgroupX –Pattern: Community of PracticeX –Pattern: Integration and Evaluation (I&E) TeamX Evaluating FrameworksX –Analysis of the LeSS FrameworkX –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 andfurther explanation of what a Project Plan might look like.

New Improved Chapter Name

X IntroductionOriginal Scrum–Pattern: Well-Formed Team

X –Pattern: Team Coach–Pattern: Business Owner

X –Pattern: Agile Product Development–Original Scrum DiscussionModern Scrum–Pattern: Team Leader–Pattern: Subject Matter Experts–Pattern: Definition of Done–Pattern: Forecast, don’t Commit (and others)

X –Modern Scrum DiscussionWhat We Learn from Scrum - the PrinciplesScaling Patterns–Pattern: Generic Development Teams–Pattern: Distribution Team–Pattern: Consolidation Team–Pattern: Program TeamPatterns for ‘Big’ Organizations–Pattern: Management Team–Pattern: Cross-Cutting WOrkgroup–Pattern: Community of Practice–Pattern: Integration and Evaluation (I&E) TeamEvaluating Frameworks–Analysis of the LeSS Framework–Analysis of the Scaled Agile Framework (SAFe)

X Book Versions