Growing Pains: Why Scaling Agile Hurts and What You Can Do

About It.

By Ed Kraayand Vibhu Srinivasan

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– PHP – 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

TimelineTeam Forming:

March 07

First Release, Infrastructure:

August 07

Game Infrastructure Teams: August

07

Program Retrospective

June 08

Releases: September 08 –

December 08

EnvironmentThe 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

• 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 A

Story 1

Story 2

Story 3

Team B

Story 1

Story 2

Story 3

Team C

Try: One product backlog to reduce sub-optimization from feature teams

Story 1

Story 2

Story 3

Story 4

Team A

Team B

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

Source: Henrik KnibergDaily Scrum Meeting

Scrum of Scrums

Meta Scrum

Daily Executive 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

Source: Jean Tabaka, Jeff Sutherland, Hubert Smits

Product Definition Team

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

SwarmingCross 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

Game Team Identity Management Persistence Team Game Infrastructure0

100

200

300

400

500

600

700

Defects and Tests

Unit TestsAcceptance TestsDefects

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 Vibhu Srinivasan, Brent Barton, Chris Sterling, and the

rest of the team that made this possible.