3. Scrum and Kanban at the team-level

5. Over 5 years in an agile software development environment

6. Most recently working with Kanban, prior to that Scrum and RUP

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

9. gil@conoa.com

11. >$200MM gross revenue per year

12. >800 employees

13. >450K paying customers

14. Engineering and Operations total about 150 people

16. Why?

17. React quicker to changing market conditions

18. Get new features to users more quickly

20. 5 development and testing server clusters

21. 2 production server clusters in 2 data centers (soon to be 3)

22. A code base that was first created around 2004 and built up over time

28. Daily stand-ups

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

30. Retrospectives

31. Burn-down chart

34. Hold a Scrum of Scrums

35. What happens if you have too many teams?

36. Hold a Scrum of Scrums of Scrums, and so on…

38. Agree to pursue incremental, evolutionary change

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

42. Limit WIP

43. Manage Flow

44. Implied that flow should be continuous

45. Make Process Policies Explicit

54. Prioritized project list

55. All At Once Planning

56. Classes of Service

57. (Near) Continuous integration and (mostly) automated regression testing

58. Dependency and deliverable review

60. Continuous delivery

64. Planning involves the identification of deliverables and dependencies.

65. Dependencies are discussed with dependent teams.

67. If they haven’t already, they determine their capacity and, based on the priorities, commit to a set of work.

68. This means that a team may have capacity to do work, but may not get to it in a release if that work pushes the operation team beyond its capacity.

70. We attempt to manage this through classes of service. We borrow a concept from Kanban that says similar projects are grouped into classes and each class is assigned an allocation.

72. Hudson for continuous integration

73. Puppet for automated deployments

74. Maven for managed builds

75. Selenium for automated testing

76. svn for source control and versioning

80. How do you handle all the testing at the end of the sprint? What if defects are found a day before the sprint ends?

81. If a deliverable misses a release (the train), it simply waits to capture the next one.

83. Releases must be short

84. Must have those tools for automated deployments

86. Teams test continuously

87. It’s OK if a team finds a defect on the last day of the release.

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

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

92. Completion time for small, medium and large

93. Spread of cycle times

94. Work items completed

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

97. We have eliminated planning poker. Work items are just sized as smalls or mediums and the average cycle times for those sizes from the last release become the estimate for the upcoming release.

100. More importantly, testing used to take 6 weeks. Now it takes 1 week. Testing used to be 50% of the release cycle, but now is just 20%.

101. We have a better picture of our release at any given moment