Skip to main content

Collaboration among several Scrum Teams working on the same product

Last post 12:32 pm September 1, 2022 by Michael Lloyd
3 replies
01:35 pm August 29, 2022

Given several Scrum Teams working on a wide product, which should be "shared/common" for those teams (e.g. in terms of way of working), apart from the Definition of Done, the Product Backlog, and the Product Owner?

 

I've already read about Nexus and LeSS but, apart from other frameworks, there could be some guidelines you may want to suggest based on your experience.

 

Thank you very much in advance!


04:16 pm August 29, 2022

"which should be "shared/common" for those teams (e.g. in terms of way of working), apart from the Definition of Done, the Product Backlog, and the Product Owner?"

I'd hope they would share the Scrum Values, but apart from that, and the things you mention for assuring a Done Product Increment, nothing.

There could be things which are either shared or common, such as terms of engagement between a Scrum Studio and the wider business, but should is too harsh a term. Scrum is minimally prescriptive and whenever practices are mandated you would wonder why. Nexus and LeSS are both framed in this spirit.


08:17 am September 1, 2022

Multiple teams working on the same product needs to be guided by the same values and make their integrated Increments meet the Definition of Done so can be released if decided. 

In my opinion, at same level of importance should be also what NOT TO DO: do not compare the teams based on the story points delivered. This can be a trap and is not the goal of Scrum framework.


12:32 pm September 1, 2022

Agree with Ian, and I think your original post basically covers the important stuff. 



The main addition I have is that I find many teams struggle to actually talk about what is or should be shared when they share a technology stack, platform, delivery pipeline etc. 



So while Scrum isn't going to mandate anything beyond the product backlog and product owner I'd suggest that the Scrum Master(s) may want to put some thought into helping remove barriers of communication and collaboration between said teams. 



Are they regularly talking about the work they're doing, the problems they're solving, and how they can help each other? 



Ultimately, a self-managing team should be solving these problems themselves, but my experience is that teams often fall into the trap of working in their own team silo until something really major goes wrong, so helping create transparency of those issues early is incredibly important. 


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.