You're familiar with agile and, perhaps, practicing Scrum. Now you're curious about Kanban. Is it right for your project? How does Kanban differ from Scrum and other agile methodologies? From theory to practice, Gil Irizarry introduces Kanban principles and explains how Kanban's emphasis on modifying existing processes rather than upending them results in a smooth adoption. Instead of using time-boxed units of work, Kanban focuses on continuous workflow, allowing teams to incrementally improve and streamline product delivery. Explore how to move from Scrum to Kanban with new, practical techniques that can help your team quickly get better. Discover the use of cumulative flow diagrams, WIP (work-in-progress) limits, and classes of services. In a hands-on classroom exercise, you'll help create a value stream map, determine process efficiency, and experience techniques from the Kanban toolset. Come and grow your agile repertoire in the Kanban way.

1.
AT4
Concurrent Session
11/8/2012 10:15 AM
"Transitioning to Kanban:
From Theory to Practice"
Presented by:
Gil Irizarry
Yesmail
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073
888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

2. Gil Irizarry
Yesmail
Gil Irizarry has worked in software development for more than twenty years as a
software developer and engineering manager in both corporate and start-up
environments. Gil is currently lead project manager at Yesmail, managing their
transition to Lean and guiding the implementation of new project workflows. Gil mentors
and trains teams on Agile and Kanban. A frequent speaker at conferences, Summits,
and local chapters of the PMI, Gil is a Certified ScrumMaster (CSM), a Kanban coach,
and has been a certified Project Management Professional (PMP). Reach him at
gil@conoa.com.

3. Transitioning Your
Team To Kanban:
Theory and Practice
Gil Irizarry
Lead Project Manager
November 2012
Learning Objectives
• Learn what Kanban is
• Learn value stream mapping and how to apply it to
your team
• Learn how to read a cumulative flow diagram
2
1

4. Agenda
• A bit about me
• Theory
• Motivations
• Background
• What is Kanban and how does it work
• Practice
• Setting up a Kanban board
• Establishing Policies and Limits
3
My background
• Lead Project Manager at Yesmail/Infogroup
• Over 20 years software development and
management experience, over 5 years in an agile
software development environment
• CSM and PMP certifications, Kanban coaching
training with David Anderson
• BS from Cornell, ALM from Harvard, certificate in
Management from MIT Sloan
• E-mail: gil@conoa.com
• http://www.slideshare.net/conoagil
4
2

5. Motivations
• We want to move to Agile management methods.
Why?
y
•
•
•
•
React quicker to changing market conditions
Get new features to users more quickly
Frequent releases are smaller releases
Better Quality
5
Quick Review of Scrum
• Fixed Iterations
• Daily Stand-ups
• What did you do yesterday, what will you do today,
any impediments?
• Retrospectives
• Burn-down chart
• Board with To Do, In Progress, and Done states
6
3

6. Lean Principles
•
•
•
•
•
•
•
Eliminate Waste
Build Quality In
Create Knowledge
Defer Commitment
Deliver Fast
Respect People
Optimize the Whole
Leading Lean Software Development: Results Are Not the
Point by Mary and Tom Poppendieck
7
What is Kanban?
• A scheduling system that tells you what to
produce, when to produce it, and how much to
produce.
produce
• An effective tool to support the running of the
production system as a whole.
• An excellent way for promoting improvements
because reducing the number of work cards in
circulation highlighted problem areas
i l ti hi hli ht d
bl
Wikipedia: http://en.wikipedia.org/wiki/Kanban
8
4

7. Foundational Principles of Kanban
• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities
& titles
From:http://agilemanagement.net/index.php/Blog/the_princip
les_of_the_kanban_method (David Anderson)
9
5 Core Properties of Kanban
• Visualize the workflow
• Team board states are a reflection of the value
stream
t
• Limit WIP
• Manage Flow
• Implied that flow should be continuous
• Make Process Policies Explicit
• Improve Collaboratively (using models & the
scientific method)
10
5

8. Kanban and Roles
Org
• Work mgmt.
• Metrics
•I
Improvement
• Prioritization
• Definition
• Ready-Ready
• Delivery
• Flow
o
Lead
Team
11
You are one team!
12
6

9. Value Mapping Exercise
How do you make dinner?
13
Sample Value Stream
Shop
for food
30 min
Value:
No
Value:
Drive to
market
30 min
Cook
Food
15 min
Unpack
groceries
5 min
Drive
home
30 min
Wash
Pots
15 min
Eat!
Serve
Dinner
5 min
50 min / 130 min = 38% efficiency
14
7

