Neil B. Harrison

Utah Valley University

Patterns of Scrum:Keys to Understanding Effective Scrum-ming

WhoAnd a bit of history

What we are doingCreating a pattern language of ScrumA few words about what patterns are …

WhyWhy is the pattern language so important

Main Course (the patterns)Some key Scrum patterns so far

What next, when, etc.And how you can be involved

TalkMap

Jeff SutherlandJim Coplien – Organizational Pattern author,

co-controller of Scrum GuideMike Beedle – Early co-developer of ScrumNeil Harrison – Organizational Pattern

authorAdemar Aguiar, Gabrielle Benefield,

Gertrude Bjørnvig, Veli-Pekka Eloranta, Dina Friis, Dan Greening, Kiro Harada, Lachlan Heesman, Ville Mäkinen, Jens Østergaard

Cast of Characters

Working together for over two yearsRegular face-to-face workshopsLots of Skype, Google docs, email, etc.

Organizational PatternsEarly organizational foundation of Scrum1993-2004Collected chiefly by Coplien and HarrisonForm the model for the Scrum patterns

A Bit of History

What are Patterns?23 Rules for Object-Oriented Design, Right?Um, no

A Pattern Is:Something you build (and instructions how to

build it)A solution to a small problem of a complex

systemA contributor to the quality of lifeA Scrum/Organizational Pattern

Changes communication pathsChanges organizational culture

A Few Words About Patterns…

Patterns are not rules to be blindly followedPatterns solve problems at the deep, systemic

levelPatterns explore:

The nature of the problemThe forces that interact that effect the problem

(make it hard)The solution:

Why it worksUnder what conditions it works

The resulting context

Solving Problems

Scrum is:LightweightSimple to UnderstandExtremely difficult to master

- Scrum Guide, p. 3

Why Do we Need Scrum Patterns?

Simple to Understand …

Many teams do Scrum poorlyOr say they are doing Scrum, but aren’t

A (small) sample of war storiesInsanity in SprintsScrum Master as Thor’s HammerThe Scrum Master in the Candy StoreA Fool with a Tool

One reason:They follow the steps, but don’t know whyUnderstanding the Why is crucial

Extremely Difficult to Master

Identify the patterns of successful Scrum teams

Organize them into pattern languagesWill be published (goal: draft next Spring)

So far:About 160 patterns identifiedDrafts of many have been writtenOver 50 workshopped (reviewed) and revised

The Scrum Patterns Project

Value Stream Managing the value stream, including estimation, backlog, release

planning, etc. Process Improvement/Retrospective

How to improve, including reviews and retrospective patterns Team

How the team is organized and works together. There is a Scrum Master sub-language

Product Organization Especially Product Owner patterns

Scaling Scrum Distributed Scrum Change Management

Changing from a traditional to a Scrum organization Scrum Core

Basic Scrum knowledge (status uncertain)

Pattern Languages (so far)

Patterns that form the organizational basis for Scrum

ManyThree examples follow

Note how they highlight the “why” …

Organization Pattern Foundation

Note:The patterns are very abbreviated, which removes some of the “whys”

... an organization is in place and has been doing work long enough that it can introspect about its structure and workings. ...

* * *An organization must seek a structure that best insures that the most authoritative roles make the decisions and carry out the work that adds value directly to the product. ...During software production, the work bottleneck of a system should be at the center of its communication and control structure. If the communication center of the organization generates more work than it does work, then organization performance can become unpredictable and sporadic...

Therefore: Work should be generated by stakeholders, especially Customers, filter through supporting roles, and be carried out by implementation experts at the center.

You should not put managers at the center of the communication grid: they will become overloaded and make decisions that are less well-considered, and they will make decisions that do not take day-to-day dynamics into account. ...

Work Flows Inward

Problem

Problem Insight

The “Why”

Stand-Up MeetingInsight: it’s not just about making assignments

…an organization of developers has formed in a corporate or social context where they are scrutinized by peers, funders, customers, and other “outsiders.” Project implementers are often distracted by outsiders who feel a need to offer input and criticism.

* * *It’s important to placate stakeholders who feel a need to “help” by having access to low levels of the project, without distracting developers and others who are moving toward project completion. ...Isolationism doesn’t work: information flow is important. But communication overhead goes up non-linearly with the number of external collaborators.Many interruptions are noise.Maturity and progress are more highly correlated with being in control than being effectively controlled.Therefore:Create a MANAGER ROLE, who shields other development personnel from interaction with external roles. The responsibility of this role is “to keep the pests away.”

Firewalls A Key role for the Scrum Master

Insights (forces) that show inherent conflict

It’s not just running the meetings!Patterns identified so far:

ScrumMasterCatalystCheerleaderCoachDoneMasterFirewallKnight of the MirrorsSheepdogProduct Owner Trainer

Scrum Master Patterns

Jeff Sutherland is putting together a small pattern language that captures the essence of a hyperproductive team: How do you get started? (Stable team) How do you successfully pull the backlog into a sprint? (Yesterday’s

Weather) How do you get stuff done? (Get Something Done) How do you deal with interruptions during the sprint? (Illigitimus

non Interruptus) How do get defect free at the end of the sprint? (Daily Clean Code) How do you ensure you continuously improve? (Scrumming the

Scrum) How do you get teams to have fun? (Happiness Metric) How do you become hyperproductive? (Teams that Finish Early

Accelerate Faster)

