Kanban Introduction for Agile Teams

An
Introduc+on
to
Kanban

Camille
Bell

Agile
Coach

cbell@CamilleBellConsul+ng.com

Twi+er
@agilecamille

Background

•  Agile
≠
Scrum

–  Agile
is
a
philosophy

•  Individuals
and
interac+ons
over
processes
and
tools

•  Working
soAware
over
comprehensive
documenta+on

•  Customer
collabora+on
over
contract
nego+a+on

•  Responding
to
change
over
following
a
plan

–  There
are
many
ways
to
do
Agile

•  Scrum

•  Kanban
/
Lean

•  XP

•  Etc

•  Kanban
is
a
change
management
method,
not
a

soAware
development
lifecycle
or
project

management
method
or
process

cbell@CamilleBellConsul4ng.com

2

Why
Kanban?

•  Stop
rewarding
star%ng
work
and
start

focusing
on
ﬁnishing
work

– Work
in
progress
(WIP)
should
be
limited

– Only
start
work
on
something
new
when
there
is

capacity
to
do
the
work


3

Way
Too
Many
User
Stories
in
Flight

(Scrum
without
WIP
Limits
can
be
dysfunc+onal)


4

5
Key
Principles
to
Kanban

•  U+lize
Visual
Controls

•  Limit
WIP
(Work-‐In-‐Progress)

•  Manage
Flow

•  Con+nuous
Improvement

•  Explicit
Policies

Manage
the

work

Not
the
people!


5

Visual
Controls

•  Work
is
transparent
and
always
present

•  Easy
to
iden+fy
boZlenecks

•  Kanban
literally
means
“visual
card/board”

TITLE
Owner
Date
Ready
Date
Started

ID#
Project
name
Due
Date


6

To
Do
In
Progress
Done

What
Happens
to
an
“In
Progress”
Story?

Where
is
each
story
in
that
process?


7

“In
Process”
Steps
May
Diﬀer
by
Team

•  Team
A
“In
Process”
steps

–  UI
Design

–  TDD
(Automated
Test/Code/Refactor
Cycle)

–  Manual
Acceptance
Tes+ng

•  Team
B
“In
Process”
steps

–  Analysis

–  SW
Design

–  Review

–  Code

–  Automated
Unit
Test


8

Model
Steps
That
Exist

(not
what
you
wish
they
were)

When
the
steps
change,
then
change
your
board,
not
before


9

In

Process

In

Process

In

Process
Queue
Queue
Queue

User

Stories

Step
1
Step
2
Step
n
Done

.
.
.

.
.
.

8

7
6
5
4
3
2
1

KANBAN
BOARD
–
VISUALIZE
WORK
STEPS

Work
Type -
Doing
Work
Type -
Done
Model
All
the
Steps
That
Exists
–
there
could
be
dozens.
Steps
will
vary
by
team.
Some
teams
do
UI

design,
some
code
reviews,
etc.
Create
a
column
for
each
step.

If
you
can
totally
eliminate
a
step
later
(do
you
really
need
that
Control
Board?),
do
so,
but
start
with

what
is,
not
what
you
wish
there
was.
Update
whole
en+re
structure
regularly
as
you
ﬁnd
ways
to

eliminate
handoﬀs
and
waste.


10

Input

Queue

UI
Design
Development
Acceptance
Test
Release

Ready

Visualize
“In
Process”
by
breaking

down
into
separate
steps

Your
deﬁni+ons
of
“Done”
can
iden+fy
steps

FLOW


11

Limit
WIP

•  We
make
a
commitment
to
limit
the
Work-‐In-‐
Progress
(WIP)

– Prevents
context
switching

– Performing
tasks
sequen+ally
yields
results
sooner

•  Focusing
more
on
ﬁnishing
work
we’ve
already

taken
on,
versus
just
star+ng
new
work

•  Enhance
teamwork

– Increase
cross-‐func+onality


12

To
Do
UI

Design

Done

Why
is
so
liZle
gepng
done?

Work
in
Progress
BoZlenecks
!
!
!

Jim

Sue

Mark

Paul

Jim

Ken

Sue

Sue

Sue
Sue

Ken

Ken

Paul

Mark

Sue

Mark

Sue

Development
Manual

Test

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


13

Queue
Limits
&
WIP
Limits
Avoid

Premature
Work
and
Mul+-‐Tasking

WIP
Limit
prevents
Queue
Limit
prevents


14

In

Process

In

Process

In

Process
Queue
Queue
Queue

User

Stories

Step
1
Step
2
Step
n
Done

.
.
.

.
.
.

Manage
Flow

•  The
ﬂow
of
work
through
each
state
in
the

workﬂow
should
be
monitored,
measured
and

reported

•  Work
is
pulled
not
pushed
through
the
system

•  Allows
you
to
quickly
iden+fy
boZlenecks
in

produc+on/work

– Toyota
produc+on
line
example


15

Input

Queue

UI
Design
Development
Dev

Ready

Test