10. Map the value stream in your group/dept./firm
• Work with your teams or teams on which you are
dependent in order to drive more efficiency
15
Sample Kanban Board
States
Classes of Service
WIP Limits
16
8

11. Pull, not Push
• Work items should be pulled into available lanes
• Work should not be pushed when completed, even
if its lane is full
Pull:
Push:
17
Limit WIP
• Why?
•
•
•
•
Less multitasking
Less time lost to context switching
Better quality
Smoother flow
18
9

12. Classes of Service
• Different types of work need to be handled and
prioritized differently
• We manage this through the concept of classes of
service. Similar projects are grouped into classes
and each class is assigned an allocation.
• For example, we may decide that 20% of ops time
should be spent on infrastructure improvements,
and 80% spent on servicing development
19
Sample CFD
60
What happened here?
50
40
User Story
30
Mockups
Lead Time
Cycle Time
Ready-Done
In Development
WIP
Dev Done
20
In Testing
Complete
10
Potential Bottlenecks
11/9/2010
11/12/2010
11/17/2010
11/22/2010
11/25/2010
11/30/2010
12/3/2010
12/8/2010
12/13/2010
12/16/2010
12/21/2010
12/24/2010
12/29/2010
1/3/2011
1/6/2011
1/11/2011
1/14/2011
1/19/2011
1/24/2011
1/27/2011
2/1/2011
2/4/2011
2/9/2011
2/14/2011
2/17/2011
2/22/2011
2/25/2011
3/2/2011
3/7/2011
3/10/2011
3/15/2011
3/18/2011
3/23/2011
3/28/2011
3/31/2011
4/5/2011
4/8/2011
4/13/2011
4/18/2011
4/21/2011
4/26/2011
4/29/2011
0
20
10

13. Team Kanban
• Teams plan continuously. Backlogs should be
constantly groomed.
• Teams test continuously
• It’s OK if a team finds a defect on the last day of
the release. Pull the feature or delay the release,
but keep the flow continuous
• It’s OK if a team starts work for the next release in
the current release
• Aim for development and testing to flow more
smoothly through your system
21
Metrics
• Considering gathering the following:
• Cycle time on items after grouping them by
size:
• Completion time for small, medium and large
• Spread of cycle times
• Work items completed
p
production, to g
, give a high-level
g
• Open defects in p
approximation of technical debt
22
11

14. Metrics guide planning and estimation
• Over time, we would expect that the spread of
cycle times for a given item size goes down.
• So over time an estimate of completion time for
So,
time,
items of a given size should become more
accurate.
• Work items can be sized by t-shirt sizes (smalls,
mediums or larges) and the average cycle times
for those sizes from the last release become the
estimate for the upcoming release.
• Large items should in most cases be broken
down into smaller items
23
Average Cycle Times for work items
35
30
25
20
Average of Cycle Time
(small - 1 Story Point)
15
Average of Cycle Time
(medium - 3 Story
Points)
10
Average of Cycle Time
( g
(large - 5 Story Points)
y
)
5
0
2010 R7
2010 R8
2011 R1
2011 R2
2011 R3
2011 R4
24
12

15. Kanban in practice
Why Kanban?
• Shorter sprint lengths were forcing us to
artificially break up items in order to fit within
sprint boundaries
boundaries.
• Sprint planning consumed the team for an entire
day.
• Most of the work for a sprint was getting
completed all at once, close to the end of the
sprint.
i t
• QA had nothing to do at the beginning of a sprint,
but were overworked at the end.
26
13

16. Mapping the Value Stream
• At the time, the Website team was really 2
teams, Engineering and Design.
• We asked the teams to map out their current
development process.
• It was really complicated…
27
Mapping the Value Stream
28
14

17. One Team – Single Flow
Produc
e
Item and task
type by color
Tod
o
Bugs & Footprints on board
WIPL = 6 full items
Visible policies
29
Cumulative Flow Diagram
•
•
•
•
QA overloaded
Worked on more constant delivery
Identified a bottleneck with source control
Changed our branching strategy to improve
30
15

18. Cumulative Flow Diagram
• Later, we’re now releasing twice a week to
Production
• Much smoother CFD, continuous deliver improves
cycle time
31
One Year Later…
32
16

19. Resources
• Kanban by David J Anderson
• Implementing Lean Software Development:
From Concept to Cash - by Mary
Poppendieck and Tom Poppendieck
• Scrumban - Essays on Kanban Systems for
Lean Software Development - by Corey
Ladas
• http://www.netobjectives.com/
33
Thank you!
17