Using the Nexus framework
Our company currently has 3 teams working on 3 different products. Each scrum teams between 6-9 which has served us well over the last year or two.
The way our products are taking share now throws up some challenges and we're looking into different ways to address our dependency issues.
I have looked into Nexus and it seems it's best suited to a single product, is this the case in the real world or has anyone used it across multiple products?
The Nexus Guide says:
"A Nexus is a group of approximately three to nine Scrum Teams that work together to deliver a single product"
This arrangement isn't just something "best suited" for a Nexus, it's definitive and explicit. If there's more than one product to be considered at scale, you'd have more than one Nexus.
Should dependencies exist between one Nexus and another, a single Product Backlog is implied which would allow those dependencies to be visualised and managed for a single overarching Product.
Nexus is designed to give some structure to the collaboration to multiple teams that are working on a single product.
I'd want to better understand the nature of the dependencies. You may want to look at ways to decouple these three products and reduce or eliminate those dependencies. Alternatively, perhaps you don't really have three products.
Hi guys thanks for the comments, I would agree with what the nexus guide says in terms of a single product.
Perhaps Thomas is right in terms of decoupling the products. I think it's safe to say whatever we do we'll need to consider if nexus will help or hinder.
It's my belief that whatever we do, it has to add value and help with transparency.
I like to remind people that a product is something that others want and use. However, it doesn't have to be something that is sold to the outside world. In more than one case when something similar to your explanation happens, I have been able to find a "product" that is used internally by multiple products that are sold external. Think of it is an internal infrastructure product. Putting a team focused on that product can eliminate dependencies because they will be able to learn what others need in order for the external products to work and provide those. You may think that this would lead to more dependencies and in the beginning it usually does. But after one team is able to focus on that shared functionality, it becomes possible for them to see ahead and provide things that the other teams don't realize they need.
Great comment again and I'm thinking is this where we are. Do we need a team to work om this as a internal product.
Plenty to think about, so thank you all for the input.
We do it. Currently have 3 teams on the same product. It works well but it’s a lot more challenging than we anticipated. Our teams were used to scrum so we thought the transition would be smoother, we are now about 6 months into using it and finally getting our stride. A lot of struggles centered around backlog refinement and nexus integration team.