Hyperproductive Teams?

In order to run a business based on software development we need some level of predictability. With everything in flux we may decide to “fix” the wrong thing to have this predictability …

Predictability and productivity are two mantras in software development. Manage by numbers, a third mantra, is used to support the first two. To optimize productivity and predictability we create the numbers to manage – estimates for tasks, resources allocated to projects to maximize utilization and project plans to schedule the estimates …

Having good estimates and a strong project manager ensures predictability …

Resource utilization leads to multi-tasking with people distributed across several teams. But the numbers, this is a good result … but will lead to difficulties for the individual who must context switch between teams …

Therefore:

Keep teams stable and avoid shuffling people between teams. Stable teams get to know their capacity, which makes it possible for the business to have some predictability. …

Stable teams get to know each other … When the team knows its capacity it can improve … the only way that a team can get to know their velocity is by being the same team members over a longer period of time …

Stable teams create pressure on the pipeline of work. Work will now need to be structured to fit with the teams, rather than teams structured to fit with – or crises. This will, in turn, highlight capability issues that occur within the organization …

Stable Teams

Insight: a temptation, with consequences explained

As a team develops the product, bugs are invariably detected. The usual tendency is to write bug reports and put them on a bug list, where they will be fixed at the appropriate time. But this leads to several problems which cause the velocity of the team to bog down.

           ✥ ✥ ✥

Velocity is limited because a team spends time dealing with too many bugs.

It is natural to want to keep a list of bugs. But keeping a bug list causes numerous problems:

Each bug has to be handled at least twice, once when it arrives, and later when it is fixed.

The longer a bug sits before it is fixed, the greater chance there is of losing information about the bug, how to reproduce it, and how to fix it.

Bug lists tend to grow. If they get large, the lowest priority bugs will never get fixed.

Therefore:

Fix all bugs in less than a day. Have a completely clean base of code at the end of every day.

It reduces the overhead of handling bugs.

It eliminates two separate lists of work to do, making it easier for the team to focus.

It keeps the code clean. Developers won’t be basing code on top of bugs.

It eliminates the need for the periodic “bugathon” or “bug bash”, where the team stops what they are doing to spend time cleaning up the code.

DAILY CLEAN CODE

From Jeff:Use of this pattern has resulted in a doubling of productivity

Scrum teams are often interrupted during a sprint by changing priorities or problems.

The Scrum team is a critical resource for creating new software and maintaining old software. This makes them a central resource to serve the needs of everyone in the company.

Often poor product ownership allows competing priorities in a company to reach a Scrum team. Some teams have even been bribed to work on features not in the companies product backlog.

Therefore:

Allot time for interrupts and do not allow the time to be exceeded.

Set up three simple rules that will cause the company to self-organize to avoid disrupting production.

The team creates a buffer for unexpected items based on historical data.

 All requests must go through the Product Owner for triage.

 If the buffer starts to overflow, the team must abort, and management is notified that dates will slip.

These rules will invariably cause individuals to self-organize to avoid blowing up a sprint as no individual wants to be seen as the direct cause of sprint failure.

Even better, the buffer will tend to never be full, allowing the team to finish early and pull forward from the backlog and/or work on removing impediments. See: Teams That Finish Early, Accelerate Faster.

Counter-intuitively, this does not cause critical problems to be hidden or unresolved, The product owner will put any critical items on the backlog. The team will typically double velocity and get twice as much done in future sprints.

ILLIGITIMUS NON INTERRUPTUS

Only a small minority of Scrum teams achieve the hyperproductive state. This is because most teams fail to identify and remove impediments. Their software is not done, their backlog is not ready, and the team does not self-organize to improve performance.Therefore:Identify the single most important impediment at the Sprint Retrospective and remove it before the end of the next sprint. To remove it, put it in the Sprint backlog as a user story with acceptance tests that will determine when it is done. Then evaluate the state of the story in the Sprint Review like any other task.Focusing attention on the top priority impediment will have the side effect that the team will self-organize to remove other high priority impediments as well, without losing focus on the highest priority impediment.This pattern assures continuously increasing velocity or sustainable high-level velocity …Hugo Heitz: “They need to put the kaizen in the backlog. They need to Scrum the Scrum. They need to use Scrum to make Scrum better.”Removing the top priority impediment should yield immediate velocity improvement. If not, the team has not properly analyzed system dynamics and understood the root cause of the primary dysfunction.

Scrumming the Scrum

www.scrumplop.org(click on “Pattern Spreadsheet”)

Feel free to give comments, even on so-called published patterns.

Do you have patterns you want to write? Do you want to participate in reviewing

patterns, or attending ScrumTulipPLoP?Contact us:

neil.harrison@uvu.edu (Neil Harrison)jcoplien@gmail.com (Jim Coplien)

Participation

Scrum Diagram: Mike Cohn, Mountain Goat Software

Work Flows Inward, Stand Up Meeting, Firewalls: Jim Coplien and Neil Harrison

Stable Teams:Gertrude Bjørnvig and Lachlan Heasman

Daily Clean Code: Jeff Sutherland and Neil Harrison

Illigitimus non Interruptus: Jeff Sutherland

Scrumming the Scrum: Jeff Sutherland

Authors