1. An Introduction to Scrum Tim McOwan KashFlow Software

2. Overview Case study & theory Scrum principles Roles, ceremonies & artifacts Planning Where next?

3. Presentation Framework from Except: Motivation theory slides Salesforce.com Exercises Story Point estimating Lean software development principles Miscellaneous other slides

4. “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.” Hirotaka Takeuchi and Ikujiro Nonaka, “The New New Product Development Game”, Harvard Business Review,January 1986. We’re losing the relay race

6. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).

7. The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.

9. Initial scrums at Easel Corp in 1993

10. IDX and 500+ people doing Scrum

11. Ken Schwaber

12. ADM

13. Scrum presented at OOPSLA 96 with Sutherland

14. Author of three books on Scrum

15. Mike Beedle

16. Scrum patterns in PLOPD4

17. Ken Schwaber and Mike Cohn

19. Yahoo

20. Google

21. Electronic Arts

22. High Moon Studios

23. Lockheed Martin

24. Philips

25. Siemens

26. Nokia

27. Capital One

28. BBC

29. Intuit

30. Nielsen Media

31. First American Real Estate

32. BMC Software

33. Ipswitch

34. John Deere

35. Lexis Nexis

36. Sabre

37. Salesforce.com

38. Time Warner

39. Turner Broadcasting

40. Oce

42. Days between Major Releases Features Delivered per Team 2000 2001 2002 2003 2004 2005 2006

43. Big Bang Scrum Application 1 late release  4 on time releases in 1 year +94% feature requests delivered (+38% pro rata) + 61%reduction in mean time to release 91% of customers believe quality has improved / remained the same

44. Transformation Results Days between Major Releases Features Delivered per Team 2000 2001 2002 2003 2004 2005 2006 2007

45. Salesforce Tips Focus on principles over mechanics Focus on automation Provide transparency When the heat is on stick to your guns Experiment, be patient and expect to make mistakes

46. 86 % of respondents are having the “best time” or a “good time” at Salesforce * Improved from 40% 15 months ago

47. Motivation Theory – Job Design

48. Motivation Theory – Psychological Contract

50. FDA-approved, life-critical systems

51. Satellite-control software

52. Websites

53. Handheld software

54. Mobile phones

55. Network switching applications

56. ISV applications

57. Some of the largest applications in use

58. Commercial software

59. In-house development

60. Contract development

61. Fixed-price projects

62. Financial applications

63. ISO 9001-certified applications

64. Embedded systems

65. 24x7 systems with 99.999% uptime requirements

67. Product progresses in a series of month-long “sprints”

68. Requirements are captured as items in a list of “product backlog”

69. No specific engineering practices prescribed

71. Project noise level Far from Agreement Anarchy Complex Requirements Complicated Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Simple Close to Agreement Technology Close to Certainty Far from Certainty

72. Sometimes Rarely 16% 19% Never Often 45% 13% Always 7% Wasted Effort Features and Functions Used in a Typical System Often or Always Used: 20% Rarely or Never Used: 64% Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

73. Exercise Possible benefits (negatives) of Scrum to Our organisation Post-Its, 5 minutes

74. The Sprint Cycle Sprint goal 24 hours Cancel Gift wrap Return Coupons Gift wrap Coupons Cancel Sprint backlog Sprint 2-4 weeks Return Potentially shippable product increment Scrum Product backlog

75. Putting it all together

77. Typical duration is 2–4 weeks or a calendar month at most

78. A constant duration leads to a better rhythm

80. Communication (Typical Model) Send

81. Communication (Shannon et al)

82. Sequential vs. overlapping development Requirements Design Code Test Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986.

84. ScrumMaster

85. Team

86. Product backlog

87. Sprint backlog

89. Sprint review

90. Sprint retrospective

92. ScrumMaster

94. Sprint review

95. Sprint retrospective

97. Sprint backlog

99. Decide on release date and content

100. Be responsible for the profitability of the product (ROI)

101. Prioritize features according to market value

102. Adjust features and priority every iteration, as needed

105. Responsible for enacting Scrum values and practices

106. Removes impediments

107. Ensure that the team is fully functional and productive

108. Enable close cooperation across all roles and functions

111. Cross-functional:

112. Programmers, testers, user experience designers, etc.

113. Members should be full-time

114. May be exceptions (e.g. database administrator)

115. Teams are self-organizing

116. Ideally, no titles but rarely a possibility

