Definition Of Done ( Mulitple Teams )
This from the Scrum Guide :
If there are multiple Scrum Teams working on the system or product release , the Development Teams on all of the Scrum Teams must mutually define the definition of ' Done ' .
So what I understood is :
It doesn't clearly mention that there's ONE definition of " Done" ( yes , it sounds like that ) , the purpose is to insist on the rule that it should be mutual . Based on Scrum.org , there can be multiple definitions of ' Done ' when multiple teams are working on the same product . we just have to be sure :
1. They are compatible , and capable of creating ONE integrated Increment at the end of the Sprint .
2. They should all follow the minimums set by the development organization ( because of the orgnisation standards ) .
Any other thoughts would be very helpful & appreciated
BRs
Remember that as well as achieving 1 and 2, it’s important that people actually share the same understanding of what Done means and are not confused by context.
The organization I'm in has been using a unified definition of done across all teams, which includes integration across the system as part of it. We've been very unsuccessful thus far in getting product increments to meet this unified DoD. Sometimes it boils down to one bug that only one team has the relevant knowledge to address. And this has a deflating effect on the other teams that feel they delivered to their potential but don't get to celebrate victory because their success is at the mercy of other teams. This has happened enough times now that it has led to a substantial decrease in morale across teams. While it's undoubtedly important to foster collaboration and integration across teams in order to come up with an integrated product increment that is potentially shippable each sprint, how should a scrum master weigh that against the frustrations that can arise among teams as in the situation I just described?
Have a look at the Nexus Guide. One of the skills which teams must demonstrate, when collaborating to create an integrated increment, is the management of joint dependencies. The teams constitute a nexus for implementing an integrated product, and not rival teams. They ought to have a shared goal and, to an extent, shared shared events and artifacts which will promote satisfactory transparency over their dependencies and their ability to control them.
Thanks Ian. Will do