2

I am a Scrum Master for a team which I think are quite mature in terms of Agility.

They have raised an impediment of having too many synchronisation meetings with individuals from other teams and the project manager for our department.

The say they are too long, unstructured, undocumented and numerous.

What is the correct approach to handle this in an Agile way. Is there a well known mechanism? e.g. SoS

1
  • Can you elaborate on what the teams need to synchronize? "What is the correct approach to handle this in an Agile way" is an oxymoron. Apr 13, 2023 at 18:41

4 Answers 4

2

TL;DR

You are missing a central coherence that ties the teams together. You are also missing one or more roles focused on integration of the work developed by each team.

Analysis and Recommendations

A "synchronisation meeting" is one of those terms that doesn't inherently mean anything. What are the teams synchronizing? What are they trying to coordinate? Why are the meetings too long, unstructured, or otherwise unproductive? Until all the teams and stakeholders perform some sort of root cause analysis or retrospective that results in actionable changes to the process, the problems will continue.

Scrum is a single-team framework. Other frameworks such as Nexus and SAFe are inherently multi-team, with the central notion that there's a coherent increment being built that requires collaboration and coordination between multiple teams. This functionality seems to be missing from your current process.

In Scrum-of-Scrums, generally the Scrum Masters (or their delegates) collaborate across teams. In Nexus, there is a dedicated Nexus Integration Team accountable for integrating the work from all the teams involved in building the increment. Other frameworks handle this in other ways, but the central idea of having a common point of integration is essential to multi-team agility.

Your next steps should be:

  1. Clearly identify the friction points of the current process.
  2. Collaborate with the other teams to reach consensus on the problems.
  3. Develop new roles, processes, or practices to reduce the perceived problems.
  4. Treat these changes as experiments, and define how you will measure the success or failure of the changes.
  5. Routinely inspect-and-adapt the changes until you reach a sustainable process with a predictable cadence.

Adopting a Scrum-of-Scrums, Nexus, LeSS, SAFe, or any other framework or practice won't magically fix the problems you've described. What's needed is better communication between teams, and a commitment to collaborating on building a better process through continuous improvement. If you have that, the framework you eventually adopt to overlay or replace single-team Scrum doesn't really matter. It's the communication, transparency, and organizational trust that creates success, not the implementation-specific details of how you get there.

1

If the teams are using something Scrum-like, you can probably draw upon frameworks like LeSS or Nexus for inspiration. Although they are scaled Scrum frameworks that are based around multiple Scrum teams, if the work is happening within synchronized, fixed-length iterations, you can draw on the techniques around how to manage the Product Backlog, plan your Sprints, review the products, and perform retrospectives.

If not all teams are using something Scrum-like, then it becomes harder. It may be a good discussion on setting up a product-level process framework to help the team align on product-level events and milestones and work on more detailed synchronization from there.

0

A few approaches I have seen work well include:

  • Have a member of a team you need to closely synchronise with attend your standups (perhaps not all of them, but regular enough to share knowledge)
  • Have a dedicated synchronisation channel (using Slack, Teams, etc.)
  • Use a Scrum-of-Scrums meeting weekly or more frequently
0

Optimising communication channels is a tough one as people don't want to miss anything, while at the same time team quickly become overwhelmed with information, as the number of external dependencies grow.

I think the issue is not process as such but organisational design. I would recommend reading Team Topologies

I would also consider organising teams into tribes where inter-tribe dependencies are more urgent and communication is frequent while intra-tribe communication is less frequent.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.