Scaling Agile Hurts by Vibhu Srinivasan
1 like402 views
The document discusses challenges faced by multiple agile teams working on a multi-faceted gaming project, including communication costs and issues caused by scaling teams. It identifies various pain points, such as defects, multiple backlogs, and siloed team structures, while emphasizing solutions like test-driven development, synchronized sprints, and cross-team collaboration. Recommendations include adopting a unified product backlog, implementing cross-team events to foster culture, and enhancing testing and validation practices to improve overall quality and performance.
Scaling Agile Hurts by Vibhu Srinivasan
- 2. Who are these guys, anyway? Ed Kraay Scrum Master, Vibhu CSP Srinivasan Agile Coach Agile Coach, Technologist. Doing scrum Doing XP and XP since since 1999 2004
- 3. Hypothesis: Scale hurts due to increased communication cost • Communication increases geometrically, while team members are added linearly. • Open environment was not enough to solve the issue. • Teams locally optimize
- 4. The context: An MMO game project 0 Identity Management Suite 0 Content Management System 0 Social Networking 0 3D Game 0 Back-end game infrastructure
- 5. The service platform 0 Technologies in Play 0 Java, Windows Communication Foundation , C# .NET 2.0, .NET 3.0, ASP.NET 0 PHP 0 A packaged product for content management 0 LDAP
- 6. Scrum + XP Environment •Scrum Process •All 3 roles, artifacts, and ceremonies •XP Practices •Paired Programming •Continuous Integration •Test Driven Development •Open environment
- 7. 5 teams, 9 projects, ~50 people 0 Multiple Team Gaming Program
- 8. Customer Team All Rights Reserved – Vibhu Srinivasan 7/18/2010 8 http;//agilefaq.net
- 9. How we organized our Meetings, and how that mapped to the 5 levels of planning
- 10. The Timeline Team Forming: First Release, Infrastructure: Timeline Game Infrastructure Program Retrospective Planned Releases: March 07 September 08 – August 07 Teams: August 07 June 08 December 08
- 11. How did we generate these insights? • Held a cross team program retrospective • 1 day facilitated event • Set the Stage, Built a 1+ year timeline, generated insights and defined actions • This was in addition to project, iteration retrospectives
- 12. Hurt: Undone work at the end of a sprint 0 Caused the next sprint to reduce velocity, reduced quality 0 Helped: Tracking the Right Metrics: Committed vs Committed vs actual Completed points, and worked to Test Points even them out. verage
- 13. Hurt: Defects slowed velocity 0 Helped: Test Driven Development 0 Hypothesis: TDD reduces defects. 700 Defects and Tests 600 500 400 300 200 Unit Tests 100 Acceptance Tests Defects 0
- 14. Hurt: Multiple Backlogs 0 Priorities handled on Many Teams, many backlogs the back end, mid sprint 0 Caused injection of priorities
- 15. Helped: chief product owner
- 16. Hypothesis: product definition team 0 A team of product owners, UX, stakeholders, working ahead of the teams, defining and feeding the backlog.
- 17. Hypothesis: Use one product backlog to reduce pain of multiple backlogs
- 18. Hurt: Multiple business priorities 0 Caused shifting focus on team. 0 Helped: Vision Statement
- 19. Hurt: Work inserted in the middle of the sprint 0 Would break the sprint, or cause delays
- 20. Helped: Synchronizing our sprints
- 21. Hurt: lack of cross team cultureTeam Team B 0 Caused silo effect, A rule even when teams rules s! were feet apart from ! each other. 0 Helped: X-Team Events: Retrospectives, Lunch, Release Planning, Celebrations.
- 23. Helped: X-Team Release Planning
- 24. Helped: Ensuring all customer stakeholders are represented by Product Owners
- 25. Hurt: Impediments 0 Hardware Requisition Process 0 Network Issues 0 Team Issues
- 26. Stop the line All rights reserved Vibhu Srinivasan 7/18/2010 26
- 28. Services are painful to consume 0 Teams are working in silos and when services are built, they are too painful to consume Service Versioning Well defined contracts Service level agreements
- 29. Lack of design caused too much technical debt 0 Agile Myth = There is no design and architecture in Agile development 0 Going from story to code causes a lot of technical debt 0 UML is not enough to convey details
- 30. 0 Teams are required to white board designs one day after the sprint planning with others 0 Use more spikes to understand a design before it can be used 0 More emphasis on pairs to talk about what they are going to do, before changing code
- 31. UML does not convey the details of the complex models 0 Some services had too Services Architecture many complicated scenarios that could Redeem R View R Manage Collection Purchase R R Open Combine/ R Convert R Unique R Escrow R Use In Destroy R R Share R not be communicated Game Client Systems easily in pictures. Consume R Repository Feed R Trade R Run Recipe R SERVICE API R SERVICE 0 Use Fundamental Collection Privision Modeling Concept ( Release Line 1 Package services FMC ) models to convey Release Line 2 Release Line 3 Game the overall intent of New Game Game2 Database Goals Accounts the system Game 3 Game 4 Uniquq Rights 0 Color Coded by Release Security line Set Inventory Levels R Track Ownership Patterns R Audit R Health Check R SERVICE API R http://www.fmc-modeling.org/ Administration 0 Invest in a great digital camera and a Define Package Publish Create Manually large whiteboard R R R R R Log R Override R Collation Recipe R Audit Ownership
- 32. More Engineering Pains 0 Common Engineering Practices Missing 0 Code was growing too fast in too many ways across teams 0 Duplicated code 0 Customers had a core architecture group that had less and less visibility as the teams grew and this caused unease.
- 33. One solution to these pains 0 Introduce a cross team architect and embedded agile coach 0 A servant thought leader 0 Mentor and the readily available to pair 0 Shields teams from technical bombshells 0 Active listener and helper 0 Help inject technical stories
- 34. More People = Less Quality 0 Some teams were reporting lower bugs than others 0 Unit testing was not consistent 0 Acceptance testing was missing 0 Team did not see value in TDD 0 More debates and arguments were leading to unhappy developers 0 Bad smells in code
- 35. Hurt: Defects slowed velocity 0 Helped: Test Driven Development 0 Hypothesis: TDD reducesTests Defects and defects. 700 600 500 400 300 200 Unit Tests Acceptance Tests 100 Defects 0
- 36. Better Smells 0 Teams were asked for mandatory testing . They could choose to implement the tests any way they want, but should have unit tests 0 Build systems were made smarter to publish test results 0 Category tags were used to group tests for quicker running. 0 Inject one or two senior developers who knew TDD well in every team- Peer pressure = great code All Rights Reserved – Vibhu Srinivasan 7/18/2010 36 http;//agilefaq.net
- 37. It works for me syndrome 0 One teams code does not interface with the other team well 0 Code working on local build fails to integrate 0 Its not easy to deploy the code to customer
- 38. Solution – Integrated build and deployment strategy 0
- 39. Odds and Ends 0 Mock objects were mockingly simplistic 0 Acceptance tests if not automated does not provide a whole lot of value 0 MOB Programming helps for cross team communication 0 A team agreement document is a must have tool.