118. ScrumMaster

119. Team

120. Product backlog

121. Sprint backlog

123. Sprint review

124. Sprint retrospective

127. Create sprint backlog (tasks) from product backlog items (user stories / features)

128. Estimate sprint backlog in hoursCurrent product Technology

130. Sprint backlog is created

131. Tasks are identified and each is estimated (1-16 hours)

132. Collaboratively, not done alone by the ScrumMaster

133. High-level design is consideredAs a vacation planner, I want to see photos of the hotels.

134. Sprint Planning Who has what responsibilities? Post Its, 10 minutes

135. Sprint planning Talk : join in What is done? Ownership of estimates Learning opportunity of context

137. Daily

138. 15-minutes

139. Stand-up

140. Not for problem solving

141. Whole world is invited

142. Only team members, ScrumMaster, product owner, can talk

145. Daily Scrum What are your responsibilities? Post Its, 10 minutes

147. Typically takes the form of a demo of new features or underlying architecture

148. Informal

149. 2-hour prep time rule

150. No slides

151. Whole team participates

153. Typically 15–30 minutes

154. Done after every sprint

155. Whole team participates

156. ScrumMaster

157. Product owner

158. Team

160. Retrospectives What are your responsibilities? Post Its, 5 minutes

162. ScrumMaster

163. Team

164. Product backlog

165. Sprint backlog

167. Sprint review

168. Sprint retrospective

170. A list of all desired work on the project

171. Ideally expressed such that each item has value to the users or customers of the product

172. Prioritized by the product owner

173. Reprioritized at the start of each sprintThis is the product backlog

174. A sample product backlog

177. Work is never assigned

178. Estimated work remaining is updated daily

179. Any team member can add, delete or change the sprint backlog

180. Work for the sprint emerges

181. If work is unclear, define a sprint backlog item with a larger amount of time and break it down later

183. A sprint burndown chart Hours

184. 4 8 12 7 10 16 11 16 8 Tasks Mon Tues Wed Thur Fri Code the user interface 8 Code the middle tier 16 Test the middle tier 8 Write online help 12 50 40 30 Hours 20 10 0 Mon Tue Wed Thu Fri

185. Does Scrum do everything? What should we be doing in any event? 5 minutes, Post Its.

186. Lean Software Development Mary and Tom Poppendieck Waiting Queuing theory, steady state of arrival Task switching Partially done or ‘stored’ completed work Speed of fixing defects Options Create many Decide at last responsible moment Trade offs

188. Scalability comes from teams of teams

189. Factors in scaling

190. Type of application

191. Team size

192. Team dispersion

193. Project duration

195. User Stories Epics: A milestone (?) with many stories User Story Conversations Acceptance Criteria

196. Epics Think of a recent Epic… Good: 5 minutes, write some stories Choose a Story Write the conversations Write the acceptance criteria

197. Estimating using Story Points Relative complexity How long will story x take compared to story y? Still an estimate More thorough than other methods Takes into account productivity / efficiency of the team

198. Relative complexity – the Bridge metaphor 1 SP 8 SP 5 SP 3 SP 2 SP 20 SP 13 SP ? 100 SP 40 SP

199. Simple Velocity 3 simple wooden bridges in 1 sprint Velocity = 3 story points Alternatively: 1 simple wooden bridge and 1 basic concrete bridge 1 covered wooden bridge Team velocity increases and decreases New team members, change in environment etc.

200. Scrum Estimating Poker cards Deliberately increases exponentially to take into account: More uncertainty with bigger tasks Debate and discuss No back log item > 20 Sufficient estimating

201. Scrum is not Magic It is simple... ...but hard work... ...and sometimes painful!

202. Dilbert’s World

203. The art of the possible Unless you are Tom Cruise .. and we aren’t, although we are all taller than him! The impossible is… Still impossible

204. The art of the possible We do what we can Not what we cannot We cannot do xyz OK, What can we do?

206. www.scrumalliance.org

207. www.controlchaos.com

209. Agile Estimating and Planning by Mike Cohn

210. Agile Project Managementwith Scrum by Ken Schwaber

211. Agile Retrospectives by Esther Derby and Diana Larsen

212. Agile Software Development Ecosystems by Jim Highsmith

213. Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

214. Scrum and The Enterprise by Ken Schwaber

215. User Stories Applied for Agile Software Development by Mike Cohn

216. Lean Software Development by Mary & Tom Poppendieck