Scrum for Managers Microsoft Corporation / TechTalk Zurich Switzerland March 2010 About Mitch Lacey Mitch Lacey 13+ years of program and project management experience Microsoft Program Manager 2001 2006 Released large backend core services for Windows Live & MSN Worked as Agile Coach, onboarding teams to Scrum and Agile principles and practices Project Management Professional (PMP) Certified Scrum Trainer (CST) 2 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 1
Question What is the role of the manager? In Scrum? 3 4 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 2
What is Agile? A set of Values & Principles (The Manifesto) A set of Practices (The Methods) Most Importantly, agile is a Mindset and Different way of working to realize business value sooner 5 What Agile is Not It is not a silver bullet Nor is it a single method Also, it is not a set of tools 6 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 3
Scrum Principles Focus Respect Commitment Openness Courage 7 The Agile Manifesto 2001 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Authors: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas 8 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 4
Agile Practices the Agile Umbrella Scrum Crystal Clear extreme Programming DSDM Feature Driven Development 9 10 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 5
Why Choose Agile? Far from Agreement Anarchy Requirements Complex Close to Agreement Simple Close to Certainty Technology Far from Certainty Source: Strategic Management and Organizational Dynamics by Ralph Stacey. 11 Why Agile? I ve got work to do, I don t have time for this. Raise your hand if you have ever Missed a release date Missed your customer s expectations Gone over budget Had requirements change mid project Lose people in the middle of a project 12 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 6
Einstein on Insanity Doing the same thing over and over again and expecting different results 13 Defined (Traditional) Approach, AKA Waterfall 14 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 7
Hurdles with Defined Approaches Stakeholders Not Sure What They Want As Product Develops, Minds / Business Goals Change Details Often Revealed During Development Internal & ExternalForces Leadto Changes or Enhancements 15 Empirical Approach 16 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 8
Daily, Weekly, Monthly Checkpoints Requirements are Gathered Over Time The Project can Adapt To Meet Business Need Course Corrections Made as Product Develops 17 Agile versus Waterfall 18 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 9
Agile in Practice Sprint 3 Sprint 2 Sprint 1 RTM 1.0 Release able Pro oduction grade ness Us efulness Time Functional capacity 19 20 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 10
The Scrum Framework 21 What is Scrum? An agile, lightweight framework for Project Management Wraps existing engineering practices Is used to manage and control software and product development using iterative, incremental practices Is driven by daily and monthly feedback loops Is ideally suited for projects with rapidly changing or highly emergent requirements. And most of all, Scrum is FUN! 22 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 11
Scrum Focus Focus on customer value Deliver small chunks of value and in short cycles Be predictable by gathering gdata and adjusting, rather than betting on the perfect plan Empower people and teams to be self managing 23 Managing Risk Risk of not pleasing the customer Mitigated through frequent delivery and feedback Risk of poor predictability (estimation & planning) Mitigated through constant prioritization and estimation Risk of not resolving issues promptly Mitigated by daily progress meetings Risk of not being able to ship Mitigated by monthly releases Risk of over commitment and interruption Mitigated by locking and loading for the Sprint duration 24 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 12
Scrum Promotes Transparency and Exposes Impediments Bad practices exposed as impediments If your project is on track The reliability of your work estimates A better way to do things 25 Which do you Prefer? 26 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 13
The Scrum Team Product Owner ScrumMaster Core Team 27 The ScrumMaster Specially formulated to provide outstanding Protection Guidance Leadership Impediment Removal Will ensure a long lasting, high performing team 28 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 14
The Product Owner Providing the Fuel & Direction 29 The Scrum Team 30 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 15
10 13 16 19 22 25 28 Scrum for Managers, Zurich March 2010 Progress in Scrum 400 350 Workitem Hours 300 250 200 150 100 50 0 Pending In Progress Complete Remaining Trend 1 4 7 Calendar Days 31 Sprint Backlog Data Analysis Calendar Day 1 2 3 4 5 6 7 Date 16 Apr 07 17 Apr 07 18 Apr 07 19 Apr 07 20 Apr 07 21 Apr 07 22 Apr 07 Total Hours Remaining 202 183.5 165 123.5 118 118 118 Hours Worked Today 28 22 20.5 25.55 28.5 0 0 Total Hours Worked To Date 28 50 70.5 96 124.5 124.5 124.5 Total Worked & Remaining Hours 230 233.5 235.5 219.5 242.5 242.5 242.5 Average Hours Worked Per Day 28.0 25.0 23.5 24.0 24.9 20.8 17.8 Est Completion Date (Burndown) 23 Apr 07 24 Apr 07 25 Apr 07 24 Apr 07 24 Apr 07 26 Apr 07 28 Apr 07 Est Completion Date (Task Completion) 29 Apr 07 26 Apr 07 26 Apr 07 23 Apr 07 25 Apr 07 27 Apr 07 29 Apr 07 Task Hours Pending 194 178 154.5 117.5 105.5 105.5 105.5 Task Hours In Progress 20 14 20 3 18 18 18 Task Hours Complete 16 41.5 61 99 119 119 119 Count of Workitems Pending 91 83 72 66 55 55 59 Count of Workitems In Progress 4 5 10 4 6 6 6 Count of Workitems Complete 6 12 19 33 42 42 42 32 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 16
Transparency in Reporting 33 34 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 17
How does Agile Apply to Managers? Understanding estimation & multitasking Know your role Trust your team Let people grow Support and encourage failure, but only if it is early Accept the transition cost Commitment 35 Estimation Estimates are not commitments just like Availability not being a skillset. 36 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 18
What Impacts Estimates? Multitasking Lateness is passed down Lack of a common understanding And more 37 Clark and Wheelwright (1993) found: determined that when working on more than two tasks, a person s time spent on value adding work drops rapidly. 38 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 19
Multitasking A B C 10 10 10 A B C A B C 20 Multitasking causes delays Instead of multitasking, use small units of work You want work to flow as fast as possible More efficient transfers to next person 20 20 39 Deferring Work (Student Syndrome) The estimate is based on this: Task Local Safety But we behave like this Local Safety Task Task 40 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 20
Lateness is Passed Down the Schedule TASK A TASK B TASK D TASK C To start early, all of these must occur Task A, B and C must finish early Tester for Task D must be available early To start late, any of these can occur Task A, B or C finish late Tester is not available 41 Validate your Build Types Build like this Not like this 42 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 21
Reward for Failiing Early Success is subjective People are typically risk averse People typically y seek out work that suits their skill sets Causes people to stay in their comfort zone Limits growth opportunity 44 Reward for Failing Early Taking on change is to take on risk of the unknown Incentive structures are not setup to reward for taking on the unknown Compensation for taking on additional risk is not proportionate to the risk itself 45 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 22
Reward for Failing Early Reward for tries & success, even if they end in failure Think about research how often are breakthroughs encountered? Reward for going outside the comfort zone Learn from failures to grow 46 Provide Protection Protection (allowing people to ) Break old habits Question the status quo Seek out new ways of working Learn to self sustain 47 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 23
Accept the Transition Cost Any change introduces instability With change, performance declines before it returns to baseline Maybe it returns at a lower level Maybe it returns at a higher level (which we always assume) Decrease in productivity Baseline achieved Long term improvement 48 Promote Transparency Highlight failure and success Publish status daily Hold retrospectives during projects,, not only at project end (note, these are not post mortems ) Use burndowns Show working software on a regular basis 49 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 24
50 Getting Started Get a senior Sponsor in the company Get a champion to drive the effort Agree on who will play the roles Create a Transition Product Backlog Set a date to start and manage to that date Build a Sprint Backlog and start working Use Burndowns Hold Company demos on how the transition is progressing Inspect and Adapt 51 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 25
What Causes Failure? Making changes out of the gate Thinking that this can t work in our company Not having honest retrospectives Falling into old habits Lacking authority and being empowered Business culture does not support Agile Principles and Values 52 Be Warned Most projects deliver every 6 18 months. Agile, and Scrum, reduces this through inspect and adapt Things will be stressful Fight the urge to be lazy Stay disciplined 53 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 26
Scrum Resources Websites: My Website: http://www.mitchlacey.com Mountain Goat Software http://www.mountaingoatsoftware.com/scrum Scrum Alliance http://www.scrumalliance.org Agile Alliance http://www.agilealliance.org Books: Agile Project Management with Scrum, 2004 The Enterprise and Scrum, 2007 Ken Schwaber, Microsoft Press ScrumDevelopment Yahoo Group http://www.yahoogroups.com 54 Copyright 2007 2010 Mitch Lacey. email mitch@mitchlacey.com for re use permission. 27