Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scale hurts

1,975 views

Published on

Scaling Scrum hurts. There are coordination challenges, technical challenges, and communication challenges. But there are some patterns you can use to overcome these pains. This is an experience report from a 30+ person 5 team scaled Scrum project. It gives you practical tips on what to try if you experience any of the pains we did when we scaled Scrum.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Scale hurts

  1. 1. Growing Pains: Why Scaling Agile Hurts and What You Can Do About It.<br />By Ed Kraay<br />and VibhuSrinivasan<br />
  2. 2. Who is more agile?<br />
  3. 3. As number of people increases, so does the cost of communication…<br /><ul><li>Expensive communication delays feedback
  4. 4. Delayed feedback reduces your ability to respond to change</li></li></ul><li>My experience up to this project<br />Used XP successfully on various web and telcommunication projects with small teams (7-9 people) with one product owner for 3 years<br />Distributed and colocated teams<br />Brought on as a ScrumMaster for one team on a 5 team projects, all with Scrum/XP<br />
  5. 5. The project: develop an online game<br />5 Feature Teams<br />Game Team<br />Art Team<br />Identity Management Suite<br />Social Networking<br />Back-end game infrastructure<br />Professional Services Environment<br />
  6. 6. The service platform<br />Technologies in Play<br />Windows Communication Foundation , C# .NET 2.0, .NET 3.0, ASP.NET<br />PHP <br />A packaged product for content management<br />LDAP , Java <br />COTS Identity Management Suite<br />One product<br />
  7. 7. 5 teams, ~50 people<br />Multiple Team Gaming Program<br />
  8. 8. We scaled by adding teams<br />
  9. 9. How we organized<br />
  10. 10. Timeline<br />
  11. 11. Environment<br />The Practices: Scrum+ XP<br /><ul><li>Scrum Framework
  12. 12. XP Practices
  13. 13. Open Room Environment</li></li></ul><li>Scrum Scaling 101<br />Scrum Rule: Agile teams scale by adding teams not by growing teams<br />Scrum Recommendation: Add a scrum of scrums meeting, add a meta scrum<br />We experienced some pains when we scaled<br />Some things we tried helped<br />There may be other things we could have tried… <br />
  14. 14. Pain: Work inserted in the middle of an iteration by a second team<br />Would “break” the sprint, or cause delays<br />
  15. 15. Try: Synchronize iterations across teams<br /><ul><li>Create a Rhythm for product owners, team members, and facilitates planning
  16. 16. Allows for cross team release planning</li></li></ul><li>Pain: Undone work at the end of an iteration<br />Caused the next sprint to reduce velocity, reduced quality<br />Try: Tracking the Right Metrics: Committed vs actual points<br />“Slow down to speed up”<br />Committed vs Completed Points<br />
  17. 17. Pain: Managing Priorities across Multiple Backlogs<br />Team A<br />Priorities handled on the back end, mid sprint<br />Caused mid sprint injection of product backlog items from other teams, breaking the sprint “bubble”<br />Dependencies not clearly across teams<br />Story 1<br />Story 2<br />Story 3<br />Team B<br />Story 1<br />Story 2<br />Story 3<br />Team C<br />Story 1<br />Story 2<br />Story 3<br />
  18. 18. Try: One product backlog to reduce sub-optimization from feature teams<br />Team A<br />Story 1<br />Team B<br />Story 2<br />Story 3<br />Story 4<br />Team C<br />
  19. 19. Pain: Multiple product owners with competing business priorities<br />Caused shifting focus on team.<br />
  20. 20. Try: Chief Product Owner with clear responsibilities<br />RACI based on Establishing Top to Bottom Transparency Using the Meta-Scrum by Brent Barton<br />
  21. 21. Try: 5 Levels of Planning to set context for leadership<br />Daily Executive Meeting<br />Meta Scrum<br />Scrum of Scrums<br />Source: HenrikKniberg<br />Daily Scrum Meeting<br />
  22. 22. Try: product definition team<br />A team of product owners, UX, stakeholders, architects working on sprint ahead of the teams, clarifying priorities and defining and feeding the backlog so it is ready to go.<br />
  23. 23. Try: Moving from Push to Flow<br />Product Definition Team<br />Source: Jean Tabaka, Jeff Sutherland, Hubert Smits<br />
  24. 24. Try: X-Team Release Planning<br />
  25. 25. Pain: Teams Build Silos <br />Occurred even when teams were feet apart from each other in open space<br />Try: Cross Team Events: Retrospectives, Lunch, Release Planning, Celebrations, Open Space Meetings.<br />
  26. 26. Pain: It works on my machine<br />One teams code does not interface with the other team well<br />Code working on local build fails to integrate<br />Its not easy to deploy the code to customer<br />
  27. 27. Try: Integrated build and deploy<br /><ul><li>Coordinate at the code level rather than at the management level
  28. 28. Stop and fix for all teams when there is a failure, reduces local optimization</li></li></ul><li>Swarming<br />Cross Team Ownership for the build – increase feedback across teams <br />
  29. 29. Pain: Unresolved Impediments<br />Hardware Requisition Process<br />Network Issues<br />Team Issues<br />
  30. 30. Try: 24 hour removal of impediments to create a continual learning culture<br />
  31. 31.
  32. 32. Try: Agile Modeling and Design<br />Teams decided to white board designs one day after the sprint planning<br />More spikes were used to understand a design before it can be used<br />More emphasis on pairs to talk about what they are going to do, before changing code<br />
  33. 33. More Engineering Pains<br />Common Engineering Practices Missing<br />Code was growing too fast in too many ways across teams<br />Duplicated code<br />Customers had a core architecture group that had less and less visibility as the teams grew and this caused unease.<br />
  34. 34. Try: Embedding a cross team architect / agile coach <br />A servant leader<br />Mentor and available to pair program<br />Shields the teams from technical bombshells<br />Active listener<br />Help inject technical stories<br />
  35. 35. Pain: Engineering Smells<br />Some teams were reporting lower bugs than others<br />Unit testing was not consistent <br />Acceptance testing was missing<br />Team did not see value in TDD <br />More debates and arguments were leading to unhappy developers<br />Bad smells in code<br />
  36. 36. Try: focusing on testing at retrospectives<br />The teams agree to focus on testing in their retrospective<br />Try an agreement: there should be increasing tests with each check-in. Team members can implement the tests any way they want, but code should have unit tests<br />Test results on build system + Big visible charts<br />Category tags were used to group tests for quicker running.<br />Inject one or two senior developers who knew TDD well in every team - Peer pressure = great code<br />
  37. 37. TDD led to a marked decrease in defects<br />
  38. 38. Conclusion<br /><ul><li>Scaling hurts
  39. 39. Focus on Agile Values and Principles
  40. 40. Increase feedback
  41. 41. Be courageous, fail fast and learn from your mistakes</li></li></ul><li>Thank you<br />Special thanks to VibhuSrinivasan, Brent Barton, Chris Sterling, and the rest of the team that made this possible.<br />

×