Scaled Scrum
Scrum Scaling Frameworks
“Since 2005, we've worked with clients to apply the LeSS (Large-Scale Scrum) framework for scaling Scrum, lean and agile development to big product groups. We share that experience and knowledge through LeSS so that you too can succeed when scaling.”
LeSS
—Craig Larman & Bas Vodde
The Nexus framework inherits the purpose and intent of the Scrum framework as documented in the Scrum Guide (www.scrumguides.org.) Scaled Scrum is still Scrum. Nexus does not change the core design or ideas of Scrum, or leave out elements, or negate the rules of Scrum. Doing so covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
Nexus
—scrum.org
Scrum, as originally outlined in the Scrum Guide, is a framework for developing, delivering, and sustaining complex products by a single team. Since its inception, its usage has extended to the creation of products, processes, services, and systems that require the efforts of multiple teams. Scrum@Scale was created to efficiently coordinate this new ecosystem of teams. It achieves this goal through setting up a “minimum viable bureaucracy” via a “scale-free” architecture.
Scrum@Scale
—The Definitive Guide to Scrum at Scale
The Spotify model is a people-driven, autonomous approach for scaling agile that emphasizes the importance of culture and network. It was successfully implemented at ING Bank, and is broadly used in many organizations and industries.
Spotify model
Challenges that Frameworks solve
Dependencies and prioritization
To scale Scrum, you need a single Product Owner with multiple Teams. Working as a single Product Owner requires rules beyond the scope of the Scrum as written. If you have several fully independent product owners, prioritizing the whole Product Backlog can become unmanageable.
To scale Scrum, you need a single Product Owner with multiple Teams. Working as a single Product Owner requires rules beyond the scope of the Scrum as written. If you have several fully independent product owners, prioritizing the whole Product Backlog can become unmanageable.
Quality Assurance and Release Management
When working on a common product, decisions about the level of quality should be uniform. This usually requires the introduction of standards, often inconvenient for individual teams. Centralized power is also needed for the process of product delivery to customers.
When working on a common product, decisions about the level of quality should be uniform. This usually requires the introduction of standards, often inconvenient for individual teams. Centralized power is also needed for the process of product delivery to customers.
Synchronization (between Teams, and between Business and IT people)
As the number of teams increases, so does the number of cross-team synchronizations. Overhead costs may be excessive or communication efficiency insufficient. Choosing optimal conditions (frequency, composition, agenda, etc.) becomes difficult and requires experience in Scrum scaling.
As the number of teams increases, so does the number of cross-team synchronizations. Overhead costs may be excessive or communication efficiency insufficient. Choosing optimal conditions (frequency, composition, agenda, etc.) becomes difficult and requires experience in Scrum scaling.
Goal Setting and Funding
Without a common approach to the Goal Setting for entire product group and each individual team, it is difficult to manage product PnL.
Without a common approach to the Goal Setting for entire product group and each individual team, it is difficult to manage product PnL.
Are you interested?
Write to us, we will contact you and tell you how this approach is applicable in your situation.
Might be interesting