Distributed team and there are some dependencies including both technical and functional that these dependencies cause delay and leading up to a failure of a sprint

[Dingshan Li]

Yes, distributed teams will cause side impact to the whole product/project team collaboration. If there were many dependencies among teams, the situation will become worse. It is not the issue caused by Scrum. But it becomes very outstanding issue by the Scrum adoption because Scrum wants very close collaboration among teams and users. To optimize it (if we cannot avoid it), my personal experience is that to set up teams very carefully before the project/product kick-off. For one product team I coached, I organized a workshop for all of the team members in Shanghai to discuss about how to organize teams. The workshop include all of the important stakeholders, like senior team members, team leaders, managers and etc. We created a product features big picture first to realize the dependencies among each feature. Then we tried to group those features to minimize the dependencies cross groups. That means we tried to limit most of the dependencies in the group as many as possible. Then we tried to set up teams for each feature group (include both Shanghai and US teams). After the workshop, we provided the team setup proposal to our US development managers. Based on that proposal and more discussion, we finally set  up four relatively separate team. 

Another thing needs to be considered in advance is some external dependencies. Like one of our feature depends on a platform team's results. That kind of dependency caused the delay of our project. So if possible, I would suggest the whole product planning needs to solve this issue. One option is to remove those platform team and distribute the requirements to each feature team. This solution needs very good collaboration among teams to avoid duplicate or conflict work. Another one is develop those base platform in advance so it may provide a reliable common base for other teams to start their work. Either solutions have their pros and cons.  Some discussion about Scrum Scaling have relative suggestions.

[Dingshan Li]

From Hugo:

I agree. I chose the option 2 in my team, but obviously, it's not a typical Scrum style.