Collaboration among several Scrum Teams working on the same product
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!
"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.
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.
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.