Multiple teams dependencies handling

Question

Scenario:

E-commerce platform implemented by following teams:

DevOps / ERP devs / web devs / native iOS devs (hybrid App) / native Android devs (hybrid App)

we are using Scrum like (not scaled) / Scrumban, each team has its own backlog and there is not a defined role to handle dependencies between teams. This scheme doesn‘t work as very often we have blockers between teams and not a clear responsible to handle them. I would like to know which scheme / methodology / framework is recommended in this context.

Answer 1

The cross-team dependency is a known problem on large scale projects. We're running a project with four teams sharing the same platform, and the solution boils down to communicate... a lot.

Specific actions to take into account on how to manage these dependencies:

• Avoid cross-dependency as much as possible; it's a no brainer, but sometimes you need someone with a pair of fresh eyes to review the way the platform is built to propose some decoupling
• when decoupling is not possible, try to have clear interfaces between applications (technologies, as it seems in your cases); This way, one implementation will be valid for all applications so long they adhere to this common interface
• During sprint plan, assess which tasks are dependent by more than one user story; one one story that depends on this task is prioritize, make sure the other stories are aware of it (if you use a software to track stories and tasks, a simple way is using links between them)
• Once a task that will impact more than one story becomes priority on the backlog, ensure the broader aspect of solution proposed is considered, to avoid situations where the task delivered only fits one story but not all of them
• Once the task is completed, ensure the other teams are aware of it. Running a scrum of scrums is a way of doing this, but there are plenty... it'll all depend on your team structure. We use for instance a Confluence board showing the latest 'core' changes built

All the best!

Answer 2

Scrum of Scrums (SoS) is a lightweight scaling approach

Unlike some of the other scaling approaches, in the Scrum of Scrums you don't need dedicated resources for coordination.

Mike Cohn sites following experiences using Scrum of Scrums:

• In this way, we have worked on projects with more than 500 people and have consulted on projects with more than 1,000.
• each team identifies one person who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams
• In many organizations, having a Scrum of Scrums meeting two or three times a week is sufficient.

I have used Scrum of Scrums to coordinate across 4 teams. In our case, we met twice a week and had more than one person (Architect, Product Owner, Scrum Master) represent each team. Some of these people handled multiple projects.

Our SoS meeting agenda typically consisted of two main items:

• Cross-team dependencies: Where one team is building, say a component, which will be used by another team.
• Resource contention: We had some shared resources. We negotiated the priorities and what % of time of the shared resource will be available for each team.