Scrum and Patterns share a heritage that goes back centuries. The common foundations of the two — local adaptation, incremental growth, focus on "value," and the central human element — make patterns a particularly viable vehicle for rolling out Scrum. These notes give a short definitive summary of patterns (by example) and pattern languages. Next, they introduce basic Scrum patterns that the Scrum PLoP® effort has gathered over the past five years. After that we look at the "Scrum secrets" — Scrum fundamentals that most practitioners either aren't aware of or which usually go unheeded. Patterns help tease out the tradeoffs ("forces") for these forms in a way that makes them memorable. Last, we give a glimpse of how to use these patterns as a powerful way to evolve your own Scrum implementation to excellence.

1. Secrets of Scrum
Gertrud Bjørnvig & James Coplien
Gertrud & Cope

2. Rainstorm

3. A. The Vision
• Scrum’s inspiration draws on the same spirit as Alexander’s
patterns
• Common ancient roots of patterns and Scrum
• Local adaptation, self-organisation, and piecemeal growth
• Excellence: Kaizen mind and value, the Quality Without a Name
• Long-term stable forms rather than fashion or exigencies
• Making it your own by writing your own patterns

4. The Context
Alfred
Kroeber
1948
1993
1977
2001
2004
Lao
Tzu
500 BC
Ken Schwaber
1993

5. Six years later…

6. Ademar Aguiar
Veli Pekka Eloranta
Mike Beedle
Dina Friis
Gertrud Bjørnvig
Jens Østergaard
Evan Leonard
Ville Reijonen
Neil Harrison
Kiro Harada
Cesário Ramos
Jim Coplien
Jeff Sutherland
Lachlan Heasman
Gabrielle Benefield
Alan O’Callaghan
Joe Yoder

7. A Pattern: STAND-UP MEETING

8. DEVELOPING IN PAIRS
 Software
development is
mistake-prone
 Reviews are
insufficient
Allow, but don’t
force people to
work in pairs

9. Patterns: Time-proven forms
• Tom Gilb: “A term coined by Jim Coplien in 1995.”
• Trygve Reenskaug: “Anne Lise Skaar and I did a large (75000 lines Smalltalk code) project
combining literate programming and pair programming in the middle to late 80ties.”
• Larry Constantine: “My name comes up in connection with pair programming because I taught and
wrote about the practice ("The Benefits of Visibility" Computer Language Magazine 9, 2, 1992)
years before the advent of agile, but I most decidedly did not invent it. I learned about the technique
from P. J. Plauger who used it as a production programming technique at Whitesmiths Ltd., where I
saw it in 1978 or 1979 being used to code C compilers for the PDP-11.”
• Ed Yourdon: “PJ Plauger … was instrumental in persuading me to get UNIX in our company (which
had a $10,000 license fee at the time, a sum of money which Plauger lent the company, interest-free!).
And even the dumb typewriter-like terminals at the time cost about $3,000 -- so we couldn't
afford to get very many of them… Consequently, Plauger told the motley crew of programmers in
our place that they should ‘pair up’ and share the terminals; it simply reflected the fact that
hardware was still more expensive than people.”
• Jerry Weinberg: “I learned to pair program (on paper--we didn't even have terminals back in the
1950s) in Los Angeles, from Bernie Dimsdale, who learned it from John von Neuman. I don't know if
it has any history before then, but that's way back to Aberdeen Proving Grounds in the 40s.”
• Ed Yourdon again: “It's gonna go all the way back to Charles Babbage, or Lady Lovelace!”
• Brian Kernighan: “I have no recollection of any of the history of pair programming, and I certainly
have no involvement with it at all.”

10. What is a pattern language?
• No pattern stands alone
• Patterns refine other patterns
• The basic building blocks come from real practice
— like Scrum, patterns are empirical
• We bring community together to build the
languages
• Patterns are discovered, not invented

11. A
Sequence

