Are Self-management and Synchronisation at odds in a Scrum Team?
As with most things in Agile, it depends.
For the past months, my Scrum Teams are being coaxed into quarterly PI Plannings and synchronised Sprints. We decided to evaluate these developments in a retrospective in an attempt to create a clearer understanding so that we can communicate better with management. We found that although the team sees the advantages in synchronising with other teams they work with, the general reaction was quite negative.
As Willem-Jan Ageling describes very eloquently in one of his latest articles, the Scrum Guide has always taken into account the fact that Scrum Teams will often work together on a single product. The original Scrum Guide, published in 2010, made it very clear that in this context synchronisation makes sense:
When a Team begins Scrum, two-week Sprints allow it to learn without wallowing in uncertainty. Sprints of this length can be synchronized with other Teams by adding two increments together.
— Schwaber and Sutherland 2010 —
Synchronisation seems like an obvious choice. So where did the resistance from my team come from?
Synchronised Teams
Let’s start by examining what synchronised teams are. The Scrum Guide is quite clear about this:
If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner
— Scrum Guide 2020 —
Synchronisation is the result of the fact that all teams share a single, integrated purpose.
But this is not what I often see happening in real life, especially in bigger organisations. There, synchronisation seems more of a governance tool, more like a purpose in itself.
To help us discuss synchronisation in a way that is acceptable for all these disparate perspectives, I think we need to focus on the most basic meaning of the word. In that sense, I would say that two teams are synchronised when they at least:
have Sprints with the same length and,
start and end their Sprints on the same day.
Everything else is a grey area, like for example whether the teams should share events, or whether they should start and end the Sprints at exactly the same time.
I would argue that many of these grey areas involve factors that are not so much a requirement for synchronisation, but instead that they are possibilities that arise from synchronisation. So for example, because teams are synchronised, they can choose to start and stop their Sprints at exactly the same time.
Why two teams would want to do this, is indeed the real question we should be asking. Indeed, new possibilities mean new choices that must be considered.
But what I find more interesting than the choice, is the consequences. So for example, because synchronised teams share the same rhythm, it means that they share the same context of time. They share the same focus at any moment during the Sprint. At the start of the Sprint they are focused on planning and discovery and towards the end of the Sprint, they share the same sense of urgency and attention to detail.
This shared state of mind makes collaboration more obvious, making synchronisation easier and even more attractive. It is the human factor, where the motivation of the team determines how easily the desired outcome can be achieved. It is a positive feedback loop, which creates a natural evolution towards ever-greater collaboration. You can see how this might lead to for example fluid teams as described, again, by Willem-Jan Ageling: Fluid Scrum Teams vs Fixed Scrum Teams — A comparison.
This evolution does not only apply to the teams, of course, but also to the stakeholders. Stakeholders can more easily coordinate with the teams, sharing the same focus as the teams do. So for example, when stakeholders are involved in reviewing results and providing feedback, it is with all the teams. It will make it easier for them to understand all results in the context of the whole. Due to the synchronisation of the teams, stakeholders are treated to a cohesive narrative, in which stakeholders can in fact treat the various teams as one entity.
This will naturally encourage them to participate more, and maybe even get involved in improving the process together with the team.
Self-management
So, having looked at the advantages, how is it that some people are very much against synchronisation? How is it my Scrum Teams are not enthusiastic about synchronisation? It seems that it often has to do with self-management. Scrum Teams should have the autonomy to decide for themselves the length and rhythm of their own Sprint, and synchronisation conflicts with that.
Looking at the length of the Sprint first, I have worked with teams that prefer a 4-week Sprint, but I’ve also worked with teams that would rather have a 1-week Sprint. This variety in the length of the Sprint is not random, chosen at a whim, but is driven by the dynamics of Scrum. A good understanding of the context in which the team operates is essential to understand these dynamics.
Let me give you an example. Some kinds of work may result in stories that do not fit well in a 1-week Sprint, automatically forcing the Scrum Team to consider lengthening their Sprints.
A second example is team maturity. I have noticed that in general, young teams work better with shorter Sprints, as it makes the events easier to do and helps the team to get used to the rhythm of a Sprint. As the team matures they develop the skills necessary to be able to manage longer Sprints, and opens up the possibility of lengthening the Sprint.
Starting and ending the Sprint on the same day can pose its own specific problems. For example, even teams with the same sprint length may want to choose different days for their events to deal with uneven working hours, planning the events on those days where everyone in the team is available.
I often see teams starting Sprints on Monday and ending on Fridays. This seems like a natural rhythm. Friday is for endings and Mondays for starting new things with renewed energy.
However, I’ve also had teams that very consciously choose not to start the Sprint on Monday, preferring to have the Sprint end and start on consecutive days, or even on the same day. Reasons vary from the experience of Mondays as the worst day of the week to wanting to put the ideas and the energy generated in the Sprint Review and Retrospective into action as quickly as possible.
Looking beyond the team itself, the same may apply to stakeholders too. For example, imagine teams that are synchronised but have decided to maintain separate events. Stakeholders may find themselves having to be at too many Sprint Reviews at the same time. Similarly, they may struggle to keep an overview when all the Sprint Plannings are being held at the same time.
What is clear is that besides all the advantages of synchronisation, there are also real costs. Whatever the reasons for synchronisation, it will only work if the benefits are greater than the costs. And only the teams can decide that.
It is all about collaboration
How then to solve this conundrum? The right choice, I think, depends on one thing only, and that is:
how are the teams collaborating?
I can’t think of any other valid reason in the context of Scrum that would require synchronisation. Collaboration between two teams or more is what determines the need for synchronisation.
Put simply, two autonomous and professional teams, mature in their understanding of Scrum, finding themselves in the need to collaborate intimately will eventually take synchronisation into account as a possible solution.
Their quest towards ever-improving value delivery, and the positive feedback created by increasing collaboration, will make it natural to synchronise, simply because the increase in value created by synchronising will outweigh the cost in flexibility.
The role of management is to facilitate these developments. Facilitation is the key. Encourage, connect and provide time and resources. Create vision so as to give purpose and direction to the collaboration. But the most important task is to not make decisions. Do not impose anything. Always give teams the opportunity to decide. Do not protect them from problems, let them solve them.
And therein lies probably the main reason that many teams are so resistant to synchronisation, the fact that it is not always employed with the team in mind. Instead, it becomes a tool for something else. Delivering a quarterly plan to higher management for sign-off. The need for neat monthly reports.
The point is that it feels arbitrary for teams and they are usually not involved in the decision. They are not included in exploring the problem and possible solutions. The costs may even outweigh the benefits. This goes so much against the self-management of the teams that it is terrible for morale.
The answer seems so simple. And that is precisely what Agile is trying to tell us all the time:
do not think about the process before you understand the people involved,
take a breath and think about root causes, what is the real problem we are trying to solve,
do not make assumptions, experiment, feel your way,
leave it to the teams to figure it out,
don’t force it, be like water and let yourself be guided to the optimal solution.
