Pros & Cons of Synchronizing Sprint Schedules
Is it always beneficial to have sprint schedules synchronized? What are the pros and cons?
In my current organization there are multiple products that in turn have multiple scrum teams associated with them and, while most of these are on a similar (if not identical) sprint schedule (both in duration and calendar-wise), there are some teams that have longer sprints or whose sprint schedule does not coincide with the majority as well as there are teams that are using kanban.
In my mind - I don't see much value to synchronization of sprint schedules... perhaps I am missing something important?
In what scenario(s) would it be really important to try and synchronize sprint schedules?
In what scenario(s) would it be better to have sprint schedules be asynchronous?
Suppose multiple teams work on the same product. Could that influence the need to synchronize -- and if so, why?
Beyond Ian Mitchell's comment about multiple teams working on the same product, there may also be considerations around teams working in the same product portfolio. Consider a portfolio or suite like Microsoft Office. There are different ways to organize teams around products (like Word, Excel, PowerPoint) and there may be teams supporting common or core pieces as well. The nature of marketing these products as a suite may drive a level of coordination among the teams that may be helpful to synchronize.
There are also different ways to synchronize Sprint cadences. One way would be to align every Sprint's start and end dates along with the events. However, you could also perform multiples. A team that is running 1-week Sprints, a team that is running 2-week Sprints, and a team running 4-week Sprints could synchronize every 4 weeks, for example. If you were to add teams working with a just-in-time approach, they could plan on a synchronization point that happens to align with one or more of the teams as necessary.
When talking about synchronizing Sprints, you should also consider when you need to align the teams with their stakeholders and against schedules and budgets. Different environments have different levels of tolerance or ways of dealing with teams that aren't necessarily synchronized.
How effective are Sprint Reviews at the moment; particularly taking into account how it is described in the Scrum Guide?
Do such Sprint Reviews result in meaningful feedback that can lead to changes in the next (or a later) Sprint?
If so, then to build on Thomas Owens' point, would there be a logical Inspect & Adapt moment, where the feedback gathered on one product, could affect the future direction of another?
there are some teams that have longer sprints or whose sprint schedule does not coincide with the majority as well as there are teams that are using kanban.
What are the reasons for such variation? For instance, does the variation in Sprint length represent an empirical decision, after considering evidence, the needs to Inspect & Adapt, and the risk involved in investing each Sprint around a particular Sprint Goal?
What needs are there for some products to be developed with Scrum, and why is Kanban considered a more appropriate choice for others? Was it ever considered to use Scrum and Kanban in combination?
The reason I ask is I've previously encountered organizations where Scrum is merely seen as an internal process for the Scrum Team, and attempts are made to adapt Scrum by shoehorning in traditional practices. As Scrum exposes pain points, the reaction can be to apply an anaesthetic to Scrum, rather than treat the underlying condition. The result is an empty process that neither builds trust, self-organization nor the structures for real accountability.
A common response to this from teams is then to then use a very loose Kanban as an escape, because the benefits of a disciplined approach towards Kanban are often even more poorly understood.
I see each Scrum Team as a different company. If they are independent, they should be able to decide how they want to deliver. This is also why I prefer one week sprints. Less issues with synchronization if the sprints are shorter.