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

13. girizarry@constantcontact.com, gil@conoa.com

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

17. >$200MM gross revenue per year

18. >800 employees

19. >470K paying customers

20. Engineering and Operations total about 150 people

23. React quicker to changing market conditions

24. Get new features to users more quickly

25. Frequent releases are smaller releases

27. Daily stand-ups

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

29. Retrospectives

30. Burn-down chart

32. Build Quality In

33. Create Knowledge

34. Defer Commitment

35. Deliver Fast

36. Respect People

39. Agree to pursue incremental, evolutionary change

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

43. Limit WIP

44. Manage Flow

45. Implied that flow should be continuous

46. Make Process Policies Explicit

55. Less multitasking

56. Less time lost to context switching

57. Better quality

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

62. Teams test continuously

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

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

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

67. Completion time for small, medium and large

68. Spread of cycle times

69. Work items completed

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

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

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

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

79. I was a Principal Engineer at the time. I’m currently the Engineering Manager of our advanced editor team.

80. Mike Fitterman (currently Director of Engineering) and Rick Simmons introduced Kanban to the team.

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

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

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

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

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

92. That WIP limit is for the whole board.

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

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

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

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

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

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

114. Worked on more constant delivery

115. Identified a bottleneck with source control