Implementing scrum on a large scale


Published on

Presentation I gave at the Scrum Gathering in Spring of 2009

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Implementing scrum on a large scale

  1. 1. Implementing Scrum on a Large Scale<br />Dan LeFebvre<br />Agile Coach, CSP<br />3/16-18/2009<br />1<br />Orlando Scrum Gathering<br />
  2. 2. Biography<br />Over 20 years in software product development as a developer, manager, director, and coach<br />Last 5 years using agile development practices<br />Last 2 years implementing Scrum in a 700 person engineering organization as an Agile Coach<br />Sites in MA, OR, TX, GA, IL<br />Also in Canada – BC, Que<br />Also in Belgium and Noida, India<br />3/16-18/2009<br />Orlando Scrum Gathering<br />2<br />
  3. 3. Intent of this Session<br />To take you through the journey of that 700 person engineering organization toward agility through Scrum. <br />How did they decide to go agile? <br />How did they decide to go Scrum? <br />How do they coordinate a large suite release? <br />How do they handle organizationally impediments? <br />What about progress reporting? <br />What were their biggest challenges? <br />What are their challenges yet to face?<br />3/16-18/2009<br />3<br />Orlando Scrum Gathering<br />
  4. 4. Something is not right<br />3/16-18/2009<br />Orlando Scrum Gathering<br />4<br />
  5. 5. Productivity was plummeting<br />3/16-18/2009<br />Orlando Scrum Gathering<br />5<br />
  6. 6. Cutter Consortium Evaluation<br />Michael Mah and Jim Highsmith<br />Evaluation – both quantitative and qualitative<br />Recommended and sold Agile to CTO<br />3/16-18/2009<br />Orlando Scrum Gathering<br />6<br />
  7. 7. “Agile Lite” Goal 11-1<br />Iterative/incremental development<br />Test Driven Development<br />Emergent/Evolutionary Design<br />Daily Standups<br />Retrospectives<br />Phase gated governance model <br />Commit to contents, dates, cost for a 12 month release<br />Account for entire organizational effort<br />3/16-18/2009<br />Orlando Scrum Gathering<br />7<br />
  8. 8. Weakest Link Theory<br />Interdependent suite of products<br />All must ship simultaneously<br />If any of them not agile, suite is in trouble<br />Roll out to entire organization at once<br />5 full time coaches from Cutter, 5 part time internal coaches<br />After 1 year, only used 5 part time coaches <br />3/16-18/2009<br />Orlando Scrum Gathering<br />8<br />
  9. 9. Results<br />Delivered 7-5<br />Improved Quality<br />More automated tests<br />Agile in the culture<br />3/16-18/2009<br />Orlando Scrum Gathering<br />9<br />
  10. 10. Entropy<br />“Inevitable and steady deterioration of a system or society.”<br />The American Heritage® Dictionary of the English Language, Fourth Edition<br />3/16-18/2009<br />Orlando Scrum Gathering<br />10<br />
  11. 11. Slip back to old ways<br />All part-time coaches back to their day jobs<br />Committed to 3 suite-wide projects within the same release (each considered all or nothing)<br />Globalization, New UI and new Reporting platform<br />Results<br />Projects fell behind<br />All UI-based automation broke<br />2 projects stopped doing retrospectives<br />Team morale suffered<br />No or meaningless burncharts so no transparency<br />3/16-18/2009<br />Orlando Scrum Gathering<br />11<br />
  12. 12. The Agile Coach<br />Without the coaches, teams had no help<br />Decided to get a full-time Agile Coach<br />Teach agile to new employees<br />Observe and help teams that are struggling<br />Roll out agile to newly acquired companies<br />Become the agile conscience of the organization<br />3/16-18/2009<br />Orlando Scrum Gathering<br />12<br />
  13. 13. What to do with management<br />3/16-18/2009<br />Orlando Scrum Gathering<br />13<br />
  14. 14. Management still too “Command and Control”<br />Culture is very hierarchical<br />People treated as “resources”<br />Regularly moved from team (workgroup?) to team to handle crises and delays<br />Management makes most decisions<br />Teams do not feel empowered<br />Many teams just going through the motions of agile development<br />“Blame” is typical reaction<br />3/16-18/2009<br />Orlando Scrum Gathering<br />14<br />
  15. 15. Collaboration Explained<br />90 people trained in collaboration skills by Jean Tabaka and Ronica Roth from Rally<br />Learned tools<br />Facilitation techniques<br />Lots of hands-on exercises<br />Results<br />Meetings ran better<br />Better agendas and capturing of group learning<br />Better retrospectives<br />3/16-18/2009<br />Orlando Scrum Gathering<br />15<br />
  16. 16. Management not Agile<br />Management not quite agile<br />Very little training was given to managers<br />Still division between Dev and QA<br />3/16-18/2009<br />Orlando Scrum Gathering<br />16<br />Manager Community<br />Customer Community<br />Developer Community<br />
  17. 17. Scrum to the rescue<br />Scrum is a management framework<br />Training focused on the managers and product managers<br />60 ScrumMaster receive CSM from Ken Schwaber<br />30 Product Owners receive CSPO from Ken Schwaber<br />Create true cross-functional teams<br />No more “communities”<br />1 ScrumMaster, 1Product Owner, Team of developers, testers, writer, etc.<br />Managers became ScrumMasters, Product Managers are now the Product Owners<br />3/16-18/2009<br />Orlando Scrum Gathering<br />17<br />
  18. 18. Scaling issues<br />3/16-18/2009<br />Orlando Scrum Gathering<br />18<br />
  19. 19. Large Interdependent Suite<br />3/16-18/2009<br />Orlando Scrum Gathering<br />19<br /><ul><li>About 30 teams need to coordinate effort to release the suite
  20. 20. Deemed impossible to synchronize sprints</li></li></ul><li>Parallel Project Organization<br />Suite Management Team (SMT)<br />Steering committee<br />1 Director and 1 Product Owner from each of the 3 organizations<br />Suite Integration Team (SIT)<br />Installs suite on a set of integration servers each week<br />Creates and runs series of suite-wide tests<br />Suite Release Team (SRT)<br />ScrumMaster and Product Owner from each team (60 people)<br />Responsible for coordinating dependencies and resolving suite-wide issues<br />Primary communication vehicle for the suite<br />3/16-18/2009<br />Orlando Scrum Gathering<br />20<br />
  21. 21. How do they synchronize and review the suite?<br />Created the concept of “Release Candidates”<br />Every 6 to 8 weeks<br />Entire system integrated and tested together<br />Suite build and battery of suite tests run weekly<br />Teams hold their own sprints but integrate into last integrated system each week<br />Each team has daily builds and battery of daily tests (some team build more often)<br />3/16-18/2009<br />Orlando Scrum Gathering<br />21<br />
  22. 22. Heartbeats<br />3/16-18/2009<br />Orlando Scrum Gathering<br />22<br />Team 3 heartbeat<br />Team 2 heartbeat<br />Team 1 heartbeat<br />Suite heartbeat<br /><ul><li>Beginning each RC
  23. 23. Each team presents release plan focusing on dependencies and impacts to SRT
  24. 24. End of each RC
  25. 25. SRT holds an RC Retrospective
  26. 26. Product Owners hold an RC Review for organization</li></li></ul><li>Dealing with Impediments<br />3/16-18/2009<br />Orlando Scrum Gathering<br />23<br />
  27. 27. Dealing with suboptimization<br />Each team is run fairly independently<br />Each identify and resolve impediments<br />Experiencing the same impediments<br />Different solutions<br />Some solutions impacted other teams<br />3/16-18/2009<br />Orlando Scrum Gathering<br />24<br />
  28. 28. First Attempt – Etc.<br />Senior Execs doing the work of prioritizing and resolving organizational impediments <br />Identified by the development teams<br />Resolve by creating small teams to remove the impediment<br />Use Scrum to run the process<br />Issues<br />Execs had no time for this work<br />Reluctant to assign people to impediment removal teams<br />3/16-18/2009<br />Orlando Scrum Gathering<br />25<br />
  29. 29. Second Attempt – Scrum Implementation Team<br />Small group of 8 people from across the organization <br />Issues<br />Focused more on process definition instead of impediment removal<br />Not all the skills represented<br />Limited time to work on this, still had day jobs<br />3/16-18/2009<br />Orlando Scrum Gathering<br />26<br />
  30. 30. Third Attempt – ScrumMaster Meeting<br />Hold a regular meeting of ScrumMasters to identify, prioritize, and volunteer to resolve impediments<br />This group got some traction<br />Issues<br />Many impediments around Product Ownership<br />Also many architectural impediments<br />3/16-18/2009<br />Orlando Scrum Gathering<br />27<br />
  31. 31. Final Attempt – Agile Leaders Meeting<br />Regular meeting of ScrumMasters, Product Owners, and Architects led by Agile Coach<br />Agenda includes a brief coaching session on an agile topic from one of the team<br />Review of resolved impediments, identifying and prioritizing new ones, and volunteering to resolve highest priority<br />Q & A session to solicit help from team and coach on individual issues<br />Resolved over 50 impediments in 1 year<br />3/16-18/2009<br />Orlando Scrum Gathering<br />28<br />
  32. 32. Transparency Issues<br />3/16-18/2009<br />Orlando Scrum Gathering<br />29<br />
  33. 33. Transparency is more translucent<br />Each team uses their own tools for tracking data<br />Flipcharts and post-its<br />Excel – Various workbooks<br />X-Planner<br />Rollup data collected manually<br />Sometimes late<br />Sometimes not complete<br />Apples to Oranges rollup<br />“Blame” culture prevents full disclosure too soon<br />3/16-18/2009<br />Orlando Scrum Gathering<br />30<br />
  34. 34. Clearing it up<br />SMT created a standard workbook that normalizes data to facilitate a suite-wide rollup<br />Includes a projected organizational velocity to predict end date<br />“I have never been in an organization that knew more about where it was throughout the lifecycle of the project” – One Senior Staff Member<br />3/16-18/2009<br />Orlando Scrum Gathering<br />31<br />
  35. 35. Clearing it up more<br />Implementing VersionOne <br />Centralize the project information <br />Give execs instant access to status of any project<br />Standardize how information is collected and managed throughout the organization<br />Simplify suite rollup<br />Provide unprecedented transparency<br />Create standard reports<br />3/16-18/2009<br />Orlando Scrum Gathering<br />32<br />
  36. 36. Dealing with “Lite”<br />3/16-18/2009<br />Orlando Scrum Gathering<br />33<br />
  37. 37. Suite planning still phase-gated<br />Need still exists to commit to an annual plan <br />Company expects large features to justify the 700 person engineering staff<br />Outside engineering still driven by “waterfall” model<br />Cannot or will not take advantage of iterative delivery<br />3/16-18/2009<br />Orlando Scrum Gathering<br />34<br />
  38. 38. Creating a Balance<br />They created a multi-tiered content strategy <br />Commit at the high level<br />Establish budgets at the mid-level<br />Stay flexible at the details<br />Budgets give guidance to Product Owners on what senior management is willing to invest to get the benefit or return<br />3/16-18/2009<br />Orlando Scrum Gathering<br />35<br />
  39. 39. Requirements hierarchy<br />Initiatives – Broad areas of focus tied to corporate strategy<br />Headlines – Major Feature Sets/Capabilities within an Initiative<br />Engineering commits to these within a budget<br />Shippable Units – The smallest feature that is worth shipping to a customer<br />Analogous to Minimal Marketable Feature from Software by Numbers<br />Engineering delivers as many of these within the budget of a headline<br />Business Value measured here<br />Stories – User stories as we all know and love<br />3/16-18/2009<br />Orlando Scrum Gathering<br />36<br />
  40. 40. Planning Onion<br />3/16-18/2009<br />Orlando Scrum Gathering<br />37<br />
  41. 41. Product Plan<br />Portfolio Plan<br />RC 1<br />RC 2<br />RC 3<br />RC 4<br />Rel 6.2<br /> SU<br /> SU<br /> SU<br /> SU<br /> SU<br /> SU<br /> SU<br /> SU<br /> SU<br /> SU<br /> SU<br /> SU<br />Headline<br />Headline<br /> SU<br /> SU<br /> SU<br /> SU<br />Headline<br /> SU<br />Headline<br /> SU<br /> SU<br />Headline<br />Headline<br /> SU<br />Headline<br />Headline<br />Release Plan<br />Rel 6.1.1<br />Sprint 1<br />Sprint 2<br />Sprint 3<br />Headline<br />Headline<br />Headline<br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />As a User, I can jfh hf jahdsdf <br />Headline<br />Rel 6.1.2<br />Headline<br />Headline<br />Headline<br />Planning and Outputs<br />SprintPlan<br />Started<br />Done<br />Task<br />Task<br />Task<br />Task<br />Task<br />Task<br />
  42. 42. Is Done really Done?<br />3/16-18/2009<br />Orlando Scrum Gathering<br />39<br />
  43. 43. Unpredictable “tail”<br />Planned 3 months for final stabilization <br />Always goes longer<br />Many unpredictable issues found<br />The Definition of Done (DoD) was not the same across teams<br />Some due to the large amount of legacy code<br />Some based on management interpretation – “Spirit of the Criteria”<br />3/16-18/2009<br />Orlando Scrum Gathering<br />40<br />
  44. 44. Executive Bias<br />Setting DoD too “weak” - guideline<br />Leads to too much work during the tail<br />Makes it hard to know where you are<br />Causes integration issues due to impedance mismatch <br />Setting DoD too “Strong” - rule<br />No real progress can be made due to late issues<br />Sets the bar too low on content<br />Executives wants team to “stretch” by setting aggressive DoD but knows he’ll get less (and accepts it)<br />This line is not apparent to the teams<br />3/16-18/2009<br />Orlando Scrum Gathering<br />41<br />
  45. 45. Created 2 lists of criteria<br />Definition of Done<br />This is the must be complete to declare victory<br />Quality Goal<br />Strive to complete and must justify shortfall<br />Example<br />DoD – Performance test must be completely run<br />Quality Goal – Performance must not have degraded by more than 5% with no S1 defects<br />3/16-18/2009<br />Orlando Scrum Gathering<br />42<br />
  46. 46. DoD is too much for each Sprint<br />Doing all the work needed for shipping each sprint is considered wasteful<br />Some tests run almost as long as a sprint!<br />Lots of legacy code with manual tests<br />3/16-18/2009<br />Orlando Scrum Gathering<br />43<br />
  47. 47. Modify DoD and QG by timebox<br />Defined unambiguously by SMT<br />For Ship – include everything that must be done<br />For RC – remove what they are unable or unwilling to do each RC<br />For Sprint – remove what they are unable or unwilling to do each Sprint<br />3/16-18/2009<br />Orlando Scrum Gathering<br />44<br />
  48. 48. Results<br />3/16-18/2009<br />Orlando Scrum Gathering<br />45<br />
  49. 49. Increased Automation<br />3/16-18/2009<br />Orlando Scrum Gathering<br />46<br />
  50. 50. What happened to quality<br />3/16-18/2009<br />Orlando Scrum Gathering<br />47<br />OpenDefects<br />Pre-Scrum<br />Scrum<br />
  51. 51. Next Challenge<br />3/16-18/2009<br />Orlando Scrum Gathering<br />48<br />
  52. 52. Enticing rest of Organization to be more Agile<br />There is still a “batch” approach to preparing Service and Customer training <br />Marketing not strongly tied in with Product Management and the Product Owners<br />3/16-18/2009<br />Orlando Scrum Gathering<br />49<br />
  53. 53. Performance and Compensation still very individualized<br />Has a negative effect on teamwork<br />Some teams view ScrumMaster/Manager as an evaluator and aren’t as open with issues<br />Individual goals trump team goals or organizational goals<br />3/16-18/2009<br />Orlando Scrum Gathering<br />50<br />
  54. 54. Still treat people as “resources”<br />Cannot break habit of moving people from team to team<br />Cannot break habit of needing “full utilization”<br />Cannot break habit of accounting for hours worked<br />3/16-18/2009<br />Orlando Scrum Gathering<br />51<br />
  55. 55. Recent Restructuring<br />Increased fear<br />Potential to reduce transparency<br />Potential to reduce teamwork to “CYA”<br />Lowered morale <br />Lower energy<br />Potential less commitment<br />3/16-18/2009<br />Orlando Scrum Gathering<br />52<br />
  56. 56. Loss of the Coach<br />They eliminated the position of Agile Coach<br />Entropy may set in again<br />No focus for getting help to the teams<br />Impediments mechanism may break down<br />Training of new employees and organizations will be affected<br />3/16-18/2009<br />Orlando Scrum Gathering<br />53<br />
  57. 57. Summary<br />3/16-18/2009<br />Orlando Scrum Gathering<br />54<br />
  58. 58. Where are they?<br />Scrum is implemented throughout<br />Mechanism for organizational impediments in place<br />Transparency is improving<br />Improvements to engineering practices are on-going<br />Quality is improving<br />Planning is becoming more flexible<br />3/16-18/2009<br />Orlando Scrum Gathering<br />55<br />
  59. 59. Questions?<br />Dan LeFebvre<br />Director, Software Engineering; Agile Coach<br /><br /><br />3/16-18/2009<br />Orlando Scrum Gathering<br />56<br />