Skip to main content

Using the Nexus framework

Last post 05:24 pm September 21, 2023 by Todd Ruiz
6 replies
10:55 am August 25, 2023

Hi all,

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?



 


11:46 am August 25, 2023

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.


11:54 am August 25, 2023

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.


12:34 pm August 25, 2023

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.


02:04 pm August 25, 2023

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.


03:41 pm August 25, 2023

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.

 


08:44 am September 21, 2023

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.