This document summarizes a presentation on transitioning a team to using Kanban. It discusses the motivations for adopting Kanban, provides an overview of Kanban principles and practices, and shares the experience of one team at Constant Contact that transitioned to Kanban. This included mapping their workflow, establishing work in progress limits, defining policies, tracking metrics like cycle time, and evolving their process over time to achieve continuous flow and delivery.

1. Copyright © 2011 Constant Contact Inc. Transitioning Your Team to Kanban: Theory and Practice Gil Irizarry & Susan Jacobs Constant Contact June 2011

3. Theory –

4. Motivations

5. Background

6. What is Kanban and how does it work

7. Practice –

8. Setting up a Kanban board

10. Over 20 years software development and management experience, over 5 years in an agile software development environment

11. CSM and PMP certifications, Kanban coaching training with David Anderson

12. BS from Cornell, ALM from Harvard, certificate in Management from MIT Sloan

14. BS degree in Computer Science / Information Science from Binghamton University

16. >$200MM gross revenue per year

17. >800 employees

18. >450K paying customers

19. Engineering and Operations total about 150 people

21. React quicker to changing market conditions

22. Get new features to users more quickly

23. Frequent releases are smaller releases

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

27. Daily stand-ups

28. What did you do yesterday, what did you do today, any impediments

29. Retrospectives

30. Burn-down chart

33. Build Quality In

34. Create Knowledge

35. Defer Commitment

36. Deliver Fast

37. Respect People

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

40. Agree to pursue incremental, evolutionary change

41. Respect the current process, roles, responsibilities & titlesFrom: http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method (David Anderson)

43. Team board states are a reflection of the value stream

44. Limit WIP

45. Manage Flow

46. Implied that flow should be continuous

47. Make Process Policies Explicit

49. Copyright © 2011 Constant Contact, Inc. 15 Pigs vs. Chickens?

50. Copyright © 2011 Constant Contact, Inc. 16 No! You are a team

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

52. Copyright © 2011 Constant Contact, Inc. 18 Sample Value Stream From http://en.wikipedia.org/wiki/Value_stream_mapping

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

56. Less multitasking

57. Less time lost to context switching

58. Better quality

60. We manage this through the concept of classes of service. Similar projects are grouped into classes and each class is assigned an allocation.

63. Teams test continuously

64. 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

65. It’s OK if a team starts work for the next release in the current release

67. Cycle time on items after grouping them by size:

68. Completion time for small, medium and large

69. Spread of cycle times

70. Work items completed

72. So, over time, an estimate of completion time for items of a given size should become more accurate.

73. 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.

76. Implementing Lean Software Development: From Concept to Cash - by Mary Poppendieck and Tom Poppendieck

77. Scrumban - Essays on Kanban Systems for Lean Software Development - by Corey Ladas

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

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

83. Sprint planning consumed the team for an entire day.

84. Most of the work for a sprint was getting completed all at once, close to the end of the sprint.

85. QA had nothing to do at the beginning of a sprint, but were overworked at the end.Copyright © 2011 Constant Contact, Inc. 31

87. We asked the teams to map out their current development process.

88. It was really complicated…Copyright © 2011 Constant Contact, Inc. 32

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

91. Don’t overthink the initial WIP limit, it will change based on metrics.

92. Start WIP limit at 1.5X the number of team members.

93. That WIP limit is for the whole board.

94. Divide total WIP amongst the columns, whatever feels right.

95. Take photos of the board daily for Cumulative Flow Diagram.Copyright © 2011 Constant Contact, Inc. 34

96. Week 2 – Patterns emerge Copyright © 2011 Constant Contact, Inc. 35 Verify column over limit Blocked Items Work not on board

97. Week 4 – Board Changes Copyright © 2011 Constant Contact, Inc. 36 Wait states Less columns Team adding policies

99. Policies are the requirements that must be met before an item is considered ready for the next state.

100. Policies were written down in a wiki and posted on the board.

101. The team frequently ignores policies, so the scrum master has to keep them honest ;-). Copyright © 2011 Constant Contact, Inc. 37

102. Copyright © 2011 Constant Contact, Inc. Items Tasks Week 5 – Items broken into Tasks 38

103. One Team – Single Flow Copyright © 2011 Constant Contact, Inc. 39 Item and task type by color Produce Todo Bugs & Footprints on board WIPL = 6 full items Visible policies

105. Perceived lack of predictability compared to Scrum was an issue.

106. By tracking Cycle Time, we can eventually provide Service Level Agreements to stakeholders.

107. SLA = Avg. Cycle Time + 2(Standard Deviation)Copyright © 2011 Constant Contact, Inc. 40

108. Cycle Times – May 2011 Copyright © 2011 Constant Contact, Inc. 41 SLA = Avg. Cycle Time + 2(Standard Deviation)

109. Cycle Times Copyright © 2011 Constant Contact, Inc. 42

110. Cycle Time Standard Deviation Copyright © 2011 Constant Contact, Inc. 43

112. 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.

115. Worked on more constant delivery

116. Identified a bottleneck with source control

117. Changed our branching strategy to improveCopyright © 2011 Constant Contact, Inc. 46 Before After

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

121. Today Copyright © 2011 Constant Contact, Inc. 50 New classes of service

122. Conclusion Copyright © 2011 Constant Contact, Inc. 51 Thanks For Spending This Time With Us