What They Didn't Tell You in CSM Clas

What
They
Didn't
Tell
You

in
CSM
Class

Camille
Bell

cbell@CamilleBellConsul0ng.com

Twi5er
@agilecamille

Agile
DC
2016

October
24,
2016

Issue:
Scrum
Team
Missing
Key
People

What:

•  Delivery
team
does
not
include
UX
designer,
DBA,
DevOps,
etc.

–  Company/OrganizaFon
silos
key
skills
into
separate
teams

–  Handoﬀs
to
outside
overworked
teams

Impact:

•  Development
team
not
cross-‐funcFonal

=>

DELAYS/LATE

PRODUCT/

Why:

•  Company
doesn't
really
understand
or
implement
Scrum

•  Company
trying
to
opFmize
locally
instead
of
globally

•  Company
can't
hire
enough
UX,
DBA,
Ops
folks

•  Company
won't
delegate
responsibiliFes
to
delivery
team


2

Company
doesn't
really
understand
or
implement
Scrum:

•  Educate
upper
management
on
the
value
of
cross-‐funcFonal
teams

Company
trying
to
op0mize
locally
instead
of
globally:

•  Educate
upper
management
on
Lean
principles

•  Conduct
Value
Stream
Map
to
quanFfy
cost
of
handoﬀs

Company
can't
hire
enough
UX,
DBA,
Ops
folks:

•  Stop
building
non-‐essenFal
low
payoﬀ
products

•  Reduce
manual
load
on
DBA,
Testers,
Ops
with
automaFon

•  Imbed
key
people
(at
least
part
Fme)
into
Development
Team

•  Cross-‐train
members
of
Development
Team
in
key
skills

Company
won't
delegate
responsibili0es
to
delivery
team:

•  Demonstrate
improved
repeatability,
Fme
to
market
and
governance

and
reduced
risk
from
automaFon
and
cross-‐funcFonality


3

MiFgaFon:
Scrum
Team
Missing
Key
People

Issue:
Scrum
a
Mismatch
for
Team

What:

•  Scrum
expects
delivery
teams
to
have
work
with
a
predictable,

backlog
that
can
be
well
esFmated
and
can
be
completed
within

a
sprint

Impact:

