Growing Pains: Scaling Agile Hurts and Solutions
•Download as PPTX, PDF•
0 likes•1,384 views
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.
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (20)
Similar to Growing Pains: Scaling Agile Hurts and Solutions
Similar to Growing Pains: Scaling Agile Hurts and Solutions (20)
Recently uploaded
Recently uploaded (20)
Growing Pains: Scaling Agile Hurts and Solutions
- 1. Growing Pains: Why Scaling Agile Hurts and What You Can Do About It. By Ed Kraay and VibhuSrinivasan
- 2. Who is more agile?
- 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 PHP 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
- 10. Timeline
- 12. XP Practices
- 14. Pain: Work inserted in the middle of an iteration by a second team Would “break” the sprint, or cause delays
- 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
- 29. Pain: Unresolved Impediments Hardware Requisition Process Network Issues Team Issues
- 30. Try: 24 hour removal of impediments to create a continual learning culture
- 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
- 39. Focus on Agile Values and Principles
Editor's Notes
- 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.