An Introduction to Scrum Tim McOwan KashFlow Software
Overview Case study & theory Scrum principles Roles, ceremonies & artifacts Planning Where next?
Presentation Framework from Except: Motivation theory slides Salesforce.com Exercises Story Point estimating Lean software development principles Miscellaneous other slides
“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
Case Study:Salesforce.com Started 2001 3 people in R & D 4 releases per year 2006 200+ in R & D 1 release per year – late!
Days between Major Releases Features Delivered per Team 2000 2001 2002 2003 2004 2005 2006
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
Transformation Results Days between Major Releases Features Delivered per Team 2000 2001 2002 2003 2004 2005 2006 2007
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
86 % of respondents are having the “best time” or a “good time” at Salesforce * Improved from 40% 15 months ago
Process and tools Individuals and interactions Following a plan Responding to change Comprehensive documentation Working software Contract negotiation Customer collaboration over over over over The Agile Manifesto – a statement of values Source: http://agilemanifesto.org
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
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
Exercise Possible benefits (negatives) of Scrum to Our organisation Post-Its, 5 minutes
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
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.
A short statement of what the work will be focused on during the sprint
Life Sciences Support features necessary for population genetics studies. Database Application Make the application run on SQL Server in addition to Oracle. Financial services Support more technical indicators than company ABC with real-time, streaming data.
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
Does Scrum do everything? What should we be doing in any event? 5 minutes, Post Its.
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
Scrum has been used on multiple 500+ person projects
Planning Estimating Road map!
User Stories Epics: A milestone (?) with many stories User Story Conversations Acceptance Criteria
Epics Think of a recent Epic… Good: 5 minutes, write some stories Choose a Story Write the conversations Write the acceptance criteria
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
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.
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
Scrum is not Magic It is simple... ...but hard work... ...and sometimes painful!