HC SVNT DRACONES*

*here be dragons scaling agile

 3
Versioni sed
v

o
t R e
ely ed
m p l e

D tter
Co Updat
&

e
B um
S c r i ps a n d in s i
w
g h ts
ell
t of t c ru m
s e t S
o ffi cial plemen
n
An u ow to im erma
rk
h nd
into
rH u
ne r Pete
i
& Tra h
um Coac
e d Scr
yC ertifi
Written b

ens e
u mS
Scr

peter hundermark
!peterhundermark
 frame

1. why do we scale?
2. laws of scaling
3. scaling patterns
4. digestion and feedback
1. why do 

we scale?
 survey
turn to your neighbour:
๏ how many people in your organisation are currently
involved in a scaled agile product development or
project delivery effort?
๏ how successful have your scaling efforts been so
far?
prepare for a call-out in 2 mins
 successes?

better outcomes
??
worse outcomes

fewer people more people

a) big product
we are building and sustaining
a product that needs 

more than 9 people
b) portfolio of products

we are building and

sustaining a portfolio of
products and projects
that involves many people
 m
c) many customer projects
le
r o b
we have lots of customer p
i n g <projects>

c a l
that do not each need a full-sized team

a s
o t just put them all
n into one backlog!
 d) multiple locations
l e m
r o b
g p
l in
a
we have a distributed team

s c
o t a this is a
n communication
problem!
2. laws of scaling
 1st law of scaling

do not scale!
 2nd law of scaling

when you scale, 


you scale everything—
the good and the bad1
1 courtesy marius de beer
 3rd law of scaling

the only way to go

fast is to go well2

2 uncle
bob martin

http://programmer.97things.oreilly.com/wiki/index.php/Speed_Kills
3. scaling patterns
 conway's law
Organizations which design systems are
constrained to produce designs which are
copies of the communication structures
of these organizations
 larman's laws
1. organizations are implicitly optimized to avoid
changing the status quo...positions and power
structures
2. as a corollary to (1), any change initiative will be
reduced to redefining or overloading the new
terminology to mean basically the same as status quo
3. as a corollary to (1), any change initiative will be
derided as purist, theoretical...which defects from
addressing weaknesses...
4. culture follows structure
http://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior
scaling anti-patterns?
SAFe
DAD
other snake oil...

Rather consider:
LeSS (Larman and Vodde)
ScALeD (scaledprinciples.org)
Enterprise Transition Framework
(agile42)
10 scaling
patterns
that work
(for me)
1) feature teams

minimise cross-dependency between teams

therefore—
form long-lived feature teams rather than component
teams. ensure each team is cross-functional

This requires organisational restructure!

2) one backlog

shorten queuing times for the waiting work

therefore—
feed multiple, synchronised teams from a single backlog
managed by an empowered product owner/manager
3) synchronised sprints

exploit scale economies of multiple

teams
therefore—
synchronise sprints for multiple
teams. use joint planning and
reviews
4) fast feedback
keep feedback loops short
therefore—
ensure all teams' outputs are tested and integrated
into the increment every sprint. work to eliminate
constructs like 'integration' or 'hardening' sprints
5) slack

retain slack to achieve flow

therefore—
allow teams to pull from the backlog, based on their
observed capacity. challenge teams to finish early
6) no silos

reduce skill silos and

dependencies within teams
therefore—
use osmotic communication
and pairing to grow
empathetic T-shaped people
7) optimise
the whole
optimise your entire portfolio
therefore—
visualise and manage your product and project
portfolio. measure outcomes at the highest possible
level and let teams seek on their own local solutions

Try using Portfolio Kanban

http://www.klausleopold.com/2013/07/kanban-and-its-flight-levels.html
8) quality
pay attention to quality
therefore—
ensure 'technical debt' is reducing, not increasing.
fix errors as soon as they are found
9) communication

pay attention to communication