12. The notion of Language
• Consider the three sequences:
• A → B → D → C
• A → B → C → D → F
• A → E → F
• Each sequence builds one of a set of related “wholes”
• We can create a shorthand for the three sequences:
• This grammar is called
a pattern language.
Every pattern is part of
a pattern language
A
B
D
E
F
C

13. Product Backlog
Product
Roadmap
Sprint Backlog
Refined Backlog
Vacation PBI
Release Staging
Layers
Release Plan
Release Range
Running Average
Velocity
Fixed-Date PBI
Definition of
Done
Regular Product
Increment
Change for Free
Value Stream
Sprint
Estimation
Points
Daily Clean
Code
Enabling
Specifications
Money for
Nothing
Product Backlog
Items
Aggregate
Velocity
Granularity
Gradient
ROI
Definition of
Ready
Small Items to
Estimate
High Value First

14. B. Some Basic Scrum
Patterns

15. STABLE TEAMS
• Stakeholders want to know when the
product is estimated to be delivered, so
we want to optimize our ability to predict.
• Therefore,
• Keep teams stable and avoid shuffling
people around between teams. Stable
teams tend to get to know their capacity,
which makes it possible for the business
to have some predictability. Team
members should be dedicated to a single
team whenever possible.

16. CROSS-FUNCTIONAL
TEAM
• Organizations often organize
around areas of competence:
birds of a feather flock
together. Yet, it is costly to
coordinate these functions
across team boundaries.
• Therefore: Teams should
comprise all talent necessary
to deliver Done functionality.

17. G&C
FIREWALLS
…an organization of developers has formed in a corporate or social
context where they are scrutinized by peers, funders, customers, and
other “outsiders.” Project implementors 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.”

18. ENABLING SPECIFICATION
• Unexplored requirements cause unpleasant
surprises.
• It's easy to throw requirements over the wall and say:
"That requirement was covered." It's even easier in
Scrum. Their user stories are enough. And the Agile
culture encourages deferring decisions and a ready,
at-hand on-site customer who can compensate for
requirements lapses during development.
• Therefore: The Product Owner should deliver
enabling specifications as a sign that he or she
has done due diligence in exploring the
requirements space. "Enabling specification" means
that the specification is rich enough that someone
reasonably skilled in the discipline can implement a
solution without substantial subsequent clarification.
Scrum secret:
There are no
User Stories in
Scrum, and it’s
not about writing!

19. DEFINITION OF READY

20. EMERGENCY PROCEDURE
• Scrum strives to master
uncertainty in a complex
environment. Bad things can
happen
• Therefore: Escalate quickly to the
point of “stopping the line,” to
assess status quo before moving
forward

21. EMERGENCY PROCEDURE
Context:
Companies, teams, and individuals often find their efforts failing to deliver
on time and the Sprint burndown shows that failure is virtually certain.
Rapid identification of problems and quick response is fundamental to the
spirit of agility. Causes of Sprint dysfunction are legion and their patterns
is primarily focused on 1-3 below:
1. Emergent requirements
2. Technical problems
3. Loss of critical people or capabilities
4. Overestimated capacity (use YESTERDAY’S WEATHER)
5. Unplanned interrupts (use ILLEGITIMUS NON INTERRUPTUS)
6. Previous work not done (use DEFINITION OF DONE)
7. Product owner changes backlog (use PRODUCT OWNER)
8. Management interference (use INVOLVE THE MANAGERS)

22. EMERGENCY PROCEDURE
• Emergency Procedure: (do only as much as necessary)
1. Change the way the work is done. Do something
different.
2. Get help, usually by offloading backlog to someone
else.
3. Reduce scope
4. Abort the sprint and replan
5. Inform management how release dates will be affected

23. YESTERDAY’S WEATHER
• Guessing when you will be done with a
complex task is always a dicey
proposition
• Yet complex stochastic processes have
norms that are dependable, on the
average
• Therefore: Use the last Sprint, or the
trend of the most recent Sprints, to
determine how much work to take into
the next one.

