Scale hurts


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

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

No notes for slide
  • While the scale of the teams may be larger, the forces and principles at work are the same in a small boat vs a large boat. What is different, is the number of people you need to coordinate to respond more quickly to change.
  • Even harder than scaling up in one large boat, is sailing a number of ships in the same direction. This is similar to project teams. Each one must not only keep discipline, its internal crew motivated, fed, show up for it’s watch on time, the effect of wind, waves, current knocking the boat and project schedule off course, but they must also keep watch and signals with the other ships. Think of the wind as velocity, the current as schedule drift or impediments, and the direction as the vision or sprint goal. In an armada you must know the rank or seniority of the ships. In a multi-team project you must know what project is the anchor project, that is driving the other projects.
  • Standard XP PracticesPaired ProgrammingContinuous IntegrationTest Driven DevelopmentBullpen, open collaborative environment“Do Food”
  • With multiple product backlogs
  • Helped to Set the business prioritity across the other product owners. RACI Matrix helped set the stage for empowerment and the right level of accountability.
  • (Stigmergy and Termites) While swarming occurs naturally in scrum teams, they don’t necessarily optimize for the whole. We found that the focus that a scrum team causes on a team worked against the focus of the whole, unless we did some things to create a shared culture and commitment across the groups.
  • 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 />