Date post: | 29-Oct-2014 |
Category: |
Technology |
Upload: | ekraay |
View: | 17 times |
Download: | 1 times |
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.