Scale hurts

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

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.

Scale hurts

by ekraay on Dec 23, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 52

Statistics

Scale hurts — Presentation Transcript