1. Transitioning Your Team to Kanban: Theory and
Practice
Project Summit &
BusinessAnalystWorld: Boston
Gil Irizarry
Constant Contact
Copyright © 2011 Constant Contact Inc.

2. 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
Copyright © 2011 Constant Contact, Inc. 2

3. Agenda
• A bit about me and Constant Contact
• Theory –
• Motivations
• Background
• What is Kanban and how does it work
• Practice –
• Setting up a Kanban board
• Establishing policies and limits
Copyright © 2011 Constant Contact, Inc. 3

4. My background
• Program Manager at Constant Contact
• 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
• girizarry@constantcontact.com, gil@conoa.com
• http://www.slideshare.net/conoagil
Copyright © 2011 Constant Contact, Inc. 4

5. Background on Constant Contact
• SaaS company offering on-line e-mail marketing,
event marketing and surveys. Recent
enhancements extend the services to the social
media space
• >$200MM gross revenue per year
• >850 employees
• >475K paying customers
• Engineering and Operations total about 150
people
• First Scrum team formed in 2006
Copyright © 2011 Constant Contact, Inc. 5

6. Motivations
• We want to move to Agile management methods.
Why?
• React quicker to changing market conditions
• Get new features to users more quickly
• Frequent releases are smaller releases
• Better Quality
Copyright © 2011 Constant Contact, Inc. 6

7. Quick Review of Scrum
• Fixed iterations
• Daily stand-ups
• What did you do yesterday, what did you do
today, any impediments
• Retrospectives
• Burn-down chart
• Board with To Do, In Progress and Done
states
Copyright © 2011 Constant Contact, Inc. 7

8. 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
Copyright © 2011 Constant Contact, Inc. 8

9. 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_pr
inciples_of_the_kanban_method (David Anderson)
Copyright © 2011 Constant Contact, Inc. 9

10. 5 Core Properties of Kanban
• Visualize the workflow
• Team board states are a reflection of the
value stream
• Limit WIP
• Manage Flow
• Implied that flow should be continuous
• Make Process Policies Explicit
• Improve Collaboratively (using models & the
scientific method)
Copyright © 2011 Constant Contact, Inc. 10

11. Kanban and Roles
• Prioritization
• Definition
• Ready-Ready
Org
• Work mgmt.
• Delivery
• Metrics
• Flow
• Improvement
Lead Team
Copyright © 2011 Constant Contact, Inc. 11

12. You are one team!
Copyright © 2011 Constant Contact, Inc. 12

13. Value Mapping Exercise
How do you make dinner?
Copyright © 2011 Constant Contact, Inc. 13

14. Sample Value Stream
Shop Unpack Cook
Value: for food groceries Food Eat!
30 min 5 min 15 min
Drive to Drive Wash Serve
No
market home Pots Dinner
Value:
30 min 30 min 15 min 5 min
50 min / 130 min = 38% efficiency
Copyright © 2011 Constant Contact, Inc. 14

15. 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
Copyright © 2011 Constant Contact, Inc. 15

16. Sample Kanban Board
States
WIP Limits
Classes of Service
Copyright © 2011 Constant Contact, Inc. 16

17. 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:
Copyright © 2011 Constant Contact, Inc. 17

18. Limit WIP
• Why?
• Less multitasking
• Less time lost to context switching
• Better quality
• Smoother flow
Copyright © 2011 Constant Contact, Inc. 18

19. 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
Copyright © 2011 Constant Contact, Inc. 19

20. Sample CFD
60
What happened here?
50
40
User Story
Mockups
Lead Time Cycle Time Ready-Done
30
In Development
WIP Dev Done
In Testing
20 Complete
10
Potential Bottlenecks
0
11/9/2010 12/9/2010 1/9/2011 2/9/2011 3/9/2011 4/9/2011
Copyright © 2011 Constant Contact, Inc. 20

21. 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
Copyright © 2011 Constant Contact, Inc. 21

22. 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
• Open defects in production, to give a high-
level approximation of technical debt
Copyright © 2011 Constant Contact, Inc. 22

23. 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
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
Copyright © 2011 Constant Contact, Inc. 23

24. 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
(large - 5 Story Points)
5
0
2010 R7 2010 R8 2011 R1 2011 R2 2011 R3 2011 R4
Copyright © 2011 Constant Contact, Inc. 24

25. Kanban in practice
Copyright © 2011 Constant Contact, Inc. 25

26. Why Kanban?
• Shorter sprint lengths were forcing us to
artificially break up items in order to fit within
sprint 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.
• QA had nothing to do at the beginning of a
sprint, but were overworked at the end.
Copyright © 2011 Constant Contact, Inc. 26

27. 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…
Copyright © 2011 Constant Contact, Inc. 27

28. Mapping the Value Stream
Copyright © 2011 Constant Contact, Inc. 28

29. How do you set a WIP limit?
• Setting WIP limit is more art than science.
• Don’t overthink the initial WIP limit, it will
change based on metrics.
• Start WIP limit at 1.5X the number of team
members.
• That WIP limit is for the whole board.
• Divide total WIP amongst the
columns, whatever feels right.
• Take photos of the board daily for Cumulative
Flow Diagram.
Copyright © 2011 Constant Contact, Inc. 29

30. Policies
• The team defined policies for moving items into
each state.
• Policies are the requirements that must be met
before an item is considered ready for the next
state.
• Policies were written down in a wiki and posted
on the board.
• The team frequently ignores policies, so the
scrum master has to keep them honest ;-).
Copyright © 2011 Constant Contact, Inc. 30

31. One Team – Single Flow
Produc
e
Tod
o
Item and task
type by color
Bugs & Footprints on board
WIPL = 6 full items
Visible policies
Copyright © 2011 Constant Contact, Inc. 31

32. Metrics are the Key to Improvement
• Cycle Time – Elapsed time from Design to
Release to Production
• Perceived lack of predictability compared to
Scrum was an issue.
• By tracking Cycle Time, we can eventually
provide Service Level Agreements to
stakeholders.
• SLA = Avg. Cycle Time + 2(Standard Deviation)
Copyright © 2011 Constant Contact, Inc. 32

33. Cumulative Flow Diagram
• QA overloaded
• Worked on more constant delivery
• Identified a bottleneck with source control
• Changed our branching strategy to improve
Copyright © 2011 Constant Contact, Inc. 33

34. Cumulative Flow Diagram
• By September, we’re now releasing twice a week to Production
• Much smoother CFD, continuous deliver improves cycle time
Copyright © 2011 Constant Contact, Inc. 34

35. One Year Later…
New classes of
Copyright © 2011 Constant Contact, Inc.
service 35

36. What were our 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
Copyright © 2011 Constant Contact, Inc. 36

37. 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/
Copyright © 2011 Constant Contact, Inc. 37

38. Conclusion
Thank you!
Copyright © 2011 Constant Contact, Inc. 38