24. C. Some Scrum
Secrets

25. SPIRIT OF THE GAME
• Rules can be written, but spirit is part of culture that guides
interactions and may only be discerned when ignored or
violated
• “We can give examples that are not in contradiction with the
Scrum Guide (Sutherland & Schwaber, 2012) but neither are
they in the spirit of the Agile Manifesto and its 16 principles.
As Scrum is under the umbrella of these values we see how
these examples break at least one principle. "Build projects
around motivated individuals. Give them the environment and
support they need, and trust them to get the job done."
• Therefore:
• When using Scrum there needs to be a focus on explicitly
creating a culture in the organization where people know and
follow the spirit of Scrum.

26. DEVELOPER-ORDERED WORKPLAN
Scrum secret:
The heart of
self-organisation!
• Therefore: Let the team self-organise to best
optimise the chances of meeting the Sprint Goal

27. DAILY SCRUM?
• What’s it for?
Scrum Secret: The
purpose of the Daily
Scrum is to re-plan
the Sprint every day.

28. Exercise

29. SWARMING
• Working on too many things at once leads to radical
reduction in the velocity of an individual, a team, or
a company. It can cut velocity by 50% and
sometimes reduce it to zero.
• Therefore:
• Focus maximum team effort on one item in the
Sprint Backlog and get it done as soon as possible.
Whoever takes this item is Captain of the team.
Everyone must help the Captain if they can and no
one can interrupt the Captain. As soon as the
Captain is Done, whoever takes responsibility for
the next priority backlog item is Captain.

30. Scrum Team: One mind
• No testers
• No DB people
• No coders
• No HCI people
• … ideally.
• Minimize coordination between teams!

31. HAPPINESS METRIC
• In reflection and other self-improvement
activities, there are generally many
ideas for improvement. But you often
don’t know in advance which
improvement activities will produce great
benefits, and which will not.
• Therefore:
• Find out what one improvement will
increase the happiness of the team the
most, and implement that improvement
in the next Sprint.

32. SCRUMMING THE SCRUM
• Identify the single most important impediment at
the Sprint Retrospective and remove it before the
end of the next Sprint.

33. WHACK THE MOLE
• Bugs can appear at any time
• Zero defect tolerance says you
need to fix them eventually.
They get in your way until you fix
them
• Therefore: Fix bugs when they
arise!

34. DEPENDENCIES FIRST
• The team orders the Sprint Backlog to reflect
known dependencies at the beginning of
the Sprint, but the variance in the effort
necessary to realize PBI delivery, and to re-plan
due to Emergent Requirements, can
push dependency resolution too late in
the Sprint and can thereby increase the risk
that the dependency will cause PBIs to be
inadvertently dropped.
• Therefore:
• Make sure that all foreseen dependencies are
in-hand by mid-Sprint; otherwise, abort
the Sprint.

35. ILLEGITIMUS NON
INTERRUPTUS
• 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.
1. The team creates a buffer for unexpected items based on historical data.
For example, 30% of the team's work on the average is caused by
unplanned work coming into the Sprint unexpectedly. If the team velocity
averages 60 points, 20 points will be reserved for the interrupt buffer.
2. All requests must go through the Product Owner for triage. The Product
Owner will give some items low priority if there is no perceived value
relative to the business plan. Many other items will be pushed to
subsequent Sprints even if they have immediate value. A few items are
critical and must be done in the current Sprint, so they are put into the
interrupt buffer by the Product Owner.
3. If the buffer starts to overflow, i.e. the Product Owner puts one point more
than 20 points into the Sprint, the team must automatically abort,
the Sprint must be re-planned, and management is notified that dates will
slip.

36. A Scrum Secret
• Kaizen mind is tough love!

37. Exercise!

