Transitioning to Kanban

Copyright © 2011 Constant Contact Inc.

Transitioning Your Team to Kanban: Theory and Practice

Gil Irizarry & Susan JacobsConstant Contact

June 2011

2Copyright © 2011 Constant Contact, Inc.

Agenda

• A bit about us and Constant Contact

• Theory –

• Motivations

• Background

• What is Kanban and how does it work

• Practice –

• Setting up a Kanban board

• Establishing policies and limits


Gil’s 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

• [email protected], [email protected]


Susan’s background

• Engineering Manager, Website Team at Constant Contact

• BS degree in Computer Science / Information Science from Binghamton University

• [email protected], Twitter: @sjacobs146


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

• >800 employees

• >450K paying customers

• Engineering and Operations total about 150 people

• First Scrum team formed in 2006


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


A little review: how things used to be


This is appropriate if you are building an…

“Originally planned to enter service in May 2008, the [Dreamliner] project has suffered from repeated delays and is now more than three years behind schedule.” -- Wikipedia


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


Digression (or maybe not)

An excellent retelling of the early days of Southwest Airlines can be found in Leading Lean Software Development: Results Are not the Point by Mary and Tom Poppendieck


Lean Principles

• Eliminate Waste

• Build Quality In

• Create Knowledge

• Defer Commitment

• Deliver Fast

• Respect People

• Optimize the WholeLeading Lean Software Development: Results Are not the Point by Mary and Tom Poppendieck


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_principles_of_the_kanban_method (David Anderson)

http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method

http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method


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)


Kanban and Roles

Lead Team

Org

• Prioritization• Definition• Ready-Ready

• Work mgmt.• Metrics• Improvement

• Delivery• Flow


Pigs vs. Chickens?


No! You are a team


Value Mapping Exercise

How do you make dinner?


Sample Value Stream

From http://en.wikipedia.org/wiki/Value_stream_mapping

http://en.wikipedia.org/wiki/Value_stream_mapping


Sample Kanban Board

States

Cla

sses o

f S

erv

ice

WIP Limits


Pull, not Push

• Work items should be pulled into available lanes

• Work should not be pushed when completed, even if its lane is full


Limit WIP

• Why?

• Less multitasking

• Less time lost to context switching

• Better quality

• Smoother flow


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


Sample CFD

11/9

/201

0

11/1

5/20

10

11/2

1/20

10

11/2

7/20

10

12/3

/201

0

12/9

/201

0

12/1

5/20

10

12/2

1/20

10

12/2

7/20

10

1/2/

2011

1/8/

2011

1/14

/201

1

1/20

/201

1

1/26

/201

1

2/1/

2011

2/7/

2011

2/13

/201

1

2/19

/201

1

2/25

/201

1

3/3/

2011

3/9/

2011

3/15

/201

1

3/21

/201

1

3/27

/201

1

4/2/

2011

4/8/

2011

4/14

/201

1

4/20

/201

1

4/26

/201

10

10

20

30

40

50

60

User StoryMockupsReady-DoneIn DevelopmentDev DoneIn TestingComplete

Cycle Time

WIP

What happened here?

Lead Time

Potential Bottlenecks


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


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


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


2010 R7 2010 R8 2011 R1 2011 R2 2011 R3 2011 R40

5

10

15

20

25

30

35Average Cycle Times for work items

Average of Cycle Time (small - 1 Story Point)

Average of Cycle Time (medium - 3 Story Points)

Average of Cycle Time (large - 5 Story Points)


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/

http://www.netobjectives.com/


Kanban in practice


Kanban in Practice

• The Website team at Constant Contact started using Kanban in the Spring of 2009.

• I was a Principal Engineer at the time. I’m currently the Engineering Manager.

• Mike Fitterman (currently Director of Engineering) introduced Kanban to the team.

• It has been an evolutionary process.

Copyright © 2011 Constant Contact, Inc. 31

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.


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…


Mapping the Value Stream


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.


Week 2 – Patterns emerge

Verify column over limit

Blocked Items

Work not on board


Week 4 – Board Changes

Wait states Less columns Team adding policies


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 ;-).


Items Tasks

Week 5 – Items broken into Tasks


One Team – Single Flow

Produce

Todo Item and task

type by color

WIPL = 6 full items

Bugs & Footprints on board

Visible policies


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)

Cycle Times – May 2011

Size Average Cycle Time

Cycle Time Std. Deviation

SLA

Sand 2.4 3.6 9.6

Pebble

7.9 5.4 18.7

Rock 13.7 2.5 18.7

Bugs 3.7 3.5 10.7


SLA = Avg. Cycle Time + 2(Standard Deviation)

Cycle Times


Nov-09

Dec-09

Jan-10

Feb-10

Mar-10

Apr-10

May-10

Jun-10Jul-1

0

Aug-10

Sep-10

Oct-10

Nov-10

Dec-10

Jan-11

Feb-11

Mar-11

Apr-11

0

10

20

30

40

50

60

70

BugsFootprintsSmallMediumLarge

Cycle Time Standard Deviation


Nov-09

Dec-09

Jan-10

Feb-10

Mar-10

Apr-10

May-10

Jun-10Jul-1

0

Aug-10

Sep-10

Oct-10

Nov-10

Dec-10

Jan-11

Feb-11

Mar-11

Apr-11

0

5

10

15

20

25

30

35

40

45

50

Bugs SDFP SDSmall SDMedium SDLarge SD

Examine Outliers to improve Process

Item Size Days

BL12785 – Aberdeen Carousel Pebble 12

BL12785 – Aberdeen LP Pebble 18

BL2956 - SMB Week PR LP Pebble 15

BL12711 – Chamber Website Design Only

Pebble 12

FP1558 – Add Simple Share tutorial in LC

Sand 24


• Aberdeen – delays due to churn• SMB Week Landing Page – we decided to start work

despite the fact that many dependent assets were not ready. Stakeholder pressure to meet a deadline.

• Chamber Website Design, and Add Simple Share Tutorial for potential bottlenecks.

Throughput


Nov-09

Dec-09

Jan-10

Feb-10

Mar-10

Apr-10

May-10

Jun-10Jul-1

0

Aug-10

Sep-10

Oct-10

Nov-10

Dec-10

Jan-11

Feb-11

Mar-11

Apr-11

0

20

40

60

80

100

120

140

160

180

200

Bugs FixedItemsFPTotal Throughput


Cumulative Flow Diagram

• QA overloaded

• Worked on more constant delivery

• Identified a bottleneck with source control

• Changed our branching strategy to improve

Before After


Cumulative Flow Diagram

• By September, we’re now releasing twice a week to Production

• Much smoother CFD, continuous deliver improves cycle time

Business Value Metrics


Right Experience11%

Ongoing Service23%

Infrastructure14%Bugs

29%

Footprints22%

Recognize Returning Visitors1%

Total Cycle Time Spent

Right ExperienceOngoing ServiceInfrastructureBugsFootprintsRecognize Returning Visitors


One Year Later…

New classes of service


Today

New classes of service


Conclusion

Thanks For Spending This Time With Us