therefore—
institute formal meetings to synchronise teams

SoS is NOT a meeting

of Scrum Masters!
10) learning

pay attention to learning

therefore—
form communities of practice for different
disciplines to share learning. hold large group
retrospectives on a longer cadence (e.g. for releases).
read books. get professional help
ten scaling patterns
1) feature teams 6) no silos

2) one backlog 7) optimise the whole

3) synchronised sprints 8) quality

4) fast feedback 9) communication

5) slack
 10)learning
4. digestion and feedback

๏ what resonates with me?

๏ what could I apply? 7'
digest input in small groups
each group provides two sentences of feedback
 takeaways
➡ be clear what you are scaling and why
➡ the only way to go fast is to go well
➡ don't be lured by scaling snake oil
➡ understand and apply the 10 scaling patterns
➡ read some books
➡ get professional help
gerald weinberg's second law of consulting:

no matter how it looks at first, it's

always a people problem
 selected references
Ambler, Scott M. and Lines, Mark (2012). Disciplined Agile Delivery: A Practitioners’ Guide to Agile Software Delivery in the Enterprise. IBM Press.

Anderson, David J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.

Conway, Melvin (1968). Conway’s Law. http://www.melconway.com/Home/Conways_Law.html.

Coplien, James O. and Harrison, Neil B. (2005). Organisational Patterns of Agile Software Development. Pearson Prentice Hall.

De Beer, Marius (2012). Data-driven Agility: An analysis of Agile adoption in North American Organisations. http://www.scrumsense.com/downloads/data-driven-agility.pdf.

DeMarco, Tom (2001). Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Dorset House Publishing.

Hackman, J. Richard (2002). Leading Teams. Harvard Business School Press.

Hackman, J. Richard (2011). Collaborative Intelligence. Berrett-Koehler.

Hundermark, Peter (2014). Do Better Scrum (Version 3). http://www.scrumsense.com/resources/do-better-scrum/

Kniberg, Henrik (2008). Multi-Team Sprint Planning. http://www.scrumalliance.org/system/resource_files/0000/0871/Multi-Team-Sprint-Planning.pdf.

Kniberg, Henrik and Ivarsson, Anders (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify.

Kniberg, Henrik (2014). Spotify Engineering Culture (Part 1 of 2). http://vimeo.com/85490944.

Kniberg, Henrik (2014). Spotify Engineering Culture (Part 2 of 2). http://vimeo.com/94950270.

Larman, Craig and Vodde, Bas (2008). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley Professional.

Larman, Craig and Vodde, Bas (2010). Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley Professional.

Larman, Craig (2013). Larman’s Laws of Organizational Behavior. http://www.craiglarman.com/wiki/index.php?title=Larman's_Laws_of_Organizational_Behavior

Larsen, Diana (2004). Team Agility: Exploring Self-Organizing Software Development Teams. http://www.futureworksconsulting.com/resources/TeamAgilityAgileTimesFeb04.pdf.

Leffingwell, Dean (2013). Scaled Agile Framework. http://scaledagileframework.com/.

Manns, Mary Lynn and Rising, Linda (2004). Fearless Change: Patterns for Introducing New Ideas. Addison Wesley.

Reinertsen, Donald G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.

Rothman, Johanna (2009). Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Pragmatic Programmers.

Schein, Edgar H. (2010). Organisational Culture and Leadership. Fourth Edition. Jossey-Bass.

Spielhofer, Thomas (2014). More than LeSS. http://www.infoq.com/articles/more-than-less.

Tabaka, Jean (2006). Collaboration Explained | Facilitation Skills for Software Project Leaders. Addison-Wesley Professional.

Weisbord, Marvin; Janoff, Sandra (2007). Don’t Just Do Something, Stand There! Ten Principles for Leading Meetings that Matter. Berrett-Koehler Publishers.
 the end
!peterhundermark
#sgza

www.scrumsense.com