•  Most
delivery
teams
slowly
become
be[er
at
esFmaFng
and

working
within
a
sprint

•  But
a
few
teams
never
do

Why:

•  Scrum
is
designed
for
teams
that
deliver
new
features

•  Some
teams
have
a
diﬀerent
cadence

•  Some
teams
cannot
eﬀecFvely
esFmate
their
work
beforehand


4

Recognize
that
Scrum
wasn't
designed
for
some
types
of
work

•  Examples
include:

–  Maintenance
Teams

–  System
Engineering
Teams

–  Network
Engineering
Teams

–  Dedicated
Research
and
Development
Teams

Maintenance
/
Bug
Fix
Teams
Can't
Es0mate
work:

•  ~
90
%
of
the
Fme
required
to
ﬁx
legacy
or
complex
bugs
is
spent

researching
and
understanding
the
bug

•  UnFl
a
bug
is
understood,
it
can't
be
esFmated

•  Use
Kanban
instead
of
Scrum
for
planning
and
tracking
progress

•  Daily
standups
and
regular
retrospecFves
are
sFll
useful


5

MiFgaFon:
Scrum
a
Mismatch
for
Team

Delivery
Teams
That
Also
Fix
Pre-‐exis0ng
Bugs:

•  EsFmaFng
bugs
is
a
waste
of
Fme

•  Instead
dedicate
a
percentage
of
the
team's
capacity
to
bug

fixes

–  Only
applies
to
pre-‐exisFng
bugs

–  Fixing
new
feature
bugs
is
part
of
regular
new
feature
work

•  Delete
that
capacity
from
the
total
capacity
when
planning
new

feature
work

•  Plan
and
track
bug
fixes
in
a
dedicated
Scrumban
Swim
Lane,

creaFng
two
input
queues,
one
the
standard
new
feature

backlog
and
a
second
of
bug
fixes

•  Use
first-‐in
first
out,
Naked
Planning,
etc.
to
prioriFze
work

items
in
the
maintenance
input
queue


6

MiFgaFon:
Scrum
a
Mismatch
for
Team

Kanban
Board
with
Swim
Lanes

(2
feature
sets,
1
bug
ﬁx)

Features

Maintenance
&

Improvement


7

System
Engineering
and
Networking
Teams:

•  These
teams
support
other
teams,
so
other
delivery
teams
are

eﬀecFvely
their
Product
Owners,
but
since
they
support
mulFple

teams
they
have
compeFng
prioriFes

•  Also
while
some
work
can
be
anFcipated,
much
of
their
work
is
and

should
be
ad-‐hoc

•  EsFmaFon
is
less
of
an
issue
(e.g.
standing
up
a
new
server
or
creaFng

a
network
alias
takes
a
predictable
amount
of
Fme)


8

MiFgaFon:
Scrum
a
Mismatch
for
Team

OpFon
1:

System
Engineering
and
Networking
Teams

incorporated
into
delivery
teams

–  Creates
a
truly
cross-‐funcFonal
team

–  Requires
restructuring
your
organizaFon

–  System
Engineering
and
Networking
tasks
become
part
of
user

stories
and
are
planned,
esFmated
and
tracked
accordingly

OpFon
2:

System
Engineering
and
Networking
Teams
remain

separate
teams

–  Use
Kanban
instead
of
Scrum
for
planning
and
tracking

progress

–  Use
ﬁrst-‐in
ﬁrst
out,
Naked
Planning,
etc.
to
prioriFze
work

items
in
the
input
queue

–  Daily
standups
and
regular
retrospecFves
are
sFll
useful


9

MiFgaFon:
Scrum
a
Mismatch
for
Team

Research
and
Development
Teams:

•  These
teams
by
their
nature
are
oeen
ad-‐hoc
and
exploratory

•  But
some
discipline
is
helpful
to
provide
technical
focus,
avoid
lengthy

excursions
down
rat
holes
and
provide
business
value

•  Less
bleeding
edge
R&D
teams
can
use
Kanban
and
someFmes
Scrum

structure
with
addiFonal
Spikes
(Fme-‐boxed
research)

•  More
bleeding
edge
R&
D
teams
probably
only
use
Kanban
containing

Spikes
with
a
very
small
input
queue/backlog
since
priority
will
oeen

change
as
a
result
of
completed
research

•  Standups
will
be
much
more
technical
in
these
teams

•  Periodic
retrospecFves
promote
new
perspecFves

•  Demos
may
be
less
regular,
but
important
to
keep
business

stakeholders
engaged


10

MiFgaFon:
Scrum
a
Mismatch
for
Team

Issue:
User
Stories
Missing
Clarity

What:

•  You
are
wriFng
User
Stories
to
avoid
requirements
bloat

•  You
even
ask
the
customer
quesFons
as
you
go

•  But
when
you
demo,
you
discover
you
are
way
oﬀ
the
mark

Impact:

•  Incorrect
funcFonality,

Fme
wasted
correcFng

=>

WRONG
PRODUCT
and/or
LATE
PRODUCT

Why:

•  User
Stories
didn’t
provide
detail
to
implement

unambiguously


11

MiFgaFon:
User
Stories
Missing
Clarity

User
Stories
didn’t
provide
enough
detail
to
implement:

•  Cards
aren’t
enough:
Need
Jeffries
3
Cs*

–  Card:
the
User
Story
itself

–  ConversaFon:
talk,
repeat
what
the
customer
said
in
different
words,

get
feedback,
ask
clarifying
quesFons
for
more
details,
challenge

your
assumpFons

–  ConfirmaFon:
automated
tests

•  Automated
tests
demand
precision

–  Given,
When,
Then
Cucumber
tests
are
very
good
for
high
level

ATDD,
BDD

–  If
possible
sit
down
with
customer
to
as
you
write
tests

–  Show
the
Cucumber
tests
to
customer

–  Get
test
data
input
and
expected
results
from
customer

•  Run
the
tests
and
show
results
to
the
customer

–  Customer
may
think
of
something
he
forgot


12
Ref:
Ron
Jeffries
3
Cs
of
User
Stories

CollaboraFvely
(Spec
it/deﬁne
tests)

•  SomeFmes
called

the
3
Amigos

(test,
dev,
business)

•  ConversaFon
based

•  Focus
on
value

•  Speciﬁc
examples

•  Concrete
data

•  Outside
in
(business
focus

drives
development)


13

Acceptance
Criteria
will
become
our
specs

when
they
have
details

Feature: Cash Withdrawal
In order to get money when the
bank is closed
As a bank customer
I want to withdraw cash at the ATM
• 
Successful
Withdrawal

• 

Less
than
balance

• 

Equal
to
balance

• 
Withdrawal
Failed
Due
to

Insuﬃcient
Funds

• 
Withdrawal
Failed
Because

Cash
Dispenser
Doesn’t

Dispense
One
Dollar
Bills

• 
Withdrawal
Failed
Because

Account
Closed

First
Cut
Acceptance
Criteria
for
several
tests


14

• 
Successful
Withdrawal

(less
than
balance)

Given my account has
starting balance of $1000
When I withdraw $200
Then $200 should be
dispensed
And the ending balance of
my account should be $800
Given,
When,
Then
format
–

Business
language
with
unambiguous
detail

Detailed
Acceptance
Criteria

These
detailed
acceptance
criteria
are

acceptance
tests
that
are
executable
specs


15

Issue:
Scrum
PrioriFzaFon
Not
CreaFng
MPV

What:

•  You
product
owners
are
prioriFzing
your
backlog
1,
2,
3
…

•  You
are
developing
stories
in
that
order

•  But
needed
pieces
are
missing
for
a
Minimal
Viable
Product

(MVP)

•  And
some
completed
stories
aren't
needed
for
a
MVP

Impact:

Not
delivering
Fmely
releasable
product

=>

IMPORTANT
FEATURES
NEGLECTED
while

=>

WASTING

TIME

and

MONEY

Why:

•  Stories
were
created
independent
of
one
another,
including

unessenFal
features,
while
omipng
less
obvious
but
needed
ones


16

Issue:
Scrum
PrioriFzaFon
Not
CreaFng
MPV

Stories
were
created
independent
of
one
another:

•  User
Story
Workshops
etc.
are
oeen
unstructured

–  Product
Owners
create
stories
oﬀ
the
top
of
their
heads

–  Stories
produce
somewhat
randomly

–  Big
picture
lost

Releases,
if
thought
of,
are
too
large,
not
MVP:

•  Triage
missing
or
applied
inconsistently

–  Nice
to
have
features
slip
in

Include
unessen0al
features:

•  Triage
missing
or
applied
inconsistently

–  Nice
to
have
features
slip
in

–  Features
that
belong
in
subsequent
MVP
releases
slip
in

Lack
of
MVP
structure
misses
less
obvious
but
needed
features


17

MiFgaFon:
Scrum
PrioriFzaFon

Not
CreaFng
MPV

Create
Personas:

•  Named
in
depth
proﬁles

•  What
is
this
user
like?
-‐
What
does
she
care
about?

Hold
Story
Mapping
sessions:

•  Keep
the
big
picture

•  Tell
stories
instead
of
write
stories

•  Elaborate
what
goes
into
a
releasable
feature,
step
by
step

•  IdenFfy
missing
pieces

–  Invisible,
but
essenFal
background
components

–  CriFcal
external
systems
,
Product
Owner
may
be
unaware
of

•  Keep
MVP
as
small
as
possible

–  Brutally
eliminate
stores
or
features
that
could
wait
for
next
MVP
as

a
mini-‐release


18

MiFgaFon:
Scrum
PrioriFzaFon
Not
CreaFng
MPV

Story
Mapping


19

System
System

NarraFve
Flow

Andy

Admin

Be[y

Buyer

Audrey

Audit

MiFgaFon:
Scrum
PrioriFzaFon
Not
CreaFng
MPV

Story
Mapping


20

System
System

NarraFve
Flow

Andy

Admin

Be[y

Buyer

Audrey

Audit

MVP1
MVP2

Issue:
RetrospecFves
Aren't
Helping

What:

•  Although
held
regularly
retrospecFves
aren't
eﬀecFve

Impact:

•  Team
is
wasFng
Fme
and
stagnaFng
instead
of
improving

Why:

•  Some
team
members
never
speak
up
in
the
retro

•  Not
possible
for
team
to
implement
recommended
changes

•  Lots
of
changes
come
out
of
the
retro,
which
aren't
implemented

•  A
few
changes
come
out
of
the
retro,
which
aren't
implemented

•  Recommended
changes
missing
underlying
problems


21

MiFgaFon:
RetrospecFves
Aren't
Helping

Some
team
members
never
speak
up
in
the
retro:

•  Team
members
feel
inhibited

–  Ensure
retro
is
held
in
completely
private
space

–  Exclude
anyone
not
working
member
of
delivery
team
(no
managers
or

observers)

–  Establish
safety
ground
rules
(e.g.
all
discussions
stay
private)

•  Extroverts
and
introverts
communicate
best
in
diﬀerent
ways

–  Write
down
retro
ideas
ahead
of
Fme
on
sFckies

–  Take
a
few
minutes
at
beginning
of
retro
to
write
down
more
ideas

–  Discuss
verbally
and
capture
more
ideas
on
sFckies

–  Use
strong
facilitaFon
if
needed
to
prevent
extroverts
overpowering

introverts


22

MiFgaFon:
RetrospecFves
Aren't
Helping

Not
possible
for
team
to
implement
recommended
changes:

•  Retro
has
become
a
gripe
session
about
other
teams

–  Acknowledge
teams'
unhappiness
(don't
pretend
it
doesn't
exist)

–  Refocus
team
on
how
they
can
improve
themselves

– 

•  Recommended
changes
have
external
dependencies

–  If
improved
collaboraFon
and
cooperaFon
with
another
team
is
a

legiFmate
concern,
focus
team
on
how
they
can
improve
their
side

(providing
earlier
heads
up,
creaFng
a
liaison,
etc.)

–  If
not,
refocus
team
on
how
they
can
improve
themselves

Lots
of
recommenda0ons
which
aren't
implemented:

•  Cluster
similar
recommendaFons
into
sFcky
groups

•  Choose
one
sFcky
to
represent
the
group

•  Use
dot
voFng
to
choose
or
or
at
most
two
recommendaFons


23

MiFgaFon:
RetrospecFves
Aren't
Helping

A
couple
recommenda0ons
but
none
implemented:

•  Track
implementaFon
of
recommendaFon
on
a
sFcky
clearly

viewable
in
team
room

•  At
the
beginning
of
each
retro
ask
team
if
they
implemented
the

recommendaFon
using
ﬁst
of
5

•  If
every
team
member
votes
a
3
or
above
mark
a
plus
on
the
sFcky

•  Otherwise
mark
a
minus

•  Aeer
four
pluses,
throw
away
the
sFcky
(Team's
internalized
it)

•  Aeer
four
minuses,
throw
away
the
sFcky
(Team's
not
going
to
do
it)

•  Aeer
four
Fmes
with
a
mix,
team
discusses


24

Team pair programs
at least 2 hrs a day
++

MiFgaFon:
RetrospecFves
Aren't
Helping

Recommended
changes
missing
underlying
problems:

•  Stop
using
simplis0c
retro
techniques,
like
the
quesFons
below

–  What
went
well
during
the
sprint
cycle?

–  What
went
wrong
during
the
sprint
cycle?

–  What
could
we
do
diﬀerently
to
improve?

•  Instead
go
much
deeper,
when
needed

–  Provide
more
Fme
for
a
deeper
retro

–  Hold
retros
that
cover
a
longer
period
of
Fme,
like
a
release

–  Use
"Timeline"
to
gather
data
and
reveal
pa[ers

–  Use
"5
whys"
to
dig
deeper
into
issues

–  Use
"SMART"
goals

•  Speciﬁc

•  Measurable

•  A[ainable

•  Relevant

•  Time
Bound


25

Issue:
No
Story
Burndown
Till
Last
Day

What:

•  Hour
burndowns
may
have
a
downward
slope
as
they
should

•  But
stories
aren't
completed
unFl
end
of
Sprint

•  End
of
Sprint
is
chaoFc

Impact:

•  Some
stories
rollover
into
the
next
Sprint

•  Completed
stories
have
lower
quality

•  Team
feels
stressed
at
the
end
of
the
Sprint

Why:

•  Stories
are
too
big

•  Team
members
are
task
switching

•  Team
members
are
focusing
on
starFng
work
instead
of
compleFng
work

•  Team
members
aren't
helping
each
other


26

0

2

4

6

8

10

12

1
2
3
4
5
6
7
8
9
10

Stories

Sprint
Day

Hockey
S0ck
Burndown

To
Do
Done

Why
is
so
li[le
gepng
done?

Too
many
stories
in
ﬂight!

Task
switching
!

Handoﬀs!

No
cooperaFon!

Jim

Mary

Mark

Paul

Jim

Ken

Sue

Sue

Ken

Ken

Paul

Mark

Sue

Mark

Sue

Scrum doesn’t have WIP Limits. Without WIP Limits Scrum can be dysfunctional. Consider adding WIP Limits to Scrum.

27

Doing

FLOW

Mary

Mary

Switching
between
three
one
week
tasks
means

none

of
them
get
done
in
three
weeks.

Week 1 Week 2 Week 3 Week 4
Task A
Task B
Task C
Dev

completes

task
before

starFng
next

one

Dev
switches

between
tasks

Ref:
Mary
and
Tom
Poppendieck
on
Lean

28

MiFgaFon:
No
Story
Burndown
Till
Last
Day

Stories
are
too
big:

•  Size
stories
to
finish
in
1/3
or
less
of
the
Sprint
length

Task
switching:

•  Set
strict
Work
in
Progress
Limits
to
prevent
task
switching

–  Recommended
Max
WIP
limit

=
Team
Size
/
#
Team
Members
per
Story

Not
Focused
on
Finishing:

•  Sign
up
for
fewer
stories
(can
always
add
one
if
others
finish
early)

•  No
team
member
starts
new
story,
if
other's
stories
not
finished

(help
others
finish
instead)

•  Use
project
board
to
show
story
progress
and
talk
about
stories

closest
to
done
in
standup,
before
talking
about
other
stories

Not
Helping
Each
Other:

•  InsFtute
Pair
Programming

•  Use
Mob
Programming


29

To
Do
Done

Jim

Mark
Paul

Sue
Ken


30

WIP
Limit
=
3

Doing

FLOW

Mary

Story
Board
with
WIP
Limits

Issue:
Scrum
Provides
No
Technical
PracFces

What:

•  Scrum
is
used
extensively
for
soeware
development

•  Scrum
provides
only
guidance
for
management
and
organizaFon
of

soeware
development
teams

Impact:

•  Only
using
Scrum
pracFces
may
build
the
right
product,
but
its
built

the
wrong
way

=>

SW
IS
HARD
TO
TEST

=>

SW
IS
HARD
TO
MODIFY

=>

SW
IS
BUGGY

=>

COSTS
EXTRA
TIME

and

MONEY

Why:

•  Scrum
is
missing
guidance
to
build
working,
tested,
maintainable

soeware


31

MiFgaFon:
Scrum
Provides
No
Technical
PracFces

Scrum
is
missing
guidance
to
build
working,
tested,
maintainable

soeware:

•  Add
Extreme
Programming
pracFces
to
Scrum

–  Acceptance
Tests
–
see
"User
Stories
Missing
Clarity"
MiFgaFon

–  Test
Driven
Development
improves
code
design,
reduces
bugs
and

eliminates
gold
plaFng

–  Refactoring
and
design
improvement
ensures
maintainability
and
speeds

addiFon
of
new
features

–  Pair
Programming
provides
conFnuous
inspecFon,
cross
training
and

distributed
knowledge
of
codebase

–  Con0nuous
Integra0on
produces
solid
builds
and
ensures
team
is
all

working
on
the
same
version
of
the
soeware

–  Etc.


32
http://www.extremeprogramming.org/

MiFgaFon:
Scrum
Provides
No
Technical
PracFces

Scrum
is
missing
guidance
to
build
working,
tested,
maintainable

Soeware
(con0nued):

•  Incorporate
Con0nuous
Delivery

–  Modern
Dev
Ops
movement
goal

•  Always
be
ready
to
release

•  Every
change
could
be
deployed
if
desired

–  Ferrets
outs
problems
in
development
and
release
processes
and
systems

–  Follow
on
to
ConFnuous
IntegraFons
with
automaFc
staging
and
tesFng
of

security,
performance,
etc.

–  Reliant
on
pracFces
like
Extreme
Programming


33

https://en.wikipedia.org/wiki/Continuous_delivery/

MiFgaFon:
Scrum
Provides
No
Technical
PracFces

Scrum
is
missing
guidance
to
build
working,
tested,
maintainable

Soeware
(con0nued):

•  PracFce,
pracFce,
pracFce

–  Like
learning
to
play
an
instrument
learning
new
ways
of
development

requires
lots
of
pracFce
and
reinforcement

–  Becoming
proﬁcient
in
Test
Driven
Development,
Refactoring,
etc.
requires

more
Fme
and
eﬀort
than
learning
Scrum
–
be
paFent

–  Provide
technical
training
to
help
developers
get
started

–  PracFce
Pair
Programming

•  Having
a
buddy
to
work
with
reinforces
TDD,
Refactoring
and
CI

•  Without
a
partner
its
too
easy
to
fall
back
onto
old
habits

–  PracFce
Mob
Programming

–  Run
Code
Katas
to
pracFce
Test
Driven
Development
and
refactoring

–  A[end
Code
Retreats

–  Get
the
team
technical
coaching


34

globalday.coderetreat.org
http://coderetreat.org/

https://www.youtube.com/watch?v=p_pvslS4gEI

Issue:
Scrum
of
Scrum
Isn't
EffecFve

What:

•  The
Scrum
of
Scrums
worked
alright
with
four
teams

•  But
when
more
teams
were
added,
problems
slipped
through
the
cracks

Impact:

•  Unneeded
working
is
being
done

•  Needed
work
is
not
being
done

•  Delivery
teams
find
themselves
blocked
by
other
teams
or
external
factors

Why:

•  Complex
technical
architecture
with
lots
of
different
languages
and
3rd
party

soeware

•  Technical
teams
are
siloed
and
over
specialized

•  There
are
lots
inter-‐team
dependencies

•  Many
inter-‐team
dependencies
are
not
obvious

•  Scrum
of
Scrums
doesn't
scale
well


35

MiFgaFon:
Scrum
of
Scrum
Isn't
EffecFve

Complex
technical
architecture
with
lots
of
different
languages

and
3rd
party
soeware:

•  Simplify
the
architecture
to
reduce
dependencies
and
complexity

•  Simply
the
architecture
step
by
step,
not
all
at
once

•  Architecture
simplificaFon
can
takes
years

Technical
teams
are
siloed
and
over
specialized:

There
are
lots
inter-‐team
dependencies:

Many
inter-‐team
dependencies
are
not
obvious:

•  Create
cross-‐funcFonal
teams
–
see
"Scrum
Team
Missing
Key

People"

•  Cross
train
team
members
–
pairing
really
helps

•  Proac0vely
look
for
dependencies
and
impediments;
don't
assume

team
members
will
always
know
about
their
dependencies
on
non-‐
team
soeware,
architecture
or
schedules


36

MiFgaFon:
Scrum
of
Scrum
Isn't
EﬀecFve?

Scrum
of
Scrums
doesn't
scale
well:

•  Scrum
of
Scrum
works
pre[y
well
with
four
teams

–  Even
with
four
teams,
it
helps
if
members
of
those
teams
interact
with

each
other
regularly
outside
of
the
Scrum
of
Scrums

•  The
the
more
teams
in
a
Scrum
of
Scrums,
the
less
well
it
works,
so

the
ﬁrst
step
is
to
reduce
the
number
of
teams

–  Ensure
that
all
teams
are
working
to
build
the
same
product

•  If
not
remove
those
teams
from
the
Scrum
of
Scrums
(they
are
just
adding

noise
to
the
Scrum
of
Scrums)

•  The
removed
teams
may
belong
in
another
product's
Scrum
of
Scrums

–  CreaFng
true
cross-‐funcFonal
teams
and
cross
training
will
reduce
the

number
of
teams
needed

–  Simplifying
the
technical
architecture
will
reduce
the
variety
of
skills

needed
and
so
the
number
of
teams
needed


37

MiFgaFon:
Scrum
of
Scrum
Isn't
EffecFve?

Scrum
of
Scrums
doesn't
scale
well
(con0nued):

•  If
aeer
applying
all
the
bullets
on
reducing
the
number
of
teams
and

there
are
sFll
more
than
four
or
five
teams
or
Scrum
of
Scrums
isn't

effecFve
even
with
a
few
teams,
replace
Scrum
of
Scrums

–  Use
Kanban
instead
of
Scrum
of
Scrums

–  Focus
on
the
product's
need
for
inter-‐team
planning
and
coordinaFon

not
"what
did
your
team
do
yesterday?"

–  Focus
on
longer
term
issues
across
Sprints

–  Assign
a
very
technical
agile
manger/facilitator
who
proac0vely
looks
for

dependencies,
impediments
and
product
wide
issues

–  Create
a
backlog
for
this
2nd
Fer
Kanban
containing
work
items
needed

for
the
product
itself
and
the
product
teams

–  Scale
across
the
organizaFon
and
mulFple
products
with
a
3rd
Fer
Kanban

with
an
organizaFonal
backlog


38

Don’t
Go
It
Alone

Become
ac0ve
in
local
user
groups
(ﬁnd
on
Meetup.com):

•  Agile,
Scrum
and
Kanban
Groups

•  Soeware
Craesmanship
Groups
(Code
Kata
groups
and
Code
Retreats)

•  Technology
Speciﬁc
Groups
(languages,
pla}orms,
DevOps,
etc.)

Read
about
several
agile
prac0ces:

•  Lean
&
Kanban

•  Scrum

•  eXtreme
Programming

A5end
conferences
and
training

Bring
in
consultants,
where
appropriate

Share
your
knowledge
and
experience


39

Camille
Bell

Agile
Coaching
&
ConsulFng

RetrospecFves

Agile
Boot
Camps

Agile
Training

Updated
Slides

or
just
to
chat
about
things
agile


What They Didn't Tell You in CSM Clas

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (11)

Similar to What They Didn't Tell You in CSM Clas

Similar to What They Didn't Tell You in CSM Clas (20)

More from Camille Bell

More from Camille Bell (12)

Recently uploaded

Recently uploaded (20)

What They Didn't Tell You in CSM Clas