Share
Multi Products Scrum teams are in reality observed often. One team serving different stakeholders and customer segments. Both would like to use the same people to work on their improvements.
In most organizations there tend to be more products than teams. While scaling frameworks give solutions on how to cope with a big Product and orchestrating value delivery among multiple teams. But how to deal with many products and a few Scrum teams?
During the NLScrum Meetup "Multi Products Scrum teams at Scale" we've shared views with 60 peers at our Xebia office in Amsterdam.
After presenting a brief overview of scaling frameworks: LeSS, Nexus, SAFe, Spotify and Scrum @ Scale. We discussed the following question:
IF you have multiple products per Scrum team,
WHAT are the advantages (up) and disadvantages (down) from the perspective of
- The Organization
- the Scrum team
- The Customer
Here are the main points:
Advantages multiple products per Scrum team for The organization
The team is serving a real product, it's clear where the team is for.
There is a limit in capacity of people / teams. So multiple teams can be a solution.
Disadvantages/concerns multiple products per Scrum team for The organization
- Coordinating and getting consent on priorities could cost more time and overhead.
- Lower priority items will never be built or take a long time (but isn't this an advantage?).
Advantages multiple products per Scrum team for The Scrum team
+ The team can stay sustainably together, as there is a constant flow of work
+ The team could share knowledge and skills amongst team members, which keeps the work interesting.
+ If the products have a clear commonality / purpose, this could give them focus.
Disadvantages/concerns multiple products per Scrum team for The Scrum team
- With multiple products, the team could suffer from context switching.
- Due to a broader spectrum of products, onboarding could take longer to learn each of them.
Advantages multiple products per Scrum team for The Customer
+ The team doesn't have to be busy with you as customer, while the knowledge of how it the current is built is trusted and contained within the team. For a request, there is no resource hunt needed first.
+ As the team has a tenure, they will have a better understanding of the context of the Customer, so will be able to deliver faster the right product.
Disadvantages/concerns multiple products per Scrum team for The Customer
- There will be competition among feature requests of the product, or some expertise could be over demanded. This means not anything will be built (now). Though, as a result, this invites making smart decisions.
Multiple products per Scrum team can be also a solution!
We concluded that multiple products per Scrum team isn't necessarily a bad thing. There are advantages too! Like keep a team, and thus the knowledge together. Spreading knowledge within the team about multiple products. And the circumstances to evolve to a high-performing team. Though the Product Owner has a though role in finding a balance in giving priority to the most valuable parts to deliver first and find consent among different customers.
The definition of a product is somewhat arbitrary
After questioning: how many products do you have in your Scrum team, some defined a few and some representatives defined many. More than 5 was among half the group! But on what basis did they distinguish multiple products? In the discussion it became somewhat arbitrary. One big application serving multiple purposes, is that one of many products? Or the other way around: one purpose served by multiple software applications. We can conclude that at least it helps when there is commonality and synergy to have the Scrum team serving a clear set of a product!
Technical challenges of multiple products and multiple Scrum teams integrating and delivering the product.
IF your product is a software product, multiple products can also have different moments or heartbeats of going live. Best practices around this challenge are shared under the secret label CICD. Continuous Integration and Continuous Delivery. So you can deliver multiple products independent and often to keep your feedback cycle as short as possible.
How to gain more insights around many products and agile delivery
Learn more about Scaling Frameworks via trainings. You can start with the overview training
Learn more about DevOps and CICD to optimize the technical delivery and quality assurance of your products in a complex organization.
Find the slide deck Multiple Products Scrum teams at scale here
Feel free to contact us about Multi products Scrum teams at your organization. Leave your contact details and we will contact you. Maybe we can host a session at your organization. Maybe we can have a consult of a few hours to get a more clear view on the challenge.
Read the related blogs