Ready

Test
Release

Ready

In
Prog

Done
In
Prog

Done
In
Prog

5
3
3
5
4
2

WIP

Limits
BLOCKED!
Can’t
move
ahead

FLOW

Queue

Limit


16

Con+nuous
Improvement

•  Start
with
what
you
do
now

•  Respect
the
current
process,
roles,

responsibili+es
&
+tles

•  Agree
to
pursue
incremental,
evolu+onary

change

– Team
empowered
to
suggest
changes

“Nothing else in their world should have changed. Jobs, activities,
handoffs, and artifacts are the same. Their process hasn’t changed,
other than you asking them to accept a WIP limit and to pull work….”
- David Anderson

17

Input

Queue

UI
Design
Development
Dev

Ready

Test
Ready
Test
Release

Ready

In
Prog

Done
In
Prog

Done
In
Prog

5
3
3
5
4
2

WIP

Limits
BLOCKED!
Can’t
move
ahead

FLOW

Queue

Limit


18

But…..

•  But
what
about
unexpected
cri+cal
work?

– Expedite
lane

•  But
some
of
my
tasks
are
more
important
than

others!

– Class
of
Service
(CoS)

•  But
what
about
tasks
that
are
blocked?

– There
are
ways
to
handle
this
and,
more

importantly,
to
measure
the
impact
of
these

blocked
tasks.


19

A
Kanban
Board
at

WIP
Limits

Metrics

FLOW


20

Kanban
Board
with
Swim
Lanes

(2
feature
sets,
1
bug
ﬁx)

Features

Maintenance
&

Improvement


21

Possible
Metrics

•  Day
finished
–
Day
entered
queue
=
Wait
Time

•  Day
finished
–
Day
started
=
Time
to
Complete

•  Average
wait
+me

•  Average
+me
to
complete

•  Averages
per
CoS

•  Standard
devia+on

•  Metrics
for
unusual
events
(e.g.
field
crisis,

special
event,
emergencies)


22

Metrics
Example

Many
tool

companies
now

have
tools
that

support
Kanban.

Alterna+vely

white
boards,

s+cky
notes
and

Excel
spread

sheets
provide

the
ul+mate
in

ﬂexibility
and

they
are
cheep.


23

Where
Kanban
Is
Especially
Needed

•  Large
organiza+ons
with
mul+ple
teams
(also
to

organize
2nd
4er
Scrum
teams)

•  Teams
that
aren’t
fully
cross
func+onal
(e.g.
missing

full
+me
DBA,
Tester,
Deployment
Specialist,
etc.)

•  Teams
that
don’t
have
a
standard
itera+on/sprint

cadence
(e.g.
maintenance
bug
ﬁx
teams,
system

engineering
teams,
etc.)

•  Teams
that
receive
unplanned
emergency
work

•  Teams
that
support
mul+ple
customers
or
Classes
of

Service

•  Teams
or
organiza+on
that
need
beZer
metrics


24

Bibliography

•  ”Kanban
101”
-‐
Jessie
Link,
November
2011

•  “Kanban”
by
David
J.
Anderson
ISBN

9780984521401

•  “Scrumban”
by
Corey
Ladas
ISBN

9780578002149

•  “Lean
from
the
Trenches”
by
Henrik
Kniberg
ISBN
139781934356852


25

Webliography

•  Limited
WIP
Society/KanbanDev:
User
group
discussing
development
using
Kanban
for

technology
business
hZp://www.limitedwipsociety.org/

•  DZone
Refcard
109
“Gepng
Started
with
Kanban
for
SoAware
Development”
by
David

J.
Anderson
and
Janice
Linden-‐Reed
hZp://www.dzone.com/

•  BTI360
Blog
“Kanbanima+on”
by
Clinton
Wivell

hZp://b+360.com/pages/page.asp?page_id=91490&hlFilter=topic&hlCriteria=1797

•  Agile
Agility
“Kanban,
Flow
and
Cadence”
by
Karl
Scotland

hZp://availagility.co.uk/2008/10/28/kanban-‐flow-‐and-‐cadence/

•  LeanKit
Kanban
“Simplifying
Project
Management”
hZp://blog.leankitkanban.com/
landing/smpl/?gclid=CPPtrJOHlK4CFRIDQAodsRWn9w

•  Lean
SoAware
Engineering
“PaZerns
of
SoAware
Engineering
Workflow”
by
Corey

Ladas
hZp://leansoAwareengineering.com/2009/06/08/workflow-‐paZerns/


26

Camille
Bell

Agile
Coaching
&
Consul+ng

Retrospec+ves

Agile
Boot
Camps

Agile
Training

Updated
Slides

or
just
to
chat
about
things
agile


Kanban Introduction for Agile Teams

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Kanban Introduction for Agile Teams

Similar to Kanban Introduction for Agile Teams (20)

More from Camille Bell

More from Camille Bell (7)

Recently uploaded

Recently uploaded (20)

Kanban Introduction for Agile Teams