38. "おやつ神社" Oyatsu Jinja (Snack
Shrine)
• The Team finds itself supporting occasional
interruptions from the Product Owner, other
teams, and other stakeholders, who need
their attention. Yet the team should be
focused during a Sprint
• Therefore: Put some snacks near the team,
where visitors can wait. The team can attend
to the diversion according to priority and
work load
• Creates “ba” rather than just a chance
encounter (like WATER COOLER)

39. TEAMS THAT FINISH EARLY
ACCELERATE FASTER
• Teams often take too much work into a sprint and cannot
finish it. Failure prevents the team from improving.
• Teams can be optimistic about their ability to finish
requested features. But in doing so, they fail to give
themselves time to reduce technical debt and sharpen
their saws. Thus they are doomed to a persistently slow
pace.
• Therefore:
• Take less work into a sprint.
• Maximize your probability of success by using the pattern
YESTERDAY’S WEATHER. Then implement ILLEGITIMUS NON
INTERRUPTUS which will systematically deal with any
interruptions cause you to finish early.

40. Jeff’s Secret Sauce for
Hyperproductivity
• How do you get started? (STABLE TEAMS)
• How do you successfully pull backlog items into a Sprint? (YESTERDAY'S WEATHER)
• How do you get stuff done? (SWARMING: ONE-PIECE CONTINUOUS FLOW)
• How do you deal with interruptions during the Sprint? (ILLEGITIMUS NON INTERRUPTUS)
• How do get defect free at the end of the Sprint? (DAILY CLEAN CODE)
• How do you deal with surprises? (EMERGENCY PROCEDURE)
• How do you ensure you continuously improve? (SCRUMMING THE SCRUM)
• How do you get teams to have fun? (HAPPINESS METRIC)
• How do you get hyperproductive? (TEAMS THAT FINISH EARLY ACCELERATE FASTER)

41. This is a Pattern Language!
• The patterns work together
• They form a “whole”

42. D. Do this at home

43. Doing patterns at home
• Understanding the patterns foundations leads to a deeper appreciation for
Scrum principles
• Try this:
1. A short introduction to patterns
2. Read the Scrum patterns
3. Come together once a month in community to review each others’ Scrum
patterns
4. Use it for your retrospective once in a while
5. Introduce the patterns (see next slide)
6. Get involved in the broader community

44. Introduce the patterns
• The Fundamental Process:
1. Find the weakest place in your organisation
2. Find a pattern that can repair, or strengthen, that
weakness — every pattern is an act of repair
3. Try the pattern
4. Measure its effectiveness with mind and heart
5. If the system is less Whole, try another pattern

45. Measure its effectiveness
with mind and heart
• There’s something deep going on here
• Alexander calls it “The Quality Without a Name” or
“Wholeness”
• Neil and I could “feel it” in the great organisations
we studied, and learned to recognise it in the
geometry of the organisations.
• Both developing a sense for this geometry, and
achieving the geometry, are career-long journeys

46. Exercise
• Write your OWN Scrum Pattern!
• Good organisations grow their own Pattern
Language

47. References
• The ScrumPLoP site: http://www.scrumplop.org.
• The Original Organizational Patterns, http://orgpatterns.wikispaces.com.
• Scrum as based on those patterns, http://www.scrumorgpatterns.com.
• Coplien &Harrison, Organizational Patterns of Agile Software Development, Prentice-Hall, 2004.
• Alexander, A Pattern Language, Oxford, 1977.
• Alexander, The Timeless Way of Building, 1979.
• Beedle and Schwaber, Agile Software Development with Scrum, Addison-Wesley, Reading, MA,
2001.
• Brendan G. Cain and James O. Coplien. A Role-Based Empirical Process Modeling Environment.
In Proceedings of Second International Conference on the Software Process (ICSP-2), pages
125-133, February 1993. Los Alamitos, California, IEEE Computer Press.
• Kroeber, Alfred. Culture, patterns and processes. New York: Harcourt, Brace and World, 1963
(1948).