Your SlideShare is downloading. ×
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Scale hurts
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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 …

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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.
  • Transcript

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