1. Patterns of Scrum: Keys to Understanding Effective Scrum-ming
Neil B. Harrison
Utah Valley University

2. TalkMap Who What we are doing Why Main Course (the patterns)
And a bit of history
What we are doing
Creating a pattern language of Scrum
A few words about what patterns are …
Why
Why 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

3. Cast of Characters Jeff Sutherland
Jim Coplien – Organizational Pattern author, co- controller of Scrum Guide
Mike Beedle – Early co-developer of Scrum
Neil Harrison – Organizational Pattern author
Ademar Aguiar, Gabrielle Benefield, Gertrude Bjørnvig, Veli-Pekka Eloranta, Dina Friis, Dan Greening, Kiro Harada, Lachlan Heesman, Ville Mäkinen, Jens Østergaard

4. A Bit of History Working together for over two years
Regular face-to-face workshops
Lots of Skype, Google docs, , etc.
Organizational Patterns
Early organizational foundation of Scrum
Collected chiefly by Coplien and Harrison
Form the model for the Scrum patterns

5. A Few Words About Patterns…
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 system
A contributor to the quality of life
A Scrum/Organizational Pattern
Changes communication paths
Changes organizational culture

6. Solving Problems Patterns are not rules to be blindly followed
Patterns solve problems at the deep, systemic level
Patterns explore:
The nature of the problem
The forces that interact that effect the problem (make it hard)
The solution:
Why it works
Under what conditions it works
The resulting context

7. Why Do we Need Scrum Patterns?
Scrum is:
Lightweight
Simple to Understand
Extremely difficult to master
- Scrum Guide, p. 3

8. Simple to Understand …

9. Extremely Difficult to Master
Many teams do Scrum poorly
Or say they are doing Scrum, but aren’t
A (small) sample of war stories
Insanity in Sprints
Scrum Master as Thor’s Hammer
The Scrum Master in the Candy Store
A Fool with a Tool
One reason:
They follow the steps, but don’t know why
Understanding the Why is crucial

10. The Scrum Patterns Project
Identify the patterns of successful Scrum teams
Organize them into pattern languages
Will be published (goal: draft next Spring)
So far:
About 160 patterns identified
Drafts of many have been written
Over 50 workshopped (reviewed) and revised

11. Pattern Languages (so far)
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)

12. Organization Pattern Foundation
Patterns that form the organizational basis for Scrum
Many
Three examples follow
Note how they highlight the “why” …
Note:
The patterns are very abbreviated, which removes some of the “whys” 

13. Work Flows Inward
... 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. ...
Problem
Problem Insight
The “Why”

14. Stand-Up Meeting
Insight: it’s not just about making assignments

15. Firewalls A Key role for the Scrum Master
…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.”
Insights (forces) that show inherent conflict

16. Scrum Master Patterns It’s not just running the meetings!
Patterns identified so far:
ScrumMaster
Catalyst
Cheerleader
Coach
DoneMaster
Firewall
Knight of the Mirrors
Sheepdog
Product Owner Trainer

17. Hyperproductive Teams?
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)

18. Stable Teams Insight: a temptation, with consequences explained
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 …
Insight: a temptation, with consequences explained

19. Daily Clean Code From Jeff:
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.
From Jeff:
Use of this pattern has resulted in a doubling of productivity

20. Illigitimus Non Interruptus
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.

21. Scrumming the Scrum
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.

22. Participation 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)
(Jim Coplien)

23. Authors Scrum Diagram: Work Flows Inward, Stand Up Meeting, Firewalls:
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: