Scale hurts
Upcoming SlideShare
Loading in...5

Scale hurts



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.



Total Views
Views on SlideShare
Embed Views



3 Embeds 86 79 6 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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 Scale hurts Presentation Transcript

  • Growing Pains: Why Scaling Agile Hurts and What You Can Do About It.
    By Ed Kraay
    and VibhuSrinivasan
  • Who is more agile?
  • As number of people increases, so does the cost of communication…
    • Expensive communication delays feedback
    • 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
  • 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
  • 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
  • 5 teams, ~50 people
    Multiple Team Gaming Program
  • We scaled by adding teams
  • How we organized
  • Timeline
  • Environment
    The Practices: Scrum+ XP
    • Scrum Framework
    • XP Practices
    • 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…
  • Pain: Work inserted in the middle of an iteration by a second team
    Would “break” the sprint, or cause delays
  • Try: Synchronize iterations across teams
    • Create a Rhythm for product owners, team members, and facilitates planning
    • 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
  • 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
  • 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
  • Pain: Multiple product owners with competing business priorities
    Caused shifting focus on team.
  • Try: Chief Product Owner with clear responsibilities
    RACI based on Establishing Top to Bottom Transparency Using the Meta-Scrum by Brent Barton
  • Try: 5 Levels of Planning to set context for leadership
    Daily Executive Meeting
    Meta Scrum
    Scrum of Scrums
    Source: HenrikKniberg
    Daily Scrum Meeting
  • 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.
  • Try: Moving from Push to Flow
    Product Definition Team
    Source: Jean Tabaka, Jeff Sutherland, Hubert Smits
  • Try: X-Team Release Planning
  • 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.
  • 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
  • Try: Integrated build and deploy
    • Coordinate at the code level rather than at the management level
    • 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
  • Pain: Unresolved Impediments
    Hardware Requisition Process
    Network Issues
    Team Issues
  • Try: 24 hour removal of impediments to create a continual learning culture
  • 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
  • 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.
  • 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
  • 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
  • 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
  • TDD led to a marked decrease in defects
  • Conclusion
    • Scaling hurts
    • Focus on Agile Values and Principles
    • Increase feedback
    • 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.