(this article is part of the upcoming “97 Things every Scrum practitioner should know” by Gunther Verheyen (editor))
When applying Scrum to a product with more than one Development Team, there is really little guidance in the Scrum Guide. The Scrum Guide seems focused on one-team Scrum for the most part. The only hint you get is in the Product Backlog section:
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed. (Scrum Guide November 2017)
We learn that, with multiple teams, we are advised to still use a single Product Backlog. Nothing is mentioned regarding the roles of Product Owner, Development Team, or Scrum Master other than “multiple Scrum Teams” working on the same product.
But how do you decide over priorities? If we take the Scrum Guide literally, there could be more than one Product Owner in each of the Scrum Teams on that product, or it could be the same person for all the teams involved.
Generally, this is the distinction between “Multiple Scrum Teams” and “Multi-Team Scrum”.
“Multiple Scrum Teams” typically holds that each Development Team has a Product Owner, yet there is a single Product Backlog. That means that potentially different people in the role of Product Owner need to coordinate with each other regarding their individual priorities, and come up with the most valuable items to be worked on.
Sometimes this set-up seems connected to having different specializations in the Development Teams. This works well if the workload on each of the specialist topics is evenly distributed across the different teams - and will stay that way for the near future. If that is not the case (which is highly likely), then one team might end up working on lower-priority, and thus lower-valuable, work for the product, just because that type of work is their specialty.
This setup generally also complicates the transparency of insights into the whole product. Not only is the in-depth knowledge about the product split across the different Scrum Teams, but also across the different Product Owners. After development on particular features has finished, additional coordination is needed on the different partial results of the product in order to have them integrated into a whole product that can be released to the customer and user. Unfortunately a Multiple Scrum Teams setting provides little incentive for cross-team collaboration, since everything will be taken care of by the additional coordination overhead that it produces.
In a “Multi-Team Scrum” setting, there is not just a single Product Backlog but also a single Product Owner who works with the multiple Development Teams. The sole Product Owner makes product-wide decisions that are fully transparent via the single Product Backlog, and the product versions created.
This setting demands a cross-functional approach from the teams. Specialization in the customer domain may still happen, but will have to dissolve once priorities and demands start to shift. For example, one team working on accounting functionality will have to shift from accounting features to another type of features if there are no longer any accounting features at the highest priority in the Product Backlog.
This setting therefore lays the demand for coordination with the teams themselves. They have to make sure to deliver an integrated product Increment at the end of every Sprint. Depending on where you start, this may result in a steep learning curve.
RSS feed