Pacific Express - Alex Yakyma - Scaled Agile
Pacific Express - Alex Yakyma - Scaled Agile
Pacific Express - Alex Yakyma - Scaled Agile
Yakyma
PACIFIC
EXPRESS
Alex
Yakyma
is
a
methodologist,
trainer,
and
consultant
who
has
been
applying
Lean
and
Agile
practices
in
the
software
industry
for
over
a
decade.
Alex
joined
Dean
Leffingwell
in
2006
and
since
then
has
been
actively
working
on
Scaled
Agile
Framework
and
its
numerous
implementations
in
the
field.
Alexs
broad
prior
experience
as
a
program
manager
in
highly
distributed,
multi-cultural
environments
allows
him
to
perfect
his
clients
operational
capabilities
at
the
program
level,
cross
program
coordination,
and
portfolio
strategy.
Contact
Alex
at
alex.yakyma@scaledagile.com
Follow
on
Twitter:
http://twitter.com/AlexYakyma
ISBN
978-1-4951-2790-8
Building
really
big
software
systems
is
one
of
the
most
challenging
intellectual
endeavors
facing
todays
businesses.
To
help
address
this
challenge,
weve
created
the
Scaled
Agile
Framework,
(SAFe),
a
knowledge
base
of
proven
best
practices
that
you
can
use
to
help
bring
the
benefits
of
Lean
and
Agile
development
to
your
business,
and
also
better
the
livesnot
just
of
the
users
for
whom
we
build
these
systemsbut
also
of
the
millions
of
software
practitioners
who
create
them.
We
do
this,
most
simply,
because
better
software
makes
the
world
a
better
place.
That
scales.
To
accomplish
this,
SAFe
is
based
on
three
primary
knowledge
pools,
Lean,
Systems
Thinking
and
Agile
development.
These
values
and
principles
power
SAFe
and
provide
the
bedrock
that
make
it
safe
and
effective.
SAFe
is
freely-revealed
and
publicly-facing,
so
that
you
can
begin
to
apply
it
immediately
in
your
business
context.
Freely
revealed-yes,
magic-no.
Implementing
SAFe
is
hard
work.
New
values,
new
ways
of
working,
and
a
willingness
to
engage
and
fully
empower
the
people
who
do
this
important
work
are
all
required.
And
there
is
no
hidden,
or
proprietary,
secret
sauce
that
unlocks
the
magic.
If
there
is
any
magic
to
be
found,
it
comes
from
the
hearts
and
minds
of
those
dedicated
people
for
whom
the
status
quo
is
not
ok;
those
who
face
the
burden
of
change,
some
positively,
some
negatively.
SAFe
is
a
documented
system,
but
it
is
people
who
do
the
work.
To
that
end,
Alex,
has
put
together
this
work
of
semi-fiction,
focused
on
one
key
element
of
SAFe,
the
Agile
Release
Train.
Semi-fiction
because
the
business
and
characters
are
fictional,
but
the
challenges,
vignettes,
opinions
and
behaviors
expressed
were
real.
His
goal
is
to
help
you
understand
SAFe,
inside
out,
from
the
standpoint
of
the
people
doing
the
work.
He
has
chosen
this
novella
as
an
experiment
to
see
if
we
can
better
communicate
why
and
how
it
works.
So
lets
leave
the
SAFe
website,
with
its
practices,
figures,
artifacts,
activities
and
references,
and
enter
this
fictional
world,
even
if
just
for
an
hour
or
two.
Lets
see
if
we
can
find
an
even
better
understanding
of
why
SAFe
works
the
way
it
does,
and
perhaps
find
a
little
fictional
enjoyment
in
the
process.
I
know
I
did,
and
I
expect
you
will
too.
A
hundred
and
ten
approximately.
All
full
time.
This
program
grew
rapidly
during
the
last
year
from
some
forty
people
to
almost
three
times
that
size.
I
wish
our
processes
were
evolving
along
with
our
growth,
but
sometimes
it
seems
to
me
that
we
are
only
getting
worse
and
worse.
The
lady
in
the
gray
elegant
suit
put
some
numbers
on
the
whiteboard
and
paused
for
a
few
moments.
A
lot
depends
on
these
people,
she
gestured
to
the
board,
and
yet
this
program
is
like
a
black
hole
requirements
are
fed
in
but
nothing
gets
out.
Our
key
stakeholders
are
becoming
impatient
especially
because
she
got
stuck
for
a
few
more
moments,
perhaps
struggling
to
frame
her
statement,
because
we
are
Agile
at
least
so
we
advertise.
Some
people
in
the
room
grimaced
at
these
words,
others
smiled
and
some
chose
not
to
burden
themselves
with
any
reaction
just
yet,
probably
anticipating
more
fun
to
come.
Even
though
I
dont
particularly
enjoy
other
peoples
awkward
moments,
these
can
actually
be
quite
useful
they
tell
you
what
your
customer
really
feels
more
accurately
than
a
thousands
words.
For
a
consultant
paying
attention
to
such
things
is
absolutely
vital.
We
just
got
started
and
things
are
already
popping
up.
Stephanie
seems
to
be
straightforward
enough
thats
going
to
make
this
easier
for
all
of
us.
Whether
its
increasing
executive
pressure
shes
under
(it
was
noticeable
even
during
our
first
phone
call)
or
just
her
personality,
I
think
I
like
the
direction
this
is
heading.
She
doesnt
seem
to
be
overly
invested
in
their
current
methods
and
tools
either.
Maybe
shes
just
one
of
those
heads
of
PMO
that
are
deeply
critical
about
the
results,
despite
all
the
politics
and
organizational
inertia.
So
far,
so
good,
but
I
need
more
detail:
And
could
you
please
describe
in
more
detail
what
exactly
Agile
means
to
your
teams?
We
work
in
Sprints,
we
use
story
points,
we
do
all
that
Sprint
planning
stuff
We
just
dont
get
anything
out
of
it
in
the
end,
a
gentleman
that
was
sitting
the
furthest
from
the
whiteboard
interjected.
Ryan,
this
is
Josh,
one
of
the
product
managers
working
with
this
program,
said
Stephanie
apologetically.
We
used
to
call
this
role
business
analyst
but
with
the
adoption
of
Agile,
we
decided
to
make
a
switch,
because
she
rolled
her
eyes
desperately
trying
to
remember,
Well,
I
guess
nobody
remembers
exactly
why.
Meanwhile,
Josh
went
on
While
I
told
you
what
is
happening
process-wise,
I
didnt
say
that
I
see
any
value
in
that
process,
he
clicked
his
pen
a
couple
of
times
and
added:
as
she
said
stuff
gets
in
but
never
gets
out.
This
is
getting
more
and
more
interesting.
Josh,
if
they
are
Sprinting,
dont
they
also
do
Sprint
demo
in
the
end?
I
asked.
Josh
only
chuckled
in
response,
grabbed
his
pen
again
and
got
back
to
clicking
it.
Im
Saheli,
Im
a
product
manager
within
this
group,
like
Josh,
a
lady
next
to
Josh
introduced
herself
with
a
light
charming
accent.
Yes,
teams
do
demos
and
Josh
and
I
were
attending
those
for
quite
a
while,
but
all
they
show
is
mostly
unfinished
stuff
Just
some
functionality
that
makes
little
sense
without
the
other
components.
Eventually
I
said
Im
not
going
to
waste
any
more
time
on
those
demos
and
we
stopped
attending,
Josh
jumped
in
again.
If
things
keep
going
like
this,
I
think
we
will
all
have
to
start
looking
at
updating
our
rsums.
Personally
I
will
include
a
year
of
hyper-Agile
experience
based
on
this,
he
said
and
laughed.
Nobody
else
in
the
room,
however,
seemed
to
find
it
as
funny.
Thats
why
we
contacted
you,
Ryan.
We
read
about
this
concept
of
the
Agile
Release
Train
and
we
thought
we
could
apply
it
to
this
program.
I
talked
to
my
former
colleagues
who
are
now
running
local
Agile
community
and
one
of
them
strongly
recommended
you.
She
actually
said
that
youve
been
through
some
really
tough
cases
in
your
consulting
career,
which
makes
me
believe
that
you
could
help
us
too.
She
mentioned
that
she
met
you
when
you
both
attended
a
conference
in
Orlando
last
year.
I
cant
figure
out
to
whom
she
could
possibly
be
referring,
but
thats
not
whats
important
right
at
this
moment.
I
bet
those
other
cases
werent
as
tough
as
our
own
private
hell,
Josh
noted
sarcastically,
now
busily
fidgeting
with
his
pen.
My
understanding
is
that
the
whole
notion
of
the
Train
revolves
around
delivering
visible,
tangible
value;
and
I
think
thats
exactly
what
we
need,
said
Stephanie
getting
us
back
on
track.
Tell
us
what
we
need
to
do.
What
does
the
transformation
process
look
like?
We
call
it
a
Quickstart,
I
said.
The
primary
action
happens
over
the
course
of
one
week
and
is
normally
preceded
by
careful
preparation
and
then
some
follow
up.
During
that
week,
I
will
work
with
teams
to
re-align
them
to
a
common
process
model,
thats
the
first
two
days.
Then,
for
the
next
two
days,
we
will
plan
our
first
Program
Increment:
PI
for
short.
Roughly
speaking,
you
can
think
of
it
as
a
release
planning
session.
And
finally,
the
last
day
can
be
used
for
Product
Owners
and
Scrum
Masters
to
dig
deeper
into
the
advanced
topics
of
how
to
operate
at
scale.
The
Quickstart
is
just
a
kick-off
for
you
guys,
but
should
provide
enough
momentum
to
drive
the
transformation.
2014
Scaled
Agile,
Inc.
They
dont,
interrupted
Josh.
They
pretend
that
dependencies
dont
exist.
They
each
iterate
in
a
complete
vacuum,
every
single
team.
And
thats
why
when
the
time
comes
to
show
Saheli
and
me
their
current
progress,
all
they
have
is
a
bunch
of
disjointed,
esoteric
stuff.
That
was
rough
but
helpful.
Actually,
despite
his
tremendously
sarcastic
attitude,
Josh
seems
to
understand
the
real
problem
here.
Stephanie
begins
looking
increasingly
puzzled.
I
outlined
the
plan:
We
will
invite
all
the
teams
and
have
Product
Management
speak
directly
to
them,
presenting
the
vision
and
key
program
priorities.
We
will
then
let
the
teams
figure
out
how
much
of
that
they
can
realistically
deliver
within
the
Program
Increment.
They
will
sort
out
the
dependencies
and
ensure
that
they
can
provide
what
they
need
for
each
other.
They
will
address
significant
risks
together
to
clear
the
way
for
realistic
release
commitment.
Then
they
will
present
their
plans
back
to
the
stakeholders,
to
make
sure
that
the
intent
is
right,
and
the
program
is
ready
to
go
full
speed
in
the
right
direction
for
the
next
PI.
Josh
stopped
his
clicking.
Stephanie,
be
open-minded
Itll
work
like
a
charm.
It
was
really
hard
to
say
whether
he
was
teasing
or
being
completely
serious,
but
it
did
not
matter
to
Stephanie.
She
was
silently
processing
all
she
had
heard.
It
was
obvious
that
she
had
begun
connecting
the
dots.
So,
thats
why
the
article
I
read
about
the
Agile
Release
Train
was
talking
about
alignment
in
almost
every
other
sentence
she
said.
Of
course.
Think
about
it.
If
a
group
of
110
people
are
busily
building
something,
but
never
able
to
produce
a
really
meaningful
increment
of
value
end-to-end,
how
much
of
their
work
is
a
waste?
Stephanie
silently
nodded.
I
continued:
Think
about
developers
and
testers
in
particular
people
that
directly
create
value
in
this
program.
They
are
supposed
to
make
an
enormous
number
of
decisions
at
the
micro
level
every
day.
For
example,
how
to
write
this
IF
statement
or
what
parameters
to
use
in
a
test
scenario,
or
what
interface
to
select
between
two
components
these
are
the
questions
for
which
they
badly
need
meaningful
context.
They
need
to
hear
from
the
business
owners,
the
product
management,
the
architects,
and
the
infrastructure
people
which
direction
the
Train
is
moving.
They
need
to
figure
out
between
themselves
the
teams
what
and
how
to
build.
Yes,
you
are
right,
alignment
is
a
key
driver
behind
the
notion
of
the
Agile
Release
Train.
Global
alignment
is
favored
over
local
team
excellence,
and
the
release
planning
session
is
a
key
first
step
in
that
direction.
You
know,
Ryan,
even
though
I
agree
with
all
of
this,
she
sighed,
I
cant
imagine
how
we
sell
it
to
the
business
stakeholders
or
even
to
the
teams.
There
will
be
a
lot
of
resistance.
Weve
already
lost
the
trust
of
the
business
stakeholders
and
now
we
are
asking
for
two
more
days
of
their
time?
Not
to
mention
that
the
teams
would
be
distracted
for
four
days?
Thats
a
tall
order.
I
understand,
but
Ill
tell
you,
Stephanie,
this
is
a
pretty
simple
cost-benefit
conversation.
Stephanie
quickly
sat
down
next
to
me,
ready
to
take
notes.
Well,
first
and
foremost,
in
order
to
justify
the
investment
of
time,
effort
and
money,
we
need
to
understand
what
the
company
can
expect
to
get
out
of
it,
I
said.
At
least
some
end-to-end
functionality,
interrupted
Josh.
We
need
to
start
building
stuff.
If
we
can
deliver,
we
can
capitalize
on
that
and
the
sooner
we
do
it
the
better
Fair
enough.
Now,
Agile
Release
Train
is
designed
to
enable
you
to
build
production-ready
increments
of
value
at
least
every
ten
weeks,
as
well
as
produce
end-to-end
working
software
as
a
measure
of
progress
at
least
once
every
two
weeks.
Stephanie
was
taking
notes
in
complete
silence.
I
let
her
finish
theres
more
to
come.
Over
time,
Trains
normally
manage
to
deliver
value
more
and
more
frequently,
therefore
detaching
development
cadence
from
delivery
schedule.
In
other
words,
you
deliver
when
the
business
needs
it
rather
than
only
at
the
Program
Increment
boundaries,
which
is
usually
eight
to
twelve
weeks.
I
picked
ten
as
a
typical
example.
That
sounds
really
good.
Stephanie
finished
writing
and
turned
to
me
again
ready,
obviously,
for
more
ideas.
Collocated
planning
every
ten
weeks
drives
alignment
of
the
entire
Train
to
a
common
vision.
Backed
by
frequent
end-to-end
system
integration
and
fortnightly
system
demos,
it
will
allow
this
group
to
build
more
value.
Its
simple
logic:
there
will
be
much
less
rework
because
teams
never
get
out
of
synch.
Nice
Give
me
one
more,
said
Stephanie.
Emphasis
on
code
quality
and
architectural
concerns
will
help
us
sustain
high
program
velocity
in
the
long
term,
and
will
prevent
technical,
design
and
quality
debt
from
accumulating.
This
means
that
our
ability
to
add
value
will
be
sustained
over
time,
which
is
not
a
typical
picture
across
the
industry
unfortunately.
2014
Scaled
Agile,
Inc.
It
will
be
fortunate
for
us,
said
Saheli.
If
we
manage
to
implement
all
you
are
saying.
Josh
made
a
funny
face,
clearly
suggesting
that
it
would
not
be
an
easy
journey.
Those
of
us,
he
quickly
added
to
the
gesture,
Who
survive
this
transformation,
will
never
be
the
same
While
the
development
managers
and
Saheli
were
cracking
up
at
Joshs
joke,
Stephanie
stayed
right
on
topic.
On
the
other
hand,
she
acknowledged
sadly,
Most
of
our
teams
are
quite
demotivated
by
the
way
things
are
now.
I
doubt
that
they
will
be
very
supportive
of
these
changes
or
of
any
changes
at
all.
Forcing
them
is
something
I
would
like
us
to
avoid
at
all
cost.
Last
month
we
lost
two
of
our
Scrum
Masters
and
a
bunch
of
developers
people
dont
feel
happy
about
their
work;
group
morale
is
very
low
I
understand.
We
will
address
that
too.
This
model
creates
benefit
not
only
for
the
business,
but
is
built
on
a
strong
foundation
of
respect
for
the
people
who
actually
create
value.
Tell
me
more,
said
Stephanie,
busily
writing
more
notes
on
a
new
sheet.
Teams
will
no
longer
plan
blindly.
They
will
now
hear
program
priorities
directly
from
the
key
stakeholders.
And
they
wont
just
hear,
its
a
two-way
conversation
where
teams
can
and
should
ask
questions
directly
of
the
stakeholders
to
figure
out
what
and
how
they
are
building
in
this
PI.
Okay
Next
their
focus
will
be
on
that
which
really
matters
end-to-end
value
delivery.
They
will
score
every
two
weeks.
Their
ultimate
goal
every
Sprint
will
be
to
deliver
a
slice
of
value
together:
something
they
can
proudly
demonstrate
to
the
stakeholders.
But
even
more
importantly,
they
will
now
know
themselves
that
they
are
making
real
progress.
That
will
bring
back
esprit
de
corps
and
make
the
workplace
an
enjoyable
place
to
be.
Beautiful
said
Stephanie,
expecting
at
least
one
more
item.
We
will
foster
software
craftsmanship
and
make
sure
that
we,
as
a
program,
take
pride
in
delivering
quality
code.
No
more
just
doing
it.
Every
increment
we
will
build
quality
in.
We
will
therefore
understand
our
real
velocity
as
a
group
and
be
able
to
sustain
it
over
a
long
period
of
time.
I
like
it.
Whether
or
not
it
will
be
an
easy
sell
only
time
will
tell.
I
personally
think
itll
be
a
tough
sell.
Nor,
Im
afraid,
will
the
implementation
be
easy
in
our
environment.
But
I
actually
have
authority
to
approve
the
budget
for
this
Quickstart.
She
paused
a
moment.
Last
question,
Ryan.
When
can
we
get
started?
2014
Scaled
Agile,
Inc.
San
Diego
is
an
amazing
place,
especially
in
the
fall.
Nature
begins
to
cut
its
ties
with
summer
in
preparation
to
what
passes
for
winter
around
here.
The
temperature
is
perfect,
although
the
water
is
a
bit
colder
than
comfortable.
The
ocean
seems
a
little
grimmer,
but
I
suspect
Im
the
only
one
who
cares
to
notice
that.
Even
having
visited
just
a
few
times,
I
feel
I
know
this
place
quite
well
and
really
enjoy
it
here.
It
would
be
nice
to
have
more
Quickstarts
on
the
West
Coast,
but
if
one
could
make
that
happen
every
time
wouldnt
that
be
a
super
power?
Like
magic,
almost
on
par
with
making
software
development
really
efficient
at
large
scale.
Tomorrow
is
a
really
big
day
we
start
our
two-day
release
planning
session
and
much
will
depend
on
how
that
goes.
The
preparation
took
two
weeks
a
very
busy
two
weeks
not
an
uncommon
thing
when
a
program
initiates
this
process
for
the
first
time.
And
not
everything
went
as
smoothly
as
expected
as
if
it
ever
does
at
scale.
The
first
thing
we
did
was
to
agree
on
the
cadence.
From
the
start,
Stephanie
managed
to
quickly
gather
key
people
and
initiate
a
good
discussion.
They
agreed
on
a
ten-week
duration
for
program
increment,
even
though
it
took
some
nerve
to
do
so.
Some
Scrum
Masters
were
overzealous
in
defending
their
existing
three-week
Sprint
cadence,
which
in
no
way
adds
up
to
a
ten-week
PI.
But
even
apart
from
that
arithmetical
glitch,
by
insisting
on
three
week
Sprints,
they
would
really
complicate
synchronization
across
the
entire
Train,
as
lots
of
teams
were
running
in
shorter,
two-week
cycles.
Aligning
the
Sprint
cadence
makes
synchronization
substantially
simpler.
And
since
most
of
the
teams
were
used
to
operating
in
two-week
timeboxes,
we
finally
managed
to
convince
the
rest
of
the
program
to
do
the
same.
In
cases
like
this
you
need
a
clear,
strong
argument
and
such
an
argument
was
presented
to
the
teams.
When
they
fail
to
deliver
end-to-end
value,
sometimes
one
wonders,
what
can
be
more
important
than
synchronization
across
teams?
When
key
stakeholders
claim
that
they
see
no
output
from
the
program,
it
is
hard
to
argue
and
defend
a
local
team
caprice.
Stephanie
did
a
lot
of
selling
during
this
session,
strengthening
my
faith
that
there
is
a
future
for
Pacific
Express
(she
came
up
with
this
name
for
the
Train).
With
this
basic
input
we
were
cleared
to
move
on
to
other
things.
The
next
big
problem
was
frequent
integration.
We
had
a
very
painful
discussion
involving
technical
experts
from
different
teams,
as
well
as
architects
and
some
test
engineers.
The
way
that
process
had
evolved
was
less
than
ideal
teams
were
each
working
in
their
own,
isolated
branch
of
code.
Did
they
have
a
common
program
branch?
Yes,
and
the
teams
actually
worked
under
the
assumption
that
they
were
regularly
synchronizing
with
the
program
branch.
The
resulting
problem
was
that
they
would
check
out
code
from
that
common
branch
into
their
own,
but
almost
never
check
anything
back
in.
So,
when
nobody
pushes
anything
into
a
shared
branch
of
code,
guess
whats
in
it?
Sprint
after
Sprint,
almost
no
changes
occurred
in
10
the
shared
codebase.
No
wonder
synchronizing
this
way
was
shockingly
easy:
nothing
was
happening!
As
soon
as
we
instituted
a
different
experiment
agreed-
upon
mandatory
daily
check-in
of
code
the
flawless
Happy
Land
turned
suddenly
into
a
world
of
pain
and
suffering.
Luckily,
though,
Saheli
provided
tremendous
support.
She
emphasized
the
importance
of
the
end-to-end
increments
from
the
teams
every
two
weeks.
And
how
could
they
produce
those
without
frequently
integrating?
I
couldnt
even
begin
to
imagine,
she
said.
Eventually
the
thread
was
resolved.
It
was
decided
to
integrate
across
the
entire
Train
at
least
three
times
per
Sprint.
These
integration
points
would
be
coordinated
carefully
on
a
Sprint-by-Sprint
basis,
assisted
by
a
newly
created
System
Team.
Their
primary
responsibilities
were
to
maintain
the
integration
and
testing
environments
and
assist
the
rest
of
the
program
with
the
integration
process.
Despite
the
fact
that
such
a
team
was
created,
Stephanie
made
it
clear
to
everyone
that
the
primary
responsibility
for
end-to-end
integration
lies
with
Agile
teams.
After
a
few
days
of
experimenting,
the
teams
also
agreed
on
a
critical
rule
the
Green
Build
Policy.
Stated
briefly:
if
integration
isnt
successful
(i.e.
not
green),
then
everybody
on
the
Train
stops
and
swarms
around
the
problem
until
it
is
resolved.
The
implication
is
that
no
new
functionality
is
being
built
on
top
of
an
incorrect
one,
which
would
cause
a
much
bigger
problem
later.
Instead,
every
new
step
is
laid
on
top
of
fully
integrated
revision
of
code.
The
organizational
structure
did
change
a
little.
It
was
decided
to
reorganize
the
maintenance
work
such
that
the
maintenance
team
would
dissolve
and
in
its
place,
maintenance
engineers
would
join
other
Agile
teams.
This
change,
proposed
by
Stephanie,
was
a
smart
move,
in
my
opinion.
There
had
always
been
a
big
gap
in
knowledge
between
the
maintenance
team
and
the
rest
of
the
program,
because
the
other
teams
never
had
an
opportunity
to
do
an
efficient
knowledge
transfer.
On
the
other
hand,
maintenance
guys
were
complaining
all
the
time
about
system
design
that
did
not
foster
maintainability
of
code.
This
was
due
to
poor
handling
of
dependencies
between
classes,
bloated
methods
and
functions
almost
impossible
to
comprehend,
and
very
tight
coupling
throughout
the
codebase.
Meanwhile,
the
eleven-member
Argonauts
team
was
split
in
two.
These
two
changes
left
the
Train
with
the
same
number
of
teams
fourteen.
The
next
big
undertaking
during
the
preparation
was
agreeing
on
program
priorities.
This
process
was
particularly
ugly
in
the
very
beginning.
It
turned
out
that
Josh
and
Saheli
didnt
actually
maintain
a
single
program
backlog,
but
instead
worked
with
teams
directly,
providing
some
scope
of
work
to
the
product
owners.
The
first
time
we
brought
things
together
in
the
same
backlog,
it
spawned
a
flurry
of
emotional
arguments
between
the
two
about
whose
stuff
was
more
valuable.
At
some
point,
I
realized
that
they
were
simply
shouting
at
one
another.
Stephanie
had
to
calm
them
down,
which
she
turns
out
to
be
quite
good
at.
Eventually,
after
the
introduction
of
economic
prioritization
with
Weighted
Shortest
Job
First
(WSJF),
the
conversation
shifted
into
a
more
productive
phase.
The
core
idea
here
is
simple:
every
feature
in
the
program
backlog
has
a
certain
Cost
of
Delay,
or
CoD
for
short.
2014
Scaled
Agile,
Inc.
11
CoD
stands
for
the
amount
of
unfulfilled
benefit
when
delivery
is
not
made
to
the
customer.
The
Cost
of
Delay
of
the
feature,
divided
by
the
duration
it
takes
to
implement,
provides
a
good
numerical
expression
of
economic
priority.
This
is
quite
intuitive,
because
the
higher
the
cost
of
delay,
the
sooner
you
want
to
get
started
with
that
feature.
And
conversely,
the
more
time
it
takes
to
implement
a
feature,
the
later
you
start
with
it.
Otherwise,
other
features,
even
smaller
ones,
will
have
to
wait
a
long
time
to
be
delivered.
We
used
a
very
specific
expression
for
Cost
of
Delay
that
reflects
different
aspects
of
a
feature
and
uses
feature
size
as
a
proxy
for
duration:
WSJF
=
(Business
Value
+
Opportunity
Enablement
+
Time
Criticality)
/
Size
We
then
gave
Saheli
and
Josh
a
chance
to
rank
each
of
these
four
parameters
for
every
feature,
in
relative
numbers,
using
Fibonacci
sequence
(just
like
the
one
Scrum
teams
use
to
estimate
the
size
of
their
stories:
0,
1,
2,
3,
5,
8,
13,
).
The
result
was
staggering:
they
managed
to
reach
reasonable
agreement
on
almost
all
features
except
one.
Enter
Stephanies
negotiation
skills
mixed
with
the
Lean
economics.
So,
we
ended
up
with
a
shared
understanding
and
agreement
on
key
priorities.
And
perhaps
most
importantly,
a
unified
program
backlog,
prioritized
by
economic
value.
With
that
accomplished,
the
Train
was
ready
to
pick
some
top
priorities
for
implementation.
The
preparation
for
the
remainder
of
the
areas,
including
the
logistics,
went
relatively
smoothly.
Nevertheless,
Stephanie
and
I
were
clearly
sensing
an
uneasy
atmosphere
across
the
board.
Key
program
stakeholders,
who
Josh
and
Saheli
de
facto
report
to,
agreed
to
participate,
but
did
so
very
reluctantly.
They
were
visibly
distant
in
all
conversations
regarding
the
transformation.
It
is
hard
to
establish
trust
when
theres
nothing
to
deliver
I
can
understand
that.
One
of
the
stakeholders,
John,
even
said
that
he
would
let
us
play
with
the
planning
and
other
things
like
that,
but
that
he
had
no
faith
in
it.
Thats
embarrassing,
but
Stephanie
and
I
are
going
to
prove
that
its
the
real
deal,
or
fail
and
fail
big
tomorrow.
But
thats
tomorrow.
Today
I
feel
a
need
to
simply
give
my
mind
a
break
from
all
these
thoughts
that
have
piled
up
over
the
last
few
days.
Right
after
finishing
the
last
session
with
Stephanie,
I
slipped
out
on
my
escape
route
La
Jolla
Village
Drive,
which
seems
to
take
me
to
another
world
in
a
matter
of
minutes.
I
hastened
to
disappear
in
the
evening
traffic
for
I
know
the
reward.
Under
the
spell
of
the
comforting
whisper
of
the
ocean,
I
can
finally
stop
thinking
and
worrying
and
fully
fuse
with
the
tremendous
vastness
of
the
sea,
as
it
prepares
to
shelter
the
sun
for
the
night.
The
day
finally
surrenders
to
the
magnificent
closure
ceremony
and
the
waters
darken,
as
does
the
whisper
of
incomprehensibly
mysterious
tongues.
No
day
repeats
itself
tomorrow
will
be
another
stream
of
unique
moments,
most
of
which
the
world
will
carelessly
forget.
12
Town
Hall
is
filled
with
the
humming
sound
of
over
a
hundred
people
getting
their
morning
coffee,
pulling
laptops
out
of
backpacks,
and
checking
smart
phones
all
the
usual
a.m.
procedures
which
you
can
do
half-asleep.
At
7:50
a.m.,
most
of
the
chairs
in
the
room
are
already
occupied.
Fourteen
tables,
one
per
team,
take
up
most
of
the
room,
leaving
some
space
around
the
walls.
A
few
more
tables
have
been
brought
in
to
handle
stakeholders
and
other
participants
that
arent
among
the
Agile
Teams.
Stephanie
is
busily
explaining
something
to
the
IT
folks
in
the
back
of
the
room,
pointing
at
the
projectors
and
large
speakers
in
the
front.
A
few
stragglers
appear
in
the
doorway
and
quickly
join
their
teams.
Stephanie
is
ready
to
kick
this
off.
She
takes
a
quick
sip
of
coffee
and
taps
the
microphone
with
her
fingernail
a
couple
times,
which
apart
from
a
sound
check
function,
signals
to
everyone
on
the
Train
that
we
are
about
to
get
started.
Good
morning
guys,
she
says
in
a
very
cheerful
voice,
causing
an
avalanche
of
good
mornings
in
response.
Earlier
today,
when
putting
team
name
tents
all
those
Wolverines
and
Argonauts
and
Spartans
and
what
not
on
every
table,
she
smiled
and
paused
for
a
second,
I
realized
that
we
were
missing
the
most
important
team
name.
We
are
all
one
team.
We
are
all
here
together
today,
on
our
first
Program
Increment
planning,
because
as
we
learned,
we
are
not
just
a
bunch
of
isolated
small
teams.
The
only
way
we
can
deliver
value
is
by
working
together.
Therefore,
I
would
like
us
all
to
remember
that
we
are
first
and
foremost
the
members
of
a
much
bigger
team
Early
in
the
morning
Stephanie
had
carefully
done
her
homework.
She
turned
now
to
the
easel
and
tore
off
the
top
page
of
the
flip
chart,
revealing
the
name
for
the
whole
program
Pacific
Express.
Stephanie
clearly
had
the
audiences
attention.
She
went
on:
Today
we
will
do
our
first
big
thing
as
a
larger
team
as
an
Agile
Release
Train.
She
pointed
at
me:
We
have
Ryan
with
us
for
the
two
days
of
planning.
Many
of
you
already
know
him
from
the
preparation
workshops
and
the
team
training
on
Monday
and
Tuesday.
Just
to
remind
you
all,
Ryan
is
a
consultant,
trainer
and
enterprise
coach
who
is
helping
us
implement
Scaled
Agile
Framework
in
our
organization.
This
program
is
our
initial
foray
into
Agile
at
scale
and
is
extremely
critical
to
the
success
of
our
business.
Our
program
will
soon
begin
operating
as
an
Agile
Release
Train
and
will
gradually
learn
how
to
deliver
meaningful
value
together,
step
by
step.
At
this
point
I
would
like
Ryan
to
take
the
stage
Thank
you,
Stephanie.
I
am
a
little
nervous.
No
matter
how
many
times
I
go
through
the
PI
planning,
its
always
a
big
deal.
Yes,
Stephanies
right.
Each
of
you
is
a
member
of
two
teams
your
Agile
team
and
the
Train.
The
notion
of
the
Agile
Release
Train
is
one
of
the
cornerstone
concepts
of
the
Scaled
Agile
Framework
(or
SAFe
for
short).
Many
of
you
have
already
heard
about
SAFe,
but
lets
make
sure
we
13
all
clearly
understand
what
it
is
and
why
we
care.
SAFe
is
a
model
of
a
Lean-Agile
enterprise.
Agility
had
proved
to
be
extremely
efficient
for
small
teams,
but
as
soon
as
large
businesses
began
implementing
the
method,
it
became
apparent
that
Agility
itself
was
not
inherently
suited
to
scale.
Out
of
this
disconnect
the
need
grew
for
a
thinking
tool
to
operate
in
a
large-scale
environment.
And
such
a
tool
was
already
out
there
Lean
thinking
a
flow-oriented
systems
thinking
approach
that
originated
from
Toyota
Production
System,
which
many
of
you
have
heard
of.
Lean
allows
us
to
abstract
for
a
moment
from
how
to
develop
software
in
an
iterative
and
incremental
manner,
and
instead
concentrate
solely
on
the
flow
of
value.
This
radical
emphasis
on
the
flow
allows
us
to
apply
this
thinking
paradigm
to
the
organization
as
a
whole.
It
serves
as
guidance
when
we
want
to
scale
agility.
It
also
governs
the
work
of
Agile
teams
so
that
they
can
understand
and
deliver
value
in
a
larger
context.
Lean
suggests
a
couple
of
simple
ideas,
that
nevertheless
substantially
facilitate
the
flow
of
value:
operating
at
low
levels
of
work-in-process,
minimizing
the
queues
in
the
flow,
and
constantly
optimizing
the
system
as
a
whole
all
to
achieve
the
shortest
sustainable
cycle
time
throughout
the
organization.
SAFe
utilizes
Lean
thinking
to
scale
Agile
best
practices.
And
the
first
such
level
we
scale
to
is
program.
Just
as
the
Agile
team
is
the
smallest
group
of
people
that
can
define-build-test
work,
there
is
another
level
Agile
Release
Train,
which
is
capable
of
delivering
solutions.
This
is
a
key
building
block
for
organizations
that
depend
on
software
development
for
their
success.
If
you
would
ask
me
how
to
define
Agile
Release
Train
in
a
single,
short
sentence,
I
would
suggest
that
it
is
simply
a
continuous
flow
program.
All
we
do
as
a
Train
is
to
accelerate
value
delivery
to
the
business.
Lean
thinking
applied
to
scaling
agility
at
this
level
leads
us
to
the
following
rules
for
the
Agile
Release
Train:
Train
is
a
self-organized
team
of
Agile
teams
(50125
individuals)
that
plans,
commits,
and
executes
together.
Program
Increment
is
a
fixed
timebox
a
major
planning
and
alignment
horizon
for
the
Train
typically
four
to
six
Sprints.
Teams
have
synchronized
Sprint
boundaries
within
the
PI.
Everyone
on
the
Train
is
aligned
to
a
common
mission
via
a
single
program
backlog,
consisting
of
features
sequenced
in
order
of
economic
priorities.
The
Train
operates
under
architectural
and
UX
guidance.
Every
two
weeks,
the
Train
produces
fully
integrated
valuable
increment
of
the
solution.
If
we
do
everything
right
during
this
planning
session,
we
will
indeed
witness
an
amazing
metamorphosis
in
this
room
a
bunch
of
disjointed
teams
will
turn
into
a
qualitatively
distinct
construct
an
Agile
Release
Train.
It
was
important
to
set
the
context
and
explain
to
them
what
Train
and
SAFe
are,
but
they
will
really
understand
it
only
by
experiencing
it.
The
planning
session
is
the
magic
wand
It
is
time
to
introduce
the
agenda
for
it.
14
PI
planning
is
a
two-day
process.
The
goal
is
simple
to
get
aligned
on
key
program
priorities
and
understand
what
we,
as
a
Train,
can
realistically
deliver
within
the
next
ten
weeks.
When
we
say
realistically,
we
mean
that
dependencies
are
identified
and
resolved,
risks
managed
and
objectives
for
each
team
agreed
upon
by
the
business
owners.
Here
is
how
we
are
going
to
do
this
Sorry,
I
have
a
question,
a
lady
from
the
Argonauts
team
raised
her
hand.
Is
this
process
similar
to
the
Sprint
planning?
Yes
and
no.
Yes,
in
the
sense
that
PI
planning
is
to
the
Train
what
Sprint
planning
is
to
the
Agile
team.
At
the
same,
time
it
has
many
additional
steps
and
process
requirements
that
differentiate
it
from
the
Sprint
planning.
The
exact
difference
we
will
be
able
to
experience
in
just
a
little
bit.
The
first
half
of
the
day
today
will
consist
of
various
briefings.
Business
owners
will
present
the
overall
direction
for
the
business.
Product
Management
will
then
present
the
solution
vision
and
the
top
features
to
be
built
in
the
PI.
Some
of
the
Product
Owners
already
have
some
seeded
stories
we
did
initial
breakdown
of
features
into
stories
a
few
days
ago.
It
was
a
useful
exercise,
but
please
keep
in
mind
that
you
may
change
the
breakdown
as
you
see
fit
as
long
as
your
product
owner
is
onboard
with
it.
The
goal
is
to
drive
maximum
value
rather
than
stick
to
the
initial
breakdown
of
features.
Next
we
will
have
the
overview
of
architecture
and
engineering
practices.
Development
infrastructure
will
also
be
discussed
as
part
of
this
briefing.
We
need
to
know
not
only
what
we
are
supposed
to
implement
as
a
Train,
but
also
how
we
are
going
to
do
that
implementation.
Again,
this
is
not
a
detailed
system
design;
its
a
high-level
guidance.
This
concludes
the
set
of
briefings
that
provide
the
required
planning
context
for
us.
Next
up
will
be
the
Team
Breakout
session.
This
is
where
the
teams
actually
plan
the
PI.
You
guys
will
have
to
break
down
features
into
stories
and
put
them
in
your
PI
plan.
While
we
will
discuss
in
detail
what
those
planning
artifacts
are
and
how
to
effectively
use
them,
let
me
make
it
clear
from
the
beginning
the
key
output
of
the
planning
for
each
team
will
be
a
set
of
Team
PI
Objectives
concise
statements
that
are
meaningful
and
valuable
to
the
business
owners.
Everything
else,
even
stories,
are
just
tools
to
arrive
at
a
succinct,
executable
set
of
objectives
lets
remember
this
throughout
the
course
of
the
planning
A
young
guy
from
the
A-Team
raised
his
hand:
How
are
objectives
different
from
features?
Or
they
are
the
same
thing?
Good
question.
In
many
cases,
objectives
will
actually
be
features.
But
thats
not
always
the
case.
Think
of
some
milestones
like
supporting
user-testing
event,
for
instance.
Its
not
a
feature
per
se,
but
makes
for
a
meaningful
PI
objective
that
has
business
value.
Another
example
could
be
a
significant
research
effort.
The
2014
Scaled
Agile,
Inc.
15
functionality
itself,
for
which
the
research
is
being
planned,
will
be
part
of
future
PIs;
or
it
may
not
be
committed
at
all
if
the
research
proves
to
be
negative.
But
the
research
itself
is
a
valuable
objective
within
the
PI.
Furthermore,
many
features
require
more
than
one
teams
participation.
In
this
case,
each
team
will
have
some
objectives
that
may
contribute
to
the
feature
but
not
entirely
complete
it.
You
may
discover
more
examples
later
today
just
by
walking
around
the
room
and
reading
what
other
teams
have
on
their
objective
sheets.
But
to
summarize,
I
can
say
that
features
are
the
initial
input
to
the
planning,
while
team
PI
objectives
represent
the
output.
The
purpose
of
the
PI
planning
session
is
to
conduct
some
sort
of
reality
check
and
to
understand
what
the
ideal
set
of
top
features
means
from
the
team
perspective.
This
is
possible
once
they
thoroughly
comprehend
the
implementation
and
possible
risks.
It
now
becomes
obvious
why
we
break
down
features
into
stories.
It
is
an
analysis-synthesis
process.
First
(analysis)
teams
break
it
down
into
smaller,
actionable
and
more
understandable
items.
Then
they
try
to
understand
each
others
dependencies,
identify
impediments
and
risks,
re-scope,
if
needed,
and
plan
for
supporting
activities
like
research,
maintenance,
etc.
Once
reality
has
set
in,
they
integrate
it
back
to
the
same
level
of
abstraction,
basically
by
summarizing
those
detailed
plans
via
the
team
PI
objectives
(synthesis).
Thats
how
we
should
view
this
process.
I
therefore
ask
you
to
do
the
following:
every
team
must
at
all
cost
get
to
the
draft
PI
objectives
by
the
end
of
the
day
today,
otherwise
neither
the
teams
nor
the
business
owners
will
be
able
to
understand
where
we
are
with
respect
to
the
planning
process.
It
is
better
to
have
a
very
rough
plan
of
all
five
Sprints
in
the
PI,
and
thus
be
able
to
derive
the
PI
objectives,
than
to
have
only
two
or
three
Sprints
planned
very
accurately,
and
still
have
no
understanding
of
the
overall
PI
outcomes.
In
other
words,
dont
get
stuck
on
too
much
detail
today.
I
especially
encourage
Scrum
Master
to
very
carefully
facilitate
the
process.
Identify
planning
impediments
as
early
as
possible
and
make
sure
the
teams
make
a
shallow
pass
over
the
entire
PI
scope,
rather
than
get
lost
in
the
detail
and
end
up
with
nothing
today.
Lets
keep
in
mind,
that
we
will
have
the
entire
day
tomorrow
to
get
deeper
into
the
nuances
of
the
functionality
and
other
concerns.
To
help
teams
stay
on
track,
we
will
have
Scrum
Master
check-in
every
45
minutes.
I
will
be
facilitating
those
meetings
while
the
rest
of
the
team
members
continue
working
on
their
plans.
Up
next
will
be
the
Draft
Plan
Review,
where
every
team
will
present
their
PI
objectives,
as
well
as
rough
description
of
the
flow
of
the
Sprints:
what
gets
done
and
when.
This
is
a
short
and
focused
presentation,
typically
two-to-three
minutes,
immediately
followed
by
a
Q&A
from
the
business
owners
and
other
teams.
This
will
conclude
the
day
for
most
of
us,
while
program
stakeholders,
Scrum
Masters
and
Product
Owners
will
stay
for
the
Management
Review
and
Problem
Solving
meeting.
We
will
go
through
what
we
learned
from
the
team
plans
and
if
any
corrective
actions
are
required,
this
is
the
time
to
make
such
decisions.
Scope
trade-offs
and
even
changes
to
the
team
composition
can
be
made
at
this
point.
2014
Scaled
Agile,
Inc.
16
We
will
begin
the
next
day
by
presenting
these
adjustments
to
the
rest
of
the
Train,
after
which
there
will
be
another
three
hours
for
team
breakout.
This
is
the
time
when
PI
plans
are
further
refined
and
business
owners
assign
business
value
to
the
objectives
for
each
team.
Once
teams
are
finished
planning
PI
scope,
they
will
present
final
plans
to
the
business
owners.
After
this
we
will
have
a
joint
session
for
risk
management
and,
finally,
teams
will
have
an
opportunity
to
do
a
confidence
vote.
After
my
introduction
to
the
process,
Stephanie
invited
the
first
presenters:
John
Head
of
Retail
Automation,
and
Tanya
VP
Development.
The
impact
this
presentation
made
on
the
audience
was
tremendous.
In
fact,
it
was
the
first
time
most
of
the
team
members
had
ever
heard
from
someone
on
the
business
side
and
the
information
John
presented
provided
invaluable
context
for
the
whole
Train.
He
discussed
the
current
state
of
the
retail
business.
Then
he
talked
about
the
companys
substantial
dilemma
of
brick-and-mortar
versus
ecommerce
as
well
as
business
automation
trade-offs
associated
with
both
paths.
John
also
talked
about
the
key
strategic
theme
of
expanding
the
number
of
ways
our
customers
can
select
products,
buy
them,
and
have
them
delivered.
Customer
base
segmentation
and
better,
more
focused
outreach
to
the
segments
with
a
particular
value
proposition
was
another
big
theme.
Although
he
was
using
a
microphone,
the
audience
was
so
quiet
you
could
hear
a
pin
drop.
After
he
finished,
Stephanie
asked
if
there
were
any
questions
the
audience
remained
silent,
still
digesting
a
boatload
of
valuable
information.
You
may
wonder
how
it
is
that
the
teams,
working
in
the
same
organization
as
John,
were
unaware
of
the
most
basic
business
context
for
their
priorities?
It
should
come
2014
Scaled
Agile,
Inc.
17
as
no
surprise,
given
that
the
methods
we
used
for
software
development
for
decades
were
built
for
anything
but
alignment.
Disjointed
activities
in
a
largely
siloed
organizational
structure
had
historically
fostered
sub-optimization
of
the
functions,
but
not
the
flow
as
a
whole.
A
simple
thing
that
accomplishes
miracles
face-to-face
communication
was
unimaginably
far
off,
replaced
instead
by
tons
of
documentation
and
a
plethora
of
isolated
business
analysis
methods
and
tools.
With
the
advent
of
Agility,
the
industry
got
a
glimpse
of
hope
as
the
Manifesto
clearly
called
for
face-to-face
communication
and
business
and
development
working
together.
But
something
else
happened
in
most
large
organizations:
for
many
of
them,
even
with
the
adoption
of
the
new
roles
and
rules,
both
Product
Owners
and
their
teams
still
stood
far
off
from
any
real
business
context,
or
the
user.
We
as
an
industry
had
failed
again
because
of
our
natural
propensity
to
value
methods
and
practices
over
process
goals
and
systems
thinking.
Picking
a
developer
and
calling
him
a
Product
Owner
does
not
help
bridge
the
gap
between
development
and
the
business.
Having
daily
standups
does
not
create
any
face-to-
face
communication
between
those
who
understand
what
needs
to
be
built,
and
those
who
are
supposed
to
build
it.
PI
planning
in
SAFe
has
a
secret
weapon,
the
likes
of
which
is
hard
to
find
probably
because
it
took
a
genius
to
figure
out
that
simply
putting
people
together
in
the
same
big
room
and
having
them
talk
to
each
other
helps
them
stay
on
the
same
page.
Tanyas
presentation
was
also
helpful.
She
provided
good
insight
to
the
technology
advancements.
She
introduced
an
important
theme:
shrinking
the
technology
stack
that
had
grown
uncontrollably
over
the
last
three
years,
ending
up
in
a
hairy
ball
of
different
tools,
libraries,
frameworks
and
platforms.
Many
of
these
duplicate
each
other
and
came
into
existence
as
a
matter
of
personal
preferences
of
different
teams,
as
opposed
to
any
rationale.
The
big
theme
for
this
PI,
as
she
noted,
would
be
to
move
all
existing
VB.NET
modules
to
C#,
as
they
are
much
easier
to
maintain.
Reducing
the
number
of
different
configuration
management
tools
used
for
different
aspects
of
data
management,
deployment
and
production
monitoring
was
another
vector
for
this
PI.
I
was
surprised
however,
when
after
finishing
their
presentations,
both
John
and
Tanya
grabbed
laptops
and
made
their
way
towards
the
door.
Puzzled,
I
glanced
at
Stephanie
but
she
didnt
seem
to
share
my
bewilderment.
As
soon
as
she
called
for
Josh
and
Saheli
to
present
the
top
priorities
in
the
program
backlog,
I
waited
a
couple
of
moments
and
caught
Stephanies
eye,
quietly
pointing
at
the
door.
She
followed
me
out
while
Josh
began
his
emotional
speech
about
the
features
the
Train
will
take
on
in
the
next
ten
weeks.
Yes?
asked
Stephanie
in
her
typically
calm
voice.
How
come
John
and
Tanya
left?
We
are
going
to
need
them.
18
For
what?
Im
sorry,
I
thought
we
needed
them
to
present
and
that
then
they
could
leave
She
realized
that
something
was
amiss.
She
sighed,
Look,
I
told
them
it
was
ok.
Maybe
that
wasnt
right.
It
wasnt.
Their
thorough
participation
was
something
I
emphasized
when
we
were
discussing
the
agenda
last
week.
The
key
stakeholders
need
to
be
with
the
program
for
the
two
days
of
planning.
Josh
and
Saheli
are
managing
the
backlog,
but
they
are
not
the
ones
that
decide
in
principle
what
this
Train
is
building.
We
need
a
full-
fledged
business
owner
team,
which
in
this
case
consists
of
John,
Tanya,
Saheli
and
Josh.
I
understand
and
Im
sorry.
Lets
run
over
and
grab
them
and
see
if
we
can
talk
them
into
coming
back.
She
sighed
again.
She
was
probably
thinking
about
how
difficult
it
would
be
to
convince
them
to
come
back,
especially
since
they
didnt
like
the
idea
of
this
planning
in
the
first
place
and
now
here
she
was
asking
for
more
If
that
was
her
thinking,
she
was
right
on
the
money.
What?
Are
you
kidding
me?
I
cant
spend
any
more
time
on
that,
said
John
when
Stephanie
voiced
the
request.
Tanya
and
I
spent
almost
an
hour
there
already.
I
dont
see
any
reason
to
spend
more
time.
Tanya
was
sitting
at
the
opposite
side
of
the
table,
nodding
in
agreement
as
John
spoke.
This
is
bad.
Without
these
two
key
people
the
program
will
drift
in
the
wrong
direction.
I
have
to
do
something
right
now
or
the
whole
thing
is
in
danger.
Teams
will
plan
something
that
these
two
guys
will
then
claim
is
wrong
in
ten
weeks
and
that
will
be
a
sad
fiasco
for
the
whole
initiative.
A
lot
of
the
Trains
effort
will
be
wasted
as
a
result.
John,
if
I
may
John
raised
his
eyebrows
and
stared
at
me.
Look,
I
know
you
and
Tanya
must
be
busy
and
have
a
lot
of
things
going
on.
I
wouldnt
expect
otherwise,
given
your
role
in
the
company.
But
I
wonder
if
you
noticed
what
just
happened
back
there
in
Town
Hall?
John
looked
at
me
suspiciously.
It
is
important
that
I
give
him
the
facts
and
then
let
him
decide.
Ill
do
what
I
can,
but
eventually
it
is
his
program,
not
mine,
so
who
should
be
more
worried
about
the
outcome
here?
John,
your
speech
absolutely
riveted
their
attention.
This
could
be
a
pretty
noisy
audience
I
can
see
that.
But
there
was
no
chatter
or
fidgeting
or
side
conversation
going
on
while
you
were
speaking.
You
know
why?
Why?
Because
they
care
There
were
many
things
that
you
and
Tanya
presented
that
they
heard
for
the
first
time
today.
That
was
an
important
piece
of
information
that
19
they
needed
to
hear
from
you.
It
is
not
something
their
product
owners
will
tell
them.
Nor
will
they
figure
that
out
on
their
own.
Things
that
are
intuitive
and
obvious
to
you
are
only
that
way
because
that
is
your
world.
You
think
and
operate
in
terms
of
the
strategic
intent
for
the
organization,
but
they
dont.
They
are
stuck
in
their
specific,
narrow
boundaries.
But
guess
what?
Every
one
of
them
is
making
lots
of
little
decisions
every
day
and
those
decisions
add
up
to
either
good
or
not
so
good
outcomes.
When
a
developer
decides
how
to
round
a
numeric
value
of
the
variable,
or
what
response
time
is
sufficient
for
a
screen,
or
which
field
to
index
a
table
by,
there
needs
to
be
some
meaning,
some
context
for
those
decisions.
There
must
be
some
glue
to
make
the
parts
adhere
into
a
broader
vision,
for
a
successful
solution
that
will
benefit
the
consumer,
as
well
as
the
business.
If
a
developer
chooses
to
create
an
index
to
slightly
speed
up
search
queries
in
the
table,
and
that
table
turns
out
to
be
write-intensive,
then
she
has
done
much
more
harm
than
good.
You
have
a
hundred
and
ten
people
in
there
that
need
guidance.
Imagine
how
many
wrong
decisions
they
will
make
within
the
next
ten
weeks
without
appropriate
context.
Imagine
how
much
waste
and
rework
there
will
be
John
sat
quietly
for
a
few
seconds
and
then
said,
Look,
you
are
probably
right.
But
I
gave
them
that
just
a
few
minutes
ago.
I
gave
them
the
context
you
are
talking
about.
For
the
rest
of
today
and
tomorrow,
I
have
a
hundred
more
things
to
get
done
and
I
bet
so
does
Tanya
I
interjected:
What
you
did
was
very
valuable.
But
it
was
a
one-way
trip.
You
delivered
the
message
to
the
group
great!
But
that
doesnt
mean
that
they
properly
understand
it
yet.
The
only
way
you
can
confirm
their
understanding
is
by
hearing
from
them;
when
you
see
their
plans,
their
PI
objectives.
They
need
to
process
your
message
and
provide
some
output
that
proves
whether
they
got
it
right
or
not.
And
trust
me,
based
on
prior
experience,
I
know
for
sure
that
you
will
find
some
significant
inconsistencies
with
your
initial
vision.
Would
you
choose
not
to
know?
John
looked
at
Tanya,
a
little
puzzled.
He
opened
his
laptop
and,
it
seemed,
completely
tuned
us
out
for
a
minute
or
two.
He
finally
put
it
aside
and
looked
at
all
of
us
with
a
softened
expression.
Very
busy
two
days,
guys.
I
can
probably
shift
some
things
around
but
dont
expect
much.
I
can
give
you
about
an
hour
more
today
and
about
the
same
amount
of
time
tomorrow.
Thats
far
from
perfect,
but
well
have
to
live
with
it.
Its
certainly
better
than
nothing.
In
that
case,
John,
if
you
could
come
by
today
at
four
for
the
draft
plan
review
and
then
again
tomorrow
at
one
when
the
teams
present
their
final
plans,
that
would
be
perfect.
John
nodded
and
looked
again
at
his
monitor.
How
about
you,
Tanya?
he
asked.
2014
Scaled
Agile,
Inc.
20
I
think
I
can
make
those
time
slots
work
as
well,
she
answered.
Great!
Stephanie
jumped
in.
Thank
you
both
so
much
for
your
flexibility
on
this.
We
all
really
need
you
two
to
make
this
program
successful.
The
door
closed
and
Stephanie
and
I
hurried
back
to
the
Town
Hall.
Ryan,
Im
sorry
for
this.
I
should
have
remembered
what
you
asked
for
earlier.
Honestly,
I
just
had
too
much
to
take
care
of
with
the
logistics
and
other
things
I
just
missed
it.
Thats
okay.
At
least
we
have
them
for
two
more
hours
now.
Lets
make
sure
we
use
their
time
efficiently.
I
think
Josh
and
Saheli
must
have
finished
their
presentations
by
now.
We
entered
Town
Hall
and
witnessed
just
the
opposite
Josh
and
Saheli
were
being
bombarded
with
questions
about
functionality,
nonfunctional
concerns,
and
so
forth.
The
teams,
realizing
that
they
finally
had
a
chance
to
resolve
the
questions
about
scope,
had
quickly
taken
advantage
of
the
opportunity.
After
four
or
five
more
questions,
Stephanie
was
able
to
usher
Saheli
and
Josh
away
from
the
podium
and
invite
the
architects
up.
This
session
went
full
length
as
teams
wondered
about
different
aspects
of
design
for
new
features,
tooling,
and
other
engineering
considerations.
With
just
fifteen
minutes
left
before
lunch,
I
took
over
the
meeting
to
cover
one
last
thing
before
the
team
breakout
starts.
This
is
what
your
plan
is
going
to
look
like,
I
pointed
at
the
wall
to
the
left
of
the
projector
screen.
21
Every
team
will
have
seven
big
sheets.
Five
of
the
sheets
will
be
for
the
five
Sprints
in
the
PI.
This
is
where
you
will
put
your
stickies
the
stories
that
you
will
formulate,
once
you
start
breaking
down
features
into
smaller,
more
manageable
chunks.
Please
keep
in
mind
that
every
team
will
still
have
their
regular
Scrum
ceremonies
(including
Sprint
planning)
every
Sprint.
Thats
when
you
will
provide
an
even
deeper
level
of
detail
to
those
backlog
items.
But
for
now,
go
only
as
deep
as
you
need
to,
in
order
to
roughly
understand
the
size,
dependencies
and
overall
significant
risks.
In
fact,
as
I
said
before,
it
is
important
that
you
stay
at
a
high
level,
otherwise
you
will
definitely
get
stuck
in
the
details
and
never
manage
to
get
through
the
entire
PI
scope.
Each
sticky
will
have
a
story
size
estimate,
just
like
in
the
sample
stories
that
Ive
created
here.
Each
Sprint
sheet
will
have
two
numbers:
Velocity
which
you
will
have
to
estimate
for
each
Sprint
in
the
PI,
taking
into
account
time
off
or
other
distractions;
and
Load
the
overall
amount
of
points
on
all
stories
loaded
into
that
Sprint.
Please
be
realistic
and
dont
expect
miracles.
Those
two
numbers
are
designed
to
be
a
self-check
for
each
team,
in
terms
of
reasonable
workload
planning.
Backlog
items
will
be
color-coded:
green
for
the
new
functionality,
orange
for
spikes
or
refactoring
effort,
purple
for
maintenance,
and
red
for
risks
and
dependencies.
Please
use
these
colors
consistently.
Another
sheet
actually
the
most
important
one
is
the
list
of
your
PI
objectives.
No
stickies
on
this
one.
Instead,
each
team
will
literally
write
the
objectives
on
the
sheet
in
the
form
of
a
list,
clear
and
legible.
The
seventh
and
final
sheet
will
be
for
risks
and
impediments
that
the
team
cannot
resolve
on
their
own.
These
need
to
be
brought
to
the
programs
attention.
2014
Scaled
Agile,
Inc.
22
We
will
adjourn
for
lunch
until
1
p.m.
But
it
would
be
helpful
if
you
guys
could
set
up
your
team
area
the
seven
sheets
so
that
we
will
have
three
full
hours
to
dedicate
to
planning.
Please
remember
that
your
goal
today
is
to
provide
a
rough
plan
of
all
five
Sprints,
enabling
you
to
derive
meaningful
PI
objectives
and
present
those
to
the
business
owners
at
four
oclock.
Lets
meet
here
at
one
sharp
for
a
quick
check-in
and
to
kick-off
the
actual
planning.
Some
teams
went
directly
to
the
kitchen
area
clearly
processing
too
much
input
during
the
briefings
consumes
a
lot
of
energy.
Others
used
the
break
to
pick
the
best
parts
of
the
wall,
close
to
their
team
tables
and
smooth
enough
to
attach
the
sheets
without
worrying
about
switches,
thermostats
or
windows.
In
just
one
hour,
the
real
action
would
kick
off,
and
result
in
a
meaningful
plan
that
helps
them
realize,
through
experience,
that
they
are
really
one
big
team.
I
certainly
want
to
believe
thats
the
case
23
It
is
1:
15
p.m.,
and
most
of
the
teams
are
busily
circulating
around
their
planning
areas.
A
few
still
sit
at
their
tables
with
Product
Owners
trying
to
pull-up
info
on
their
laptops.
Josh
and
Saheli
were
hanging
out
with
the
Avengers,
explaining
something
to
the
team.
Josh
waived
his
hands
in
his
typically
expressive
manner,
while
Saheli
made
notes
on
the
stickies
and
handed
them
to
the
team.
Thats
a
very
good
sign
thats
why
they
were
brought
in
here
to
work
with
one
another.
The
whole
room
looks
and
sounds
like
a
busy
beehive.
Hopefully
the
product
will
be
equally
sweet
.
Ryan,
does
everything
look
good
so
far?
Stephanie
had
approached
so
silently,
I
havent
even
noticed.
Are
you
kidding?
They
are
only
fifteen
minutes
into
it,
so
how
can
I
tell?
However,
some
good
things
are
already
happening.
See
Saheli
and
Josh?
Yes
Well,
they
are
exactly
where
we
need
them
to
be
during
the
breakout
session
helping
teams
and
addressing
their
inquiries.
Its
too
early
to
get
real
excited,
but
in
the
meantime,
the
first
Scrum
Master
check-in
is
going
to
happen
in
thirty
minutes
lets
go
prep
the
area.
It
is
key
for
the
entire
group
to
stay
focused,
and
in
order
to
stay
focused
you
need
a
few
key
process
goals
that
are
easy
to
follow.
Stephanie
eagerly
assisted
me
in
creating
those
and
now
its
almost
time
to
call
for
the
first
Scrum
Master
check-in.
The
teams
are
so
busy
planning,
that
only
three
Scrum
Masters
come
without
being
prompted.
We
had
to
switch
on
the
microphone
again
to
call
for
the
rest
them.
Once
all
fourteen
of
them
had
gathered
around
the
check-in
board,
we
get
started.
Guys,
we
have
to
make
this
quick
and
efficient.
We
only
have
a
few
questions
to
check
status
on,
but
they
are
important
ones.
Its
a
matrix
with
questions
as
rows
and
teams
as
columns.
I
will
pick
a
question
and
go
through
all
the
teams
and
then
another
question,
and
so
on.
All
teams
will
have
to
tell
me
where
they
are
and
then
we
will
move
to
the
next
question.
Once
we
complete
this
part,
hopefully
quickly,
we
will
have
a
meet-after,
where
you
are
welcome
to
bring
up
specific
impediments
your
teams
have
discovered.
24
Lets
get
started.
First
entry:
Are
features
broken
down
into
stories?
Id
like
to
hear
from
you
guys,
team
by
team
now.
Avengers?
No,
not
quite
finished
yet,
said
the
Scrum
Master
of
Avengers.
Were
still
working
on
it.
Good.
Partial
credit
then,
I
said
and
drew
my
favorite
half-dot
sign
in
their
cell
on
the
matrix.
Next
Argonauts?
Done!
Very
good.
Solid
dot
for
you
guys.
Spartans?
Not
done,
but
close.
We
are
moving
really
fast
with
this.
The
rest
of
the
teams
Scrum
Masters
provide
their
progress
quickly
and
we
move
to
the
next
question:
How
many
Sprints
planned?
Guys,
I
need
to
warn
you
to
be
careful
with
this
one.
Planned
means
a
very
specific
thing
for
the
Sprint.
It
means
it
has
stories
loaded
on
the
Sprint
sheet
and
it
has
two
numbers
on
it
velocity
and
load.
Then
it
counts.
Im
not
trying
to
be
overly
formal
here,
but
with
fourteen
teams
in
the
room
we
need
to
be
disciplined
about
the
process
to
avoid
unproductive
chaos.
I
will
be
putting
as
many
dots
in
a
cell
as
the
number
of
Sprints
you
have
planned.
Once
you
have
five
dots
its
going
to
be
a
check
mark
simple!
So,
Avengers?
2014
Scaled
Agile,
Inc.
25
None
yet.
Okay.
Next.
Argonauts?
One
done,
their
Scrum
Master
proudly
pointed
to
their
team
area.
It
had
everything
in
place,
including
velocity
and
load
for
the
first
Sprint.
Good
job,
guys.
One
dot
out
of
the
way
The
rest
of
the
process
went
quickly.
Partly
because
not
too
many
Scrum
Masters
had
much
to
share.
This
is
a
good
exercise
to
show
them
where
they
are,
relative
to
the
goal
for
the
day
to
have
a
plan
ready
to
present
to
the
business
owners.
Guys,
please
look
carefully
at
our
check-in
sheet.
Your
big
next
goal
is
to
finish
loading
scope
into
the
Sprints
and
formulate
your
draft
PI
objectives.
Meanwhile,
make
sure
you
start
effectively
identifying
risks,
impediments,
and
dependencies
with
other
teams.
Thats
it
for
the
main
part.
We
finished
in
nine
minutes
not
bad
at
all
for
the
first
time.
Next,
is
the
meet-after
if
we
need
one.
Are
their
any
problems
you
see
so
far?
Yes,
said
the
Avengers
Scrum
Master.
Just
before
coming
here
my
guys
asked
a
very
good
question
that
made
me
rethink
the
way
we
are
planning
the
PI.
Who
do
we
need
for
this
discussion,
do
you
think?
Im
afraid
well
need
all
Scrum
Masters
because
it
is
going
to
affect
the
entire
Train.
I
also
need
Sunil
a
developer
from
my
team
26
Stephanie
quickly
went
in
search
of
Sunil,
to
bring
him
into
the
conversation.
In
the
meantime,
the
Scrum
Master
went
on:
We
actually
almost
finished
planning
Sprint
one
and
had
started
working
on
Sprint
two,
when
Sunil
told
us
that
most
of
the
stories,
he
thinks,
are
considerably
underestimated.
Here
he
is
actually,
so
Ill
let
him
speak
All
the
stories
we
have
on
those
sheets,
except
for
spikes,
will
take
much
longer,
Sunil
quickly
jumped
in.
I
realized
that
we
did
not
account
for
end-to-end
system
integration.
During
the
last
few
weeks,
we
were
experimenting
with
it
because
Ryan
raised
the
issue
of
full
system
integration
and
we
had
agreed
to
integrate
at
least
three
times
per
Sprint.
Unfortunately,
we
never
bothered
to
determine
how
much
more
time
it
takes.
But
we
know
how
painful
it
was
during
our
initial
experiment.
The
other
guys
and
I
believe
that
it
will
take
ten
to
thirty
percent
for
each
story,
depending
on
the
complexity
and
the
number
of
teams
involved.
Some
of
the
Scrum
Masters
nodded
in
agreement.
Stephanie
glanced
at
me
and
then
proposed
an
idea:
Why
dont
we
all
simply
assume
an
average
of
20%
to
be
added
to
the
current
estimates.
Every
team
will
have
dozens
of
backlog
items
for
this
PI
and
I
think
the
law
of
large
numbers
will
make
it
work.
Shes
right.
We
need
to
communicate
this
to
the
teams
ASAP.
We
will
need
every
Scrum
Master
to
communicate
this
to
their
team.
The
message
is
simple
account
for
roughly
20%
more
to
cover
integration
effort
for
each
story,
except
for
spikes,
other
research
or
anything
that
does
not
need
to
be
integrated
into
the
mainline.
Are
we
clear
on
this
guys?
All
the
Scrum
Masters
agreed
and
now
were
ready
for
action
again.
Wait!
Another
Scrum
Master
raised
his
hand.
My
team
has
a
serious
problem.
It
affects
only
us
and
Spartans
and
we
had
better
bring
in
architects
for
this
one.
Stephanie
rushed
to
get
Bill
and
Todd,
the
system
architects
working
with
this
group,
who
were
sitting
idle
at
their
table
in
the
back
of
the
room.
Guys,
why
dont
you
all
quickly
go
back
to
your
teams
and
notify
them
about
the
change
in
the
estimation
of
stories.
I
will
need
Ninjas
and
Spartans
Scrum
Masters
back
here
immediately
afterward
for
the
session
with
the
architects.
Feel
free
to
bring
other
team
members
as
you
see
fit.
In
less
than
five
minutes,
the
entire
group
of
seven
people
was
discussing
the
issue
that
Ninjas
had
uncovered.
It
turned
out
that
this
was
the
first
time
they
had
to
apply
a
series
of
changes
to
the
database
structure
that
would
affect
a
number
of
tables
with
high
transaction
intensity.
The
tables
are
basically
responsible
for
storing
data
for
the
major
part
of
the
purchasing
process.
Data
transformation
and
2014
Scaled
Agile,
Inc.
27
transfer
to
the
new
structure
was
estimated
to
take
at
least
thirty
minutes
in
the
production
environment.
With
an
average
rate
of
three
hundred
transactions
per
second,
they
needed
a
smart
way
to
handle
this.
Luckily,
Todd
was
at
hand
and
suggested
creating
a
temporary
table
to
capture
all
the
transactions
while
the
main
data
transfer
process
was
running
in
the
background.
The
maintenance
window
can
be
then
reduced
to
less
than
a
minute
just
enough
time
to
flush
all
the
data
from
the
temporary
transaction
tables
into
the
main
tables,
once
the
main
data
transfer
process
is
complete.
We
are
looking
at
three
minutes
though,
including
the
time
to
restore
indices.
That
was
a
good
catch
by
Ninjas.
Now
they
will
have
to
add
additional
items
to
the
plan
to
create
data
transformation
scripts
that
would
automatically
handle
the
process,
and
test
it
very
thoroughly
for
any
errors
in
transaction
processing
that
could
be
fatal
to
the
business.
The
architecture
session
ended
there.
Stephanie
and
I
finally
got
a
few
minutes
to
silently
observe
the
movement
in
the
room
without
arranging
any
sessions
or
helping
teams
exchange
thoughts,
or
what
not.
It
appears
that
after
the
initial
check-
in,
there
is
more
and
more
action
in
every
team
area.
Josh
and
Saheli
split
up
and
are
working
with
different
teams,
busily
clarifying
and
moving
things
around
on
the
sheets.
Both
Bill
and
Todd
were
helping
Spartans
with
estimation.
I
could
sit
and
watch
something
like
this
forever,
but
there
were
other
things
to
do.
The
next
check-ins
introduced
more
interesting
questions,
but
teams
seemed
to
be
able
to
move
forward.
Scoping
decisions
after
the
second
check-in
unblocked
the
Samurais,
who
otherwise
could
not
fit
anything
else
in
the
PI.
A
few
more
implementation
nuances
required
Bills
attention,
but
everything
was
resolved,
since
Bill
had
moved
to
helping
another
team.
The
last
check-in
looked
really
encouraging.
All
teams
managed
to
get
to
the
PI
objectives.
And
while
there
were
small
issues
with
some
teams,
it
looked
like
the
Train
was
ready
to
present
the
plan.
28
John
and
Tanya
showed
up
a
few
minutes
before
four
oclock,
both
with
curious
expressions
as
fourteen
teams
came
into
view
in
front
of
them.
All
were
busily
discussing
scope,
walking
around
to
other
teams,
and
finalizing
the
plans
for
the
initial
review.
The
walls
looked
like
some
sort
of
mosaic,
tiled
out
of
stickies.
Red,
orange,
purple,
green
they
all
harmonized
into
a
peculiar
ornament
that
was
nearly
ready
to
tell
the
story
of
Pacific
Express.
For
someone
who
had
left
the
room
in
the
morning
when
the
walls
were
entirely
empty,
this
picture
would
indeed
appear
quite
shocking.
Now
its
time
to
wrap
up
and
present
plans.
Most
teams
decided
that
the
Product
Owners
would
be
the
ones
presenting.
Stephanie
shared
the
presentation
agenda
with
the
group.
Each
team
will
present
the
PI
objectives
and
the
overall
flow
of
the
plan,
including
key
impediments
and
dependencies
if
any
have
been
identified
so
far.
The
Spartans
will
present
first.
John,
Tanya,
Saheli
and
Josh
stand
as
close
to
the
Spartans
team
area
as
they
can
in
order
to
follow
the
outline
of
their
PI
scope.
In
this
PI,
the
team
is
going
to
pursue
the
following
objectives:
- Coupon
entry
at
Point-of-Sale
- Mirrored
real-time
transaction
data
transfer
scripts
- Support
of
different
coupon
types
- Research
and
prototyping
of
earned
points
algorithm
- Basic
discount
points
for
registered
customers
Our
estimated
velocity
in
Sprint
1
is
45
and
the
load
is
42.
Velocity
in
the
second
Sprint
is
40
with
the
load
of
39
story
points
29
He
spent
another
minute
describing
capacity
matching
and
giving
the
audience
a
rough
idea
of
what
gets
done
in
each
Sprint.
We
have
dependency
on
the
Data
Warehousing
team,
he
said,
finishing
his
talk.
Stephanie
brought
the
second
mic
and
stood
closer
to
the
business
owners.
I
have
a
question,
said
John.
What
is
that
Mirrored
data
transfer
thing?
Basically,
in
order
to
be
able
to
apply
a
coupon
at
the
point
of
sale,
we
need
to
change
the
database
structure,
where
affected
tables
have
very
high
transaction
rate
per
second.
This
requires
us
to
use
mirroring
tricks
to
capture
all
transactions
that
will
occur
in
the
system,
while
the
main
corpus
of
data
is
being
reloaded
into
a
new
structure
of
tables.
Okay,
John
said
without
too
much
confidence.
Are
you
sure
this
has
business
value
to
the
organization?
I
definitely
agree
that
it
is
a
necessary
step
to
manage
the
data
transfer
once
the
functionality
is
ready,
but
is
it
useful
enough
to
be
called
an
objective?
Stephanie
quickly
jumped
into
the
conversation:
John,
let
me
describe
whats
happening
here.
What
he
just
explained
is
not
a
one-time
process.
They
are
creating
a
set
of
scripts
that,
once
developed,
can
be
used
repeatedly
for
purposes
like
this.
Also,
the
scripts
can
be
used
with
other
tables
with
a
minimum
of
modification.
So
2014
Scaled
Agile,
Inc.
30
we
are
really
talking
about
a
re-usable
capability
that
will
recurrently
allow
our
company
to
implement
the
new
functionality
and
always
have
a
way
to
reload
the
data
within
an
extremely
tiny
maintenance
window.
John
nodded.
I
see
I
actually
agree
that
it
has
value.
Thanks
Stephanie.
Any
questions
from
the
teams?
I
turned
to
the
rest
of
the
tables
where
team
members
were
all
sitting
together,
just
like
they
had
done
in
the
morning.
After
three
hours
of
highly
intensive
planning
effort,
they
are
all
curious
to
see
what
others
have
to
present.
I
have
a
question,
shouted
a
guy
in
a
yellow
t-shirt
with
code
snippets
on
it.
What
kind
of
dependency
do
you
have
on
us?
As
the
Spartans
Product
Owner
began
to
explain,
it
became
apparent
that
the
dependency
had
not
been
communicated
to
the
other
team.
Stephanie
didnt
miss
this
opportunity
to
remind
everyone
that
they
are
supposed
to
not
only
identify
the
dependencies,
but
also
to
resolve
them.
Nevertheless,
the
team
definitely
deserved
applause
and
the
entire
room
exploded
in
cheers.
We
are
moving
to
the
next
team.
The
next
presentation
seems
to
go
quite
well
and
John
does
not
have
any
questions.
Saheli
ponders
aloud
some
details
of
the
functionality,
but
that
was
it
from
the
business
owners
side.
Surprisingly
though,
this
team
also
mentioned
a
dependency
on
data
warehousing
team.
Unlike
the
previous
case,
it
was
communicated
to
that
team,
but
it
was
also
much
bigger
and
riskier
in
nature.
Team
after
team,
we
gradually
managed
to
go
through
the
entire
group.
Some
good,
some
not
so
good,
but
every
team
had
their
PI
objectives.
Some
teams
ended
up
with
an
unrealistic
ratio
of
velocity
and
load,
which
was
pointed
out
and
taken
as
an
action
item.
The
story
with
data
warehousing
did
not
end
up
on
the
first
two
teams.
With
growing
focus
on
retail
analytics
as
a
strategic
theme,
the
Train
ended
up
with
nine
teams
requiring
assistance
of
the
data
warehouse
team,
mostly
for
logging
the
data
that
newly
implemented
user
scenarios
would
imply.
This
substantial
dependency
issue
made
Stephanie
very
uncomfortable
with
the
plan.
In
the
meantime,
John
looked
very
puzzled.
On
one
hand
he
had
the
opportunity
for
the
first
time
in
his
career
to
see
what
teams
are
really
intended
to
do.
On
the
other
hand,
something
was
deeply
troubling
him
about
what
he
just
seen.
A
few
moments
later
he
grabbed
the
mic:
Guys,
I
have
a
serious
concern
here.
I
realized
that
we
are
missing
a
lot
in
terms
of
the
pre-order
functionality.
This
is
a
strategic
direction
for
us.
Some
chains
have
this
functionality
already,
while
we
havent
been
able
to
deliver
much
of
anything
lately.
To
compete
with
the
rest
in
the
race,
we
need
to
make
a
really
bold
statement
that
will
differentiate
us
and
make
our
customers
eager
to
use
that
functionality,
over
31
and
over
again.
We
need
to
give
them
control
over
the
process
and
we
need
to
enhance
the
transparency
for
these
deceptively
obvious
user
scenarios.
John
is
apparently
eager
to
discuss
this
further,
but
thats
what
the
next
session
is
for.
We
need
to
let
the
teams
go
for
the
day.
You
guys
did
a
great
job
today,
said
Stephanie
smiling,
but
obviously
tired.
She
did
a
good
job
as
well
today,
thats
for
sure.
Whether
or
not
she
will
be
a
facilitator
for
Pacific
Express
I
cant
say,
but
she
definitely
understands
this
process
and
is
capable
of
pushing
things
forward.
Sleep
well
and
see
you
all
at
eight
tomorrow,
she
said,
adding:
We
are
still
going
to
need
Scrum
Masters
and
Product
Owners
for
another
hour
today
for
the
Management
Review
and
Problem
Solving
session.
While
the
teams
packed
their
backpacks
and
left,
the
rest
of
us
swarmed
around
the
whiteboard.
I
explained
the
process
to
the
group
that
is
staying
for
this
meeting:
We
need
to
go
though
all
outstanding
issues
and
come
up
with
the
suggestions
that
we
will
communicate
to
the
teams
first
thing
tomorrow
morning.
Lets
list
all
the
topics
Pre-order
functionality.
Theres
such
a
gap
here
that
I
cant
believe
it!
said
John
in
a
very
emotional
tone.
Im
also
changing
my
schedule
and
canceling
most
of
my
meetings
for
tomorrow.
I
dont
want
to
come
just
to
the
final
presentation
and
find
out
that
the
teams
planned
something
way
out
of
alignment
with
the
key
themes.
I
want
to
be
here
during
the
process
itself,
not
only
for
the
final
review!
Stephanie
gave
me
a
funny
look.
This
is
a
perfect
development.
John
realizes
that
the
teams
need
him.
He
probably
does
not
remember
what
happened
less
than
five
hours
ago
in
his
office,
when
he
explained
to
us
how
busy
a
person
he
is
in
this
company
Ultimately,
who
cares?
What
matters
is
that
hes
here
now,
and
he
wants
to
have
even
more
interaction
with
the
teams.
Another
topic
on
the
list
was
multiple
dependencies
on
data
warehousing.
John,
however,
quickly
got
us
back
to
the
previous
topic:
We
need
them
to
add
more
pre-order
functionality.
I
want
to
see
options
for
user
pick-up
and
delivery,
as
well
as
for
curb
pick-up.
I
also
want
order
status
tracking
and
status
updates
over
SMS.
We
need
to
show
our
customers
that
this
is
a
fast
and
transparent
process
with
multiple
options.
I
also
want
automatic
selection
of
closest
store
location,
and
selection
of
an
arbitrary
store
on
the
map.
We
need
to
make
a
strong
impression,
guys.
Saheli
and
Josh
promised
to
work
with
the
teams
the
next
day
to
add
all
of
this
to
the
plan.
It
means
that
we
will
have
to
pull
something
out
of
the
plan,
said
Saheli.
But
since
you
are
going
to
be
here
most
of
tomorrow,
we
can
probably
choose
the
items
to
de-scope
together.
2014
Scaled
Agile,
Inc.
32
John
agreed
to
that
plan
of
action
and
we
moved
to
the
second
topic
data
warehousing.
I
dont
think
any
of
this
will
execute
well
during
the
PI
if
one
team
has
almost
every
other
team
on
the
Train
depending
on
them,
said
Stephanie,
looking
to
the
others
for
more
opinions.
Guys,
I
had
to
help
move
this
topic
in
the
right
direction,
It
is
quite
obvious
that
the
Data
Warehousing
team
is
going
to
end
up
with
a
pretty
random
backlog
across
all
the
Sprints
with
that
many
dependencies
in
flight.
It
is
impossible
to
realistically
plan
and
even
worse
to
execute.
This
is
not
going
to
fly,
Im
afraid
Maybe
we
need
to
make
sure
we
invite
other
Scrum
Masters
to
this
teams
Sprint
planning
every
time
just
to
make
sure
they
are
synchronously
handling
it,
offered
Saheli.
Maybe
we
just
need
to
split
them
up
like
we
did
with
the
maintenance
team
and
have
those
people
join
the
teams
that
have
the
highest
number
of
dependencies
on
data
warehousing,
said
Josh
as
he
approached
the
board.
How
many
developers
are
on
the
team
now?
Six,
said
their
Scrum
Master.
And
one
tester
See?
Josh
smiled
widely.
They
dont
even
have
enough
testers
to
make
sure
they
are
doing
the
right
thing.
If
wed
move
those
six
guys
to
other
teams,
their
functionality
could
at
least
be
tested
in
the
context
of
other
important
scenarios
those
teams
are
working
on.
Well,
this
is
the
smartest
thing
Ive
heard
today!
he
concluded,
breaking
into
laughter,
along
with
the
rest
of
the
group.
Also,
they
didnt
even
have
a
proud
name,
like
Spartans
or
some
other
team
of
heroes
What
a
shame.
People
are
still
chuckling,
but
Josh
obviously
has
a
point
even
though
it
was
delivered
in
his
typically
pompous
manner.
As
Stephanie
had
noted
in
one
of
our
private
conversations,
Josh
is
usually
in
one
of
the
three
states:
sarcastic,
cocky
or
simultaneously
both.
But
regardless
of
that,
he
really
gets
it
and
this
time
he
again
advised
the
correct
course.
As
it
turned
out,
the
team
didnt
even
have
a
Product
Owner,
and
the
Scrum
Master
can
be
efficiently
used
with
the
newly
formed
System
Team
that
needs
one
very
badly,
but
doesnt
have
one.
The
decision
was
supported
by
everyone
and
would
be
announced
the
next
day.
*
*
*
An
hour
later
I
was
on
the
trail,
running
my
5k
down
the
beautiful
shores
of
Del
Mar.
The
ocean
looked
like
a
huge,
live
mirror,
breathing
and
spitting
out
splashes
of
the
pure,
late
evening
tides.
My
brain
was
slowly
getting
back
to
normal
and
my
GPS
2014
Scaled
Agile,
Inc.
33
watch
was
still
giving
me
hope
that
I
could
cover
the
distance
in
twenty-five
minutes
today.
My
running
belt
pouch
rhythmically
scratched
my
back
in
time
with
my
pace
Wait
it
is
actually
my
phone
vibrating.
Someone
is
calling.
I
quickly
rotate
the
belt
180
degrees
moving
the
pouch
to
the
front
Im
trying
to
grab
my
phone
without
slowing
my
pace.
Its
Stephanie
Oh
Not
now!
Now
I
have
to
stop
Ryan,
we
have
a
problem.
Do
you
remember
some
guys,
the
development
managers,
that
you
met
quite
a
while
time
ago
at
one
of
our
first
discussions?
Yes,
I
think
so
my
brain
busily
scans
for
a
picture.
Well,
I
wonder
if
you
noticed
them
in
Town
Hall
today?
No,
I
dont
think
so
Turns
out
they
were
there.
But
wait
I
dont
remember
them
at
our
last
session.
We
only
had
like
twenty
five
people
total
I
would
have
noticed
them.
See,
thats
the
problem,
Stephanies
voice
sounded
even
more
worried.
They
stayed
during
the
breakout
session
and
then
for
the
plan
review,
but
left
right
afterwards.
In
fact,
they
did
not
leave
the
office.
Do
you
remember
seeing
Tanya
at
the
problem
solving
session?
No.
I
remember
her
and
John
during
draft
plan
review,
but
she
wasnt
participating
much.
Right.
So
after
that
session
she
and
her
development
managers
conspired
in
her
office,
complaining
about
this
whole
initiative
and
the
planning
process.
What?!
Yes.
They
complained
to
her
that
with
the
new
process,
they
feel
like
they
are
not
needed
anymore.
With
teams
planning
on
their
own,
they
feel
nobody
cares
about
their
opinion.
Crap
Yep.
Tanya
called
me
and
voiced
the
seriousness
of
her
concerns,
saying
that
she
is
going
to
talk
to
our
CIO
and
express
them
to
him.
We
need
to
do
something
ASAP.
Ryan,
you
and
I
need
to
meet
at
the
office
tomorrow
at
seven
and
think
through
the
next
steps.
Can
you
do
that
for
me
please?
2014
Scaled
Agile,
Inc.
34
She
sounded
totally
desperate.
But
it
was
depressing
indeed.
We
had
had
a
pretty
good
day,
but
with
an
unexpected,
bitter
ending.
Listen,
Stephanie,
I
have
an
idea.
We
will
need
to
talk
to
all
of
them
tomorrow,
including
Tanya.
I
have
something
to
present
to
them.
Im
sure
we
have
a
chance
to
fix
this
misunderstanding.
We
better
have
a
chance,
she
said
in
a
very
depressed
voice.
Thank
you,
Ryan.
Thanks
for
helping
with
this.
Im
really
worried
about
it
all.
Thank
you
and
lets
do
all
we
can
tomorrow,
okay?
Thank
you.
She
hung
up,
but
her
deeply
disturbed
voice
still
echoed
in
my
mind.
This
is
a
very
unnecessary
complication,
but
we
will
give
it
our
best
shot.
We
will
delve
into
the
heart
of
the
problem,
instead
of
running
from
it.
Tomorrow
she
and
I
will
win
big
or
lose
big,
but
tonight
I
dont
even
want
to
think
about
it.
35
V. TROJAN HORSE
I
feel
like
Im
sending
a
sheep
down
among
the
wolves,
Ryan.
Im
sorry.
But,
you
are
right,
the
Train
needs
me
in
Town
Hall.
Stephanie,
have
you
ever
heard
of
a
sheep
that
can
bite?
A
sheep
that
hunts
to
kill?
Very
funny.
I
talked
with
Tanya
this
morning.
She
agreed
to
at
least
listen
to
you
first,
and
then
decide
what
to
do.
That
means
that
shes
not
going
to
go
to
the
CIO
and
bitch
about
us
right
away,
shell
give
it
a
chance
she
probably
wants
to
savor
it
Stephanie
smiled,
but
the
smile
was
pretty
pathetic.
Dont
worry
about
me.
Ill
do
what
I
have
to
do.
Please
make
sure
the
changes
to
the
team
composition
and
scope
of
work
are
properly
communicated
before
you
kick
off
the
breakout
session
today.
And
remember,
they
have
to
get
to
the
stretch
objectives
and
John
must
assign
business
value
to
all
PI
objectives
the
teams
have.
Stephanie
nodded
and
smiled
without
saying
a
word.
Only
now
did
I
realize
how
different
our
positions
are
and
whats
at
stake
for
her.
I
certainly
want
this
implementation
to
be
successful
and
will
do
all
I
can
to
make
it
happen,
but
shes
probably
putting
her
whole
career
at
stake
here.
Whats
the
worst
that
can
possibly
happen
to
a
consultant
whose
method
is
not
adopted?
They
never
invite
me
again?
Big
deal.
But
Stephanie
could
easily
lose
her
job
in
a
political
fight
like
this.
I
cant
let
that
happen
Guys,
you
all
know
Ryan.
Hes
here
with
us
today
to
address
our
current
concerns
with
the
process.
Feel
free
to
ask
questions
thats
why
we
set
up
this
session.
Right,
Ryan?
Thats
right.
Thank
you,
Tanya.
Actually,
before
we
get
started
with
questions,
I
want
to
present
some
initial
thoughts
to
you
guys.
Some
things
to
think
about,
some
things
to
chew
on.
Tanya
and
her
crew
were
sitting
at
the
same
table,
their
body
language
saying
more
than
a
thousand
words
possibly
could.
Some
had
their
arms
folded
across
their
chests,
others
were
settled
deep
in
their
chairs
all
of
them
sported
pretty
annoyed
expressions.
Awesome
Should
be
piece
of
cake
to
melt
this
iceberg.
I
can
admit
it
to
myself
now
Im
really,
really
worried.
But
I
move
forward:
We
are
here
because
of
a
fundamental
question:
what
is
the
role
of
the
leader
in
a
Lean-Agile
enterprise?
Many
of
you
have
operated
in
an
environment
that
employed
some
team-level
Agility.
All
teams
were
using
Scrum
as
their
basic
process.
But
do
you
know
what
Scrum
says
about
management?
36
The
awkward
silence
drives
me
crazy.
I
need
them
to
participate,
instead
of
showing
how
disconnected
they
are.
Guys?..
A
few
more
moments
pass
in
complete
silence.
Nothing?
The
guy
sitting
closest
to
me
guesses.
It
says
nothing?
Oh,
thank
goodness
for
any
answer
at
this
point,
because
the
right
answers
up-front
is
not
what
matters
in
our
little
Socratic
experiment
here.
I
just
need
them
to
abandon
all
bias
and
start
thinking.
Close.
But
its
actually
a
little
worse
than
that.
Have
any
of
you
heard
the
story
of
the
Chicken
and
the
Pig?
One
person
nodded:
It
says
were
chickens,
because
we
are
not
committed
to
the
successful
outcome
for
the
team.
At
least
it
doesnt
call
us
pigs.
The
others
chuckled.
You
have
probably
also
heard
that
Scrum
Master
is
the
one
who
removes
all
impediments
for
the
team
They
all
nodded.
So,
how
many
real
impediments
in
this
program
did
they
remove
so
far?
Again,
they
chuckled.
Unfortunately,
at
scale
this
turns
into
a
rhetorical
question.
But
please
dont
think
that
this
is
because
your
Scrum
Masters
are
bad,
or
Scrum
per
se
is
misleading.
Scrum
is
a
great
method
that
undoubtedly
revolutionized
the
way
teams
work.
At
scale,
however,
different
forces
come
into
play.
For
that
reason,
leadership
is
a
whole
separate
domain
in
Scaled
Agile
Framework.
It
provides
critical
guidance
to
those
who
actually
can
eliminate
systemic
impediments
in
large
programs
like
Pacific
Express
managers
that
have
sufficient
authority
to
change
things
for
the
better.
The
posture
and
the
expressions
on
their
faces
began
to
change
from
challenging
to
confused.
I
proceeded:
Teams
always
try
to
do
their
best.
But
they
are
the
hostages
to
the
system
they
are
part
of.
We
know
this
from
our
own
decades
of
experience.
If
you
put
people
into
functional
silos,
no
matter
how
hard
they
work
the
value
will
flow
very
slowly
through
the
system,
and
the
resulting
quality
will
be
unacceptable.
Do
you
think
2014
Scaled
Agile,
Inc.
37
38
and
the
next
one:
Help
upper
management
and
business
understand
and
embrace
Lean
thinking
Understand
and
exploit
specific
nuances
of
knowledge
creation
and
sharing
in
the
program
Identify
key
factors
that
build
trust
between
the
teams
and
the
business
Create
a
tangible
improvement
roadmap
for
the
program
and
lead
the
teams
through
the
improvement
journey
Foster
team
and
program
spirit
of
self-organization
The
expressions
on
their
faces
began
to
change.
So,
does
anybody
still
think
there
is
a
deficit
of
involvement
for
a
leader
in
a
Lean-Agile
enterprise?
Oh,
but
wait,
there
is
more!
I
hit
the
clicker
again:
Help
teams
engage
into
highly
collaborative
intra-
and
inter-team
workshops
in
identifying
requirements,
elaborating
design,
etc.
Provide
necessary
guidance
on
soft
skills
and
collaborative
techniques
Enable
spontaneous
situational
leadership
among
the
team
members
Improve/influence/change
outside
(with
respect
to
the
teams)
processes
such
as
deployment,
compliance
validation
etc.
Shorten
external
components
of
the
overall
lead
time
in
end-to-end
value
delivery
Create
a
balanced,
decentralized
decision
making
model
that
covers
a
majority
of
the
risky
areas
And
again:
Engage
all
necessary
stakeholders
in
program
backlog
refinement
and
economic
prioritization
Foster
collaborative
culture
within
the
teams
(side-by-side
work,
rotation
over
functionality,
etc.)
Keep
external
teams
and
individuals
aligned,
motivated
and
capable
of
collaborating
with
the
program
Assist
programs
in
exchanging
practical
knowledge
And
certainly
there
are
many
more
real
life
examples
that
I
did
not
include.
After
Stephanies
call
yesterday,
I
timeboxed
myself
to
twenty
minutes
and
came
up
with
these
five
dense
slides.
2014
Scaled
Agile,
Inc.
39
The
gentleman
next
to
me
rubbed
his
forehead
and
said:
Thats
a
lot
of
things
indeed,
Ryan.
It
is
a
lot,
youre
right.
But
let
me
tell
you
the
trick
we
use
to
get
that
many
touch
points
in
a
Lean-Agile
environment.
Did
you
notice
a
single
item
on
that
list
that
would
actually
have
anything
to
do
with
managing
the
teams
per
se?
No
Exactly.
The
principal
force
behind
these
dozens
of
bullet
points
is
the
switch
from
managing
to
enabling
teams.
And
since
enabling
teams
is
what
we
are
after,
we
naturally
arrive
at
a
gazillion
aspects
of
the
Leader
role.
As
you
shift
your
thinking
and
start
looking
for
the
bottlenecks
that
prevent
the
Train
from
fast
delivery
of
value
to
the
business,
you
arrive
at
more
and
more
things
like
that.
Take
a
look
at
these
again
I
browsed
through
the
presentation
once
again,
pausing
a
few
seconds
on
each
slide.
Do
you
think
teams
can
do
any
of
these
on
their
own?
No,
Ryan,
I
understand
your
point,
the
same
gentleman
said.
I
dont
know
about
you
guys,
he
turned
to
the
rest
of
the
group,
but
I
think
we
are
in
the
wrong
room
right
now.
Our
teams
need
us
in
Town
Hall.
He
rose
from
his
chair
and
walked
towards
the
door.
Other
guys
quickly
jumped
off
their
seats
too,
and
followed
him.
Tanya
alone
remained.
She
stayed
in
her
chair
for
a
little
while,
then
finally
sighed
and
headed
towards
the
doors
without
a
single
word.
However,
unlike
the
others
that
had
exited
the
room
and
moved
quickly
to
the
left,
she
turned
to
the
right,
which
clearly
is
not
the
way
to
Town
Hall.
Somehow
I
feel
that
this
isnt
over
yet.
Not
with
Tanya,
anyway.
However,
one
important
battle
was
won
today.
Four
of
the
development
managers
returned
back
where
they
belong
helping
their
teams.
I
took
a
few
minutes
to
decompress
while
disconnecting
my
laptop.
Suddenly,
Stephanie
appeared
in
the
doorway
all
shiny
and
happy,
like
you
are
at
your
12th
birthday
party.
Ryan,
I
dont
know
what
you
did
to
them,
but
they
all
ran
into
Town
Hall,
split
up
and
started
discussions
with
their
teams.
Im
staggered,
Ryan.
Thank
you
so
much!
Yeah,
but
Tanya
didnt
seem
to
Oh,
dont
worry
about
it
thats
business
as
usual
for
her.
Shell
stab
us
in
the
back
later
thats
her
style.
Lets
go
now.
Saheli
just
texted
me
that
something
is
going
on
there.
We
need
to
go
back.
She
put
her
phone
in
her
pocket
and
added:
You
know,
John
is
absolutely
rocking
it
there.
Hes
running
around
the
room
and
hes
probably
met
with
every
team
already,
some
even
twice.
Hes
assigned
business
value
to
basically
all
teams
objectives,
as
you
said,
just
a
relative
number
one
through
ten,
and
assisted
many
of
2014
Scaled
Agile,
Inc.
40
them
in
determining
what
they
should
set
as
a
stretch
objective.
I
even
heard
him
talking
on
the
phone
earlier
today,
canceling
some
of
his
meetings,
saying
something
like
I
need
to
be
here
today,
I
need
to
finish
this
first
and
so
on
And
then
he
simply
hung
up,
Stephanie
smiled.
I
automatically
smiled
in
return,
but
realized
that
for
the
last
couple
of
days
I
hadnt
been
smiling
much.
However,
all
this
time
Stephanie
had
been
around
and
despite
all
the
hardships
of
this
adventure,
she
was
the
one
human
being
I
was
so
desperately
glad
to
see
every
morning.
We
would
talk
through
the
plan
for
the
day,
discuss
problems
and
share
concerns.
Was
that
just
a
reflection
on
the
fact
that
she
will
probably
make
the
best
Release
Train
Engineer
Ive
ever
known,
or
am
I
taking
the
Lean
tenet
of
Respect
for
People
to
a
whole
new,
somewhat
personal
level?
Concentrate,
Ryan,
this
adventure
is
not
over
yet.
It
will
be
over
when
the
business
owners
tell
us
they
are
happy
with
the
plan,
and
the
teams
confirm
they
can
deliver
the
value.
Stephanie
opened
the
door
and
the
scene
before
us
was
absolutely
stunning.
It
appeared
that
team
members
had
re-shuffled.
Some
of
them
joined
two
development
managers
in
the
corner
by
the
window,
busily
crafting
something
I
hadnt
seen
before.
Hmm
Stephanie
looked
around
and
said:
Looks
like
lots
of
the
team
members
are
working
now
in
their
peer
teams
areas.
Dependencies,
I
would
guess.
And
what
is
that?
she
pointed
at
the
corner
that
had
me
completely
puzzled.
Saheli
approached
us
and
pointed
to
the
same
corner:
Guys,
I
dont
know
what
happened,
but
about
thirty
minutes
ago
Brian
and
some
other
development
managers
literally
ran
into
the
room,
circled
a
time
or
two,
carefully
observing
the
team
plans,
and
then
started
offering
help
to
the
teams
that
needed
it.
They
quickly
noticed
that
the
Wolverines
had
some
dependencies
on
the
Spartans,
but
that
those
were
actually
based
on
false
timing
expectations.
Something
that
was
expected
by
the
Wolverines
in
Sprint
two
was
actually
to
be
delivered
only
in
Sprint
four
by
the
Spartans.
Then
Brian
I
quickly
realized
that
he
was
the
one
leading
the
merry
company
back
to
Town
Hall
Gathered
the
other
managers
and
the
Scrum
Masters
and
started
mapping
those
dependencies
for
the
Train.
Thats
actually
what
they
are
doing
there
in
the
corner
as
we
speak
creating
a
dependency
board.
Its
a
matrix
with
teams
as
rows
and
Sprints
in
the
PI,
as
columns.
There
are
stickies
of
two
colors:
blue
and
red.
Blue
stands
for
a
feature.
If
a
blue
sticky
is
in
a
particular
cell,
it
means
that
that
feature
will
be
finished
by
the
team
in
that
particular
Sprint.
But
other
teams
may
also
have
inputs
to
that
feature,
which
are
the
red
stickies
connected
to
the
blue
ones
with
the
string.
I
have
no
idea
where
Brian
found
the
string,
but
it
seems
like
they
know
what
they
are
doing.
Within
the
last
ten
minutes,
they
found
four
more
dependencies
between
teams
that
were
not
synchronized
in
time.
Thats
why
the
teams
are
now
working
with
one
another
they
are
re-planning
for
those
dependencies.
2014
Scaled
Agile,
Inc.
41
Wow.
I
was
certainly
expecting
Brian
and
his
fellow
managers
to
come
and
help
their
teams,
but
I
was
not
expecting
miracles.
Meanwhile,
Brian
was
so
busy
there
at
the
board
that
he
hadnt
even
noticed
us.
But
thats
not
why
I
texted
you,
Stephanie,
Saheli
went
on.
Team
Moria
has
no
stretch
objectives.
They
are
saying
they
dont
have
any
choice
other
than
to
commit
to
100%
of
the
scope
that
they
have
on
their
sheets.
What
are
they
working
on?
I
have
seen
such
things
a
couple
times
before,
but
every
time
it
was
for
a
different
reason.
They
are
basically
working
on
legal
and
compliance
backlog
items.
Lets
go
talk
to
them.
We
dont
have
any
other
choice,
said
the
Scrum
Master
of
Moria.
If
we
dont
finish
this
whole
scope,
he
waived
his
hand
across
the
sheets
with
stickies,
We
will
not
be
able
to
even
sell
most
of
our
perishable
goods,
nor
will
we
be
able
to
take
debit
and
credit
cards.
These
are
mandatory
things
to
do
and
we
just
have
to
roll
up
our
sleeves
and
make
it
happen.
I
moved
a
little
closer
to
the
Sprint
sheets
to
see
the
numbers:
But
those
Sprints
are
fully
loaded.
Some
are
even
over
capacity.
Yeah,
but
there
is
nothing
we
can
do
2014
Scaled
Agile,
Inc.
42
Look.
The
fact
that
this
entire
scope
needs
to
be
delivered
doesnt
automatically
make
it
possible.
The
urgency
of
this
scope
and
your
teams
ability
to
deliver
are
practically
unrelated
things.
If
we
do
that,
if
we
simply
accept
this
plan
and
assume
that
the
team
will
do
miracles,
that
will
surely
lead
to
a
much
bigger
problem
later,
because
you
will
simply
fail
to
deliver.
Stephanie
was
carefully
reading
the
teams
objectives.
Im
sure
that
the
Argonauts
can
help
you
with
this
one,
she
pointed
at
Synchronized
tracking
of
used-by
date
through
the
supply
chain.
Lets
get
their
Product
Owner
over
here.
And
this
one
In-memory
encryption
mechanisms
Im
sure
it
can
be
addressed
too.
In
the
next
twenty
minutes,
they
adjusted
the
plan
and
the
two
teams
that
had
offered
help
pulled
out
some
less
important
items
from
their
backlogs.
Team
Moria,
in
turn,
picked
some
future
research
items
as
their
stretch
objectives,
which
they
would
be
able
to
get
to
once
they
got
some
breathing
room.
The
second
breakout
was
approaching
the
finish
line.
Teams
were
still
making
adjustments,
but
it
seemed
like
they
were
finally
ready
to
present
decent
plans
to
the
business
owners.
The
last
short
break
before
the
final
plan
review
does
not,
however,
seem
to
distract
the
teams
from
their
planning
areas.
Most
kept
discussing
various
items,
pointing
at
the
Sprint
sheets.
Some
walking
to
the
dependency
board
and
back
43
Accepted,
said
John
merrily,
glancing
at
Saheli
and
Josh.
The
guys
nodded
and
gave
a
big
thumbs-up
as
the
whole
room
applauded
the
product
owner
of
the
Spartans,
who
had
just
finished
presenting
their
final
plan.
The
presentation
went
pretty
fast,
generating
very
few
questions
from
the
business
owners.
Stephanie
asked
their
product
owner
to
gather
their
objectives-
and
risk
sheets
and
bring
them
to
the
front
wall,
where
the
other
four
teams
had
already
attached
theirs
after
presenting
them
to
John.
Team
Erebor
presented
next,
which
took
their
product
owner
only
three
minutes.
Basically
every
team
was
trying
to
focus
their
presentation
on
the
PI
objectives,
and
the
business
value
assigned
to
those
objectives
by
the
business
owners.
And
at
the
end,
explicitly
going
through
the
stretch
goals
for
the
PI,
as
this
is
something
that
may
or
may
not
be
delivered
and
thus
needs
to
be
called
out.
Finally,
John
and
the
guys
approved
the
last
team
plan
and
the
front
wall
received
the
last
piece
of
the
program
plan.
What
do
we
do
now?
asked
John
while
rubbing
his
hands.
Risks.
Program
risks,
I
answered
John,
as
I
took
the
microphone
and
addressed
the
whole
group:
Now,
there
is
one
more
thing
that
lies
between
us
and
the
commitment
risks.
We
will
go
through
all
the
teams
risk
sheets
one-by-one
and
build
a
consolidated
risk
sheet
for
the
program.
In
the
meantime
Stephanie
attached
four
new
flipcharts
to
the
windows
and
named
each
one
of
them:
2014
Scaled
Agile,
Inc.
44
Resolved.
Owned.
Accepted.
Mitigated.
Lets
ROAM,
she
said
and
picked
the
closest
risk
sticky
from
the
Argonauts
risk
sheet
and
read
it
out
loud
to
the
group:
Class
dependency
mapping
for
VB.Net
to
C#
module
translation.
She
raised
the
sticky
up
in
the
air
and
asked
for
someone
to
comment
on
it.
One
of
the
Argonauts
quickly
jumped
out
of
his
seat:
We
have
the
tool
to
assist
us
in
the
initial
translation
of
the
VB.NET
module,
but
since
we
know
that
such
tools
are
not
perfect,
and
we
will
still
have
to
manually
check
a
lot
of
real-
time
dependencies
between
instances
of
classes,
we
would
like
to
have
some
automatic
way
to
validate
whether
the
dependencies
were
preserved
in
a
translated
C#
source
code.
Without
such
a
thing,
we
could
actually
be
slowed
down
quite
substantially
I
know
some
tools,
Todd,
the
architect,
raised
his
hand.
I
can
show
you
at
least
two
of
the
tools
that
I
know,
but
you
guys
will
have
to
take
it
from
there.
Great,
said
Stephanie.
She
put
Todds
name
on
the
sticky
and
moved
it
to
the
Mitigated
sheet
of
the
consolidated
program
risk
area.
She
picked
the
next
sticky
and
then
the
next
More
and
more
stickies
appeared
on
the
program
sheets.
Some
werent
actually
that
risky,
as
clarified
by
other
team
members.
These
went
to
the
Resolved
sheet.
Others
we
could
do
nothing
about
and
those
were
put
in
Accepted.
She
finally
pulled
the
last
sticky
from
the
last
teams
risk
sheet:
Heres
the
last
one
from
Ninjas.
Releasability.
Stephanie
looked
on
the
other
side
of
the
sticky
but
did
not
find
any
further
detail.
Very
specific,
she
smiled
and
asked
for
the
author
of
that
sticky
to
elaborate
We
have
an
overly
formal
process
with
our
release
operations.
We
never
know
if
a
release
is
going
to
happen
smoothly
or
if
we
will
have
deployment
issues,
like
we
have
had
multiple
times
before.
If
we
keep
doing
it
this
way,
we
may
not
meet
the
dates,
said
Ninjas
Scrum
Master.
Ill
take
it,
said
Brian.
I
hear
what
you
guys
are
saying
and
Im
not
too
crazy
about
the
brick
wall
between
you
and
the
deployment
operations
team.
We
are
going
to
change
this
and
Im
taking
responsibility
over
this
item,
said
Brian,
proudly
adding,
Please
put
my
name
on
that
one.
Looks
like
Brian
is
totally
into
his
role
as
a
leader
an
enabler.
Thank
you
Brian,
that
would
make
our
life
2.5
times
easier,
said
the
Scrum
Master.
2014
Scaled
Agile,
Inc.
45
Stephanie
handed
me
the
microphone
for
the
culmination
of
the
PI
planning
session
the
Team
Confidence
Vote.
Thank
you
Stephanie.
You
guys
have
probably
noticed
that
the
key
to
this
planning
process
is
not
to
have
the
management
plan
for
you,
but
to
have
you
plan
for
yourselves,
to
have
you
manage
dependencies
and
risks.
It
is
not
enough
that
the
business
owners
approve
your
PI
objectives.
That
only
means
that
they
have
confirmed
to
you
your
understanding
of
what
they
want
you
to
build.
You
and
only
you,
can
commit
to
that
scope.
So
now
Im
going
to
ask
every
team
to
do
a
simple
confidence
vote.
Each
team
member
will
have
to
do
fist-of-five
to
show
your
confidence
level
in
delivering
this
scope
in
ten
weeks.
If
the
average
is
three
or
more,
we
take
it
as
a
sufficient
confidence
level.
So,
Ninjas,
lets
start
with
you.
Ready?
Three,
two,
one,
go!...
Five,
four,
five,
five,
four,
three,
four.
Very
good.
I
think
that
deserves
some
applause.
The
room
erupts
in
cheerful
applause.
The
next
team
vote
count
is
almost
all
fives,
as
is
the
next
one.
Argonauts.
Ready?
Go
2014
Scaled
Agile,
Inc.
46
Wow.
We
have
a
one!
What?
A
one?
We
need
to
hear
from
you
sir,
Stephanie
makes
her
way
with
the
microphone
to
a
developer
who,
I
hope,
simply
misunderstood
the
process.
Hes
the
guy
I
had
noticed
walking
around
the
room
during
the
risk
management
session.
He
had
been
staring
at
other
teams
plans
and
taking
notes.
Well,
lets
see
what
hes
got.
Im
a
developer
that
was
previously
on
the
maintenance
team
that
was
disbanded.
Now
Im
with
Argonauts
and
I
brought
some
backlog
items
with
me
from
that
team.
You
can
see
those
in
our
plan
those
purple
stickies.
He
pointed
to
the
far
corner
where
his
new
teams
Sprint
plans
were
hung.
Then
I
realized
that
some
routine
bug
fixing
that
I
used
to
do
myself
was
not
on
my
team
plan.
I
wondered
where
it
went.
I
started
walking
across
the
room
and
looking
at
other
teams
purple
stickies.
What
I
found
was
that
not
only
is
that
bug
fixing
scope
nowhere
in
the
plan,
but
that
the
overall
amount
of
maintenance
work
across
the
teams
seems
to
be
considerably
below
our
prior
workload,
compared
to
when
I
was
part
of
the
maintenance
team.
It
was
actually
quite
easy
to
figure
out.
Two
days
ago
Ryan
taught
us
Normalized
Estimation,
which
is
basically
about
starting
with
the
same
basis
for
a
story
point
across
the
Train,
in
order
to
be
able
to
compare
different
backlog
items.
Something
doesnt
add
up.
I
think
we
are
missing
a
lot
of
critical
maintenance
work,
guys.
Brian
and
Todd
where
already
walking
around
the
room.
Other
team
members
stood
up
and
started
looking
in
their
plans.
Brian
was
making
notes
and
when
he
finished
his
first
pass
around
the
room,
said:
Hes
right.
We
missed
a
whole
bunch
of
things
that
we
used
to
do.
We
have
to
re-
plan.
In
the
next
thirty
minutes,
Brian
and
all
of
the
ex-maintenance
team
members
made
a
quick
check
and
identified
the
missing
areas.
Meanwhile,
the
other
teams
product
owners
worked
with
Saheli
and
Josh
to
determine
what
they
could
pull
out,
or
at
least
move
to
stretch,
in
order
to
make
room
for
more
maintenance
effort.
Finally,
when
the
adjustments
where
made,
all
the
teams
returned
to
their
tables.
The
walls
blossomed
with
a
comforting
purple
color.
Almost
forty
percent
maintenance
missed?!
Brian
took
the
microphone.
Sergey,
thank
you
for
voicing
those
concerns,
he
pointed
to
the
developer
who
had
spotted
the
problem.
I
think
if
we
all
have
courage
and
attention
to
detail
like
Sergey
just
demonstrated,
Pacific
Express
has
a
great
chance
to
succeed.
After
this
change
we
obviously
had
to
redo
the
confidence
vote,
but
this
time
all
the
teams
voted
quite
quickly
and
all
of
them
far
exceeded
the
required
minimum.
Now,
guys,
I
took
the
mic
again,
we
have
dependencies
on
one
another,
and
we
have
to
frequently
synchronize
and
integrate
our
work.
We
have
to
operate
as
a
2014
Scaled
Agile,
Inc.
47
Train,
not
just
as
individual
Agile
teams.
This
means
that
we
must
have
a
final
vote
as
a
Train
all
of
us.
If
you
have
any
concerns,
if
you
think
that
some
of
those
things
in
the
plans
we,
as
a
Train,
will
not
be
able
to
accomplish
now
is
the
time
to
say
it
out
loud.
Everyone
raised
their
fist-of-five.
And
I
can
see
that
the
votes
are
well
above
the
three-point
average.
Which
means
we
are
done.
Congratulations,
Pacific
Express.
You
got
your
plan.
It
was
my
pleasure
to
assist
you
in
this
venture,
but
keep
in
mind
that
you
essentially
did
all
of
this
yourself.
John
suddenly
picked
up
a
second
microphone
and
joined
me
on
the
stage:
Ryan,
I
think
we
all
owe
you
one.
After
going
through
these
two
days
of
planning,
I
now
realize
how
much
we
accomplished
in
terms
of
alignment
and
gaining
a
true
understanding
of
what
we
are
building
here.
I
think
we
all
learned
a
lot
in
this
process.
And,
as
the
one
and
only
true
representative
of
the
business
here
in
this
room,
I
can
tell
you
that
I
am
really
happy
with
the
outcome.
I
think
weve
got
a
plan
*
*
*
One
hour
later,
Stephanie
and
I,
tired
but
very
happy
with
the
result
of
the
session,
were
ordering
appetizers
at
Tapenade
restaurant
in
La
Jolla.
She
said
that
the
other
guys
were
not
able
to
join
us,
which
I
absolutely
believed
to
be
the
case.
At
least
this
would
let
us
have
an
honest
conversation
about
the
flow
of
value,
limiting
WIP
and
controlling
the
queue
length...
And
in
the
morning
I
will
take
off
48
EPILOGUE
It
was
a
gentle
afternoon
rain,
tapping
softly
on
my
porch
and
trying
to
seduce
the
entire
world
into
a
nap.
It
may
be
the
last
rain
of
the
season
whatever
falls
next
out
of
the
sky
is
likely
to
freeze
before
it
touches
the
ground.
The
grass
has
all
turned
yellow
and
my
garden
is
withered
almost
ready
for
the
harshness
of
winter.
Loaded
with
coffee,
I
was
busily
working
on
a
presentation
that
would
hopefully
expand
into
a
brand
new
training
course
some
day.
I
was
taking
a
longer
break
from
traveling:
being
on
the
road
all
the
time
leaves
no
time
to
invent
new
things
and
also
leads
to
the
desolation
of
my
garden.
Both
require
time
to
grow,
both
need
attention
and
effort
to
result
in
something
pleasing
to
the
eye.
Theres
not
much
growing
outside
this
time
of
the
year
only
dry
stems
poking
out
of
the
ground.
Only
my
little
spruce
is
full
of
resilience
and
life.
This
is
the
perfect
time
to
rearrange
the
flower-beds
and
re-pave
those
tiny
little
pathways
between
them.
I
was
finishing
the
current
slide
as
well
as
my
second
cup
of
coffee
when
the
phone
broke
the
silence
with
its
rhythmic
humming,
slowly
shifting
on
the
table
in
random
directions.
It
was
Stephanie
calling.
Ryan,
how
are
you?
Is
this
good
time
to
talk?
Our
first
PI
comes
to
conclusion
in
about
two
weeks
and
we
need
you
to
help
us
with
the
program
Inspect
&
Adapt
workshop.
Sorry
for
such
short
notice,
weve
all
been
really,
really
busy
She
told
me
how
they
had
failed
to
integrate
the
system
early
on
and
how
that
led
to
a
failed
system
demo
after
Sprint
one.
Consequently,
Tanya
had
come
back
almost
immediately
with
a
lot
of
criticism
and
begun
busily
campaigning
among
the
executives
to
shut
down
SAFe
adoption.
But
heres
what
happened,
Stephanie
proceeded,
She
faced
a
relentless
resistance
from
her
own
development
managers.
I
cant
tell
you
how
many
conflicts
between
Tanya
and
Brian
I
personally
witnessed.
And
those
were
no
fun
to
listen
to,
trust
me.
But
Brian
and
other
development
managers
provided
assistance
to
the
teams
in
every
imaginable
aspect.
They
all
swarmed
around
the
integration
problem
and
guess
what?
In
Sprint
two,
we
witnessed
our
first
system
demo.
John
attended
and
was
as
happy
as
a
kid
in
a
candy
store,
asking
guys
to
run
this
and
to
click
that
and
ended
up
taking
over
the
keyboard.
Certainly
we
had
to
de-scope
a
little
to
recover
from
our
sluggishness
in
Sprint
one,
but
it
was
a
good
demo
nonetheless.
Immediately
after
the
demo,
Brian
ran
around
the
entire
building
and
personally
thanked
every
Agile
team.
Since
then
we
have
had
a
fully
integrated
increment
every
Sprint.
Yesterday
was
our
last
system
demo
and
today
we
started
Sprint
five.
We
need
you
very
badly
for
the
last
couple
days
in
this
Sprint,
where
well
do
the
grand
demo
of
the
entire
PI
scope.
This
time
not
only
will
John
be
there,
but
other
guys
from
the
business
side
said
they
would
like
to
attend.
Also,
our
CIO
will
be
there.
Stephanie
paused
for
a
couple
moments.
You
know,
they
actually
redefined
49
Tanyas
position.
She
still
holds
that
job,
but
development
managers
no
longer
report
to
her.
Also,
Brian
was
promoted
to
a
director
of
development,
which
is
a
de
facto
replacement
for
Tanya.
Anyway,
we
see
her
less
and
less
now
which
is
a
big
win
for
everyone,
she
chuckled.
So
Can
you
come?
Yes.
I
will.
Awesome
sauce!
She
said,
bursting
into
laughter.
I
have
one
other
question
for
you
though.
Yes
We
have
only
now
begun
to
realize
that
we
achieved
a
qualitative
shift
in
progress
tracking
by
producing
fully
integrated
increments
of
the
solution
every
two
weeks.
But
we
also
realized
that
now,
as
we
are
ending
the
PI,
we
dont
have
a
single
metric
to
show
how
successful
it
was
for
the
Train
as
a
whole,
or
to
see
how
good
we
did
as
individual
teams.
We
will
certainly
have
the
grand
PI
demo,
but
that
doesnt
allow
us
a
finer
perspective
on
our
accomplishments.
And
it
is
a
pity
that
we
have
only
now
realized
that
we
dont
have
a
single
metric
at
our
disposal,
here
at
the
end
Oh,
that
is
so
not
true.
You
guys
have
a
metric
already.
No
we
dont.
Sure
you
do.
Whats
on
all
those
PI
objective
sheets
the
teams
have?
Well,
committed
objectives,
stretch
objectives
and
business
value
for
each
one
of
them.
There
you
go!
But
that
is
planned
business
value.
Thats
what
business
owners
ideally
expect
from
the
teams.
Now
is
the
time
to
let
John
and
his
guys
fill
out
actual
business
value,
as
they
perceive
it
based
on
the
upcoming
PI
demo.
Imagine
this.
You
will
have
two
columns
on
every
sheet:
planned
and
actual.
Each
team
will
then
add
them
up
and
get
two
numbers:
total
planned
and
total
achieved
business
value.
Your
metric
is
the
ratio
of
the
two.
The
numbers
then
can
be
consolidated
and,
voila,
youve
got
your
metric
for
the
Train.
By
the
way,
if
you
want
to
measure
anything
at
all
for
the
Train,
you
want
to
measure
this.
And
this
metric
has
some
magic:
it
gives
you
an
idea
of
productivity,
but
expressed
in
the
most
relevant
currency
possible
percentage
of
achieved
business
value.
And
who
defines
those
numbers?
Those
in
the
organization
who
ultimately
determine
value.
You
can
never
be
wrong
when
you
directly
ask
the
business
instead
of
speculating
on
your
own.
Ryan
this
is
awesome.
Im
so
looking
forward
to
seeing
you
Seems
like
the
Train
is
acquiring
momentum.
Im
actually
glad
they
failed
their
first
system
demo
in
Sprint
one.
At
least
now
they
clearly
understand
that
our
initial
2014
Scaled
Agile,
Inc.
50
sessions,
including
the
PI
planning,
were
not
the
transformation
itself.
There
is
a
reason
why
it
is
called
Quickstart.
In
fact,
it
is
only
the
beginning
of
a
learning
journey
that
knows
no
end.
But
there
is
something
different
about
Pacific
Express
now.
They
have
learned,
although
it
was
through
much
pain,
how
to
deliver
end-to-
end
value.
That
should
open
their
eyes
to
all
other
things.
Most
programs
cant
improve
because
they
are
blind
to
the
things
that
really
matter
they
dont
see
the
system
as
a
whole.
Neither
the
one
they
are
developing,
nor
the
one
they
are
themselves
part
of.
This
Train,
it
seems,
succeeded
with
this
first,
smallest
but
most
important
step
they
acquired
the
bigger
picture
view.
The
rain
has
almost
stopped.
A
few
drops
can
still
be
seen
here
and
there,
flaring
in
the
air,
as
the
clouds
start
to
give
way
to
the
magnificent
azure
sky.
I
cant
sit
and
stare
out
in
my
window
any
longer
I
need
to
go
outside
and
feel
the
last
touch
of
the
rain,
the
kindness
of
the
sun
and
the
playful
breeze
from
the
mountains
that
wear
their
stunning
white
mitres
quite
prematurely
this
year.
51