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

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

40. Agree to pursue incremental, evolutionary change

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

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.

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

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.

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.

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.

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