With agile projects, cross-functional teams work together during every sprint of the project, doing the same types of work each sprint and implementing requirements from the product backlog into completed, working, shippable functionality. When multiple teams work from the same product backlog, however, you have new challenges to address.
Common challenges with more than one scrum team working on the same project include the following:
- Project planning: Agile planning is collaborative, from the beginning. Collaboration for large groups is different than for single scrum teams. Establishing a vision with the broader project team (all scrum teams and stakeholders) and building a product roadmap and product backlog with collaborative input from all parties involved requires a different approach than with single-team projects.
- Release planning: Similar to the challenge of project planning, releases involve more specific planning of scope and release timing. Coordinating who will work on what and when throughout the release cycle is even more critical to ensure that dependencies, scope gaps, and talent allocation match the needs across the project.
- Decomposition: To break down larger requirements in the same backlog, multiple teams may need to be involved in research and refinement discussions and activities. Who initiates these discussions? Who facilitates?
- Sprint planning: Although not the last opportunity to coordinate planning and execution between scrum teams, sprint planning is when scrum teams lock in a certain amount of scope from the product backlog to execute. At this stage, dependencies between scrum teams become reality. If the preceding activities of developing the product roadmap and release plan have not exposed dependencies, what are some ways scrum teams can expose and address them at sprint planning?
- Daily coordination: Even after effective planning and collaboration from project initiation through sprint planning, scrum teams can and should collaborate each day. Who participates and what can be done while teams are in execution mode?
- Sprint review: With so many teams demonstrating their product increments and seeking feedback, how can stakeholders participate with their limited schedules? How can product owners update the product backlog with all that was learned across multiple scrum teams? How do development teams know what was accomplished by other development teams?
- Sprint retrospective: Multiple scrum teams working together make up a broader project team. How do they identify opportunities for improvement and implement those improvements across the program?
- Integration: All product increments need to work together in an integrated environment. Who does the integration? Who provides the infrastructure to the teams? Who ensures the integrations work?
- Architecture decisions: Who oversees the architecture and technical standards? How can these decisions be decentralized to enable teams to be self-organizing and work as autonomously as possible?
Some scaling frameworks offer solutions to challenges you may not have. Be careful not to bloat your framework fixing things that are not broken.
In general, a product is a set of features that provide some sort of value or usefulness to a customer. A project is a planned set of work that requires time, effort, and planning to complete. It has a distinct start and end. A program is a collection of projects with an affinity to each other (addressing a certain market segment or rolling into the same product). A portfolio is a collection of programs and projects used to meet specific strategic business objectives. The projects or programs of the portfolio may not be directly related to each other but are grouped to facilitate management of the work.
Since the first scrum teams in the mid-1990s, there have been agile projects requiring multiple scrum teams collaborating effectively together. Following are overviews of various scaling frameworks and techniques addressing many of these challenges.