Sprint Rhythm being changed by management

Are these teams all working on one product or are there multiple products involved? For cases where there are multiple teams working on one product, synchronization makes sense and can be found in the major scaling frameworks. This facilitates the delivery of a complete, fully integrated increment on a minimum cadence.

Regardless of the number of products supported, what does management hope to achieve by synchronizing the teams? I'd also be curious how they are aligning - is a new schedule being dictated or are the teams free to determine which schedule is most appropriate given the constraint that they are all synchronized?

I would point out that, in Scrum at least, the timebox is relatively stable and fixed. That means that you do not alter the timebox if someone has a day off (planned or otherwise). The Sprint begins and ends on a cadence. It can be changed with good reasons, but it's generally something that you want to do infrequently. The regularity adds some level of predictability in an otherwise uncertain event, which increases empiricism and the ability to make decisions based on data, and reduces the cognitive load of having to make decisions on when to hold events.

For starters I have a problem with the top down approach. I would have liked to see a more open approach to seemingly a problem management has.

What can you do to help open it? Have you invited them to explain their reasoning to those impacted by the decision?

one product or are there multiple products involved

We are working on multiple products behind the scenes and some of us work on the main website as well and that is a shared product. We have however synchronized releases for the website.

Regardless of the number of products supported, what does management hope to achieve by synchronizing the teams? I'd also be curious how they are aligning - is a new schedule being dictated or are the teams free to determine which schedule is most appropriate given the constraint that they are all synchronized?

To be honest I don't know their aim yet. So far they anounced the idea out of the blue and I want to know what the theory says to see if that supports either standpoint. Just doesn't feel very agile to me.

What can you do to help open it? Have you invited them to explain their reasoning to those impacted by the decision?

This will be my next step to have them explain to us why so we can understand where they are coming from. Information has just been sent to all teams.

If any of you could help me out with your past experiences regarding this or if you have some parts of the theory that I missed in my search that I could read, that would really help during the conversation.

Thanks in advance.

The first thing that you should do is have a conversation with management to determine what their objectives are. Synchronization between teams may provide some greater organizational benefit and it makes sense. As much as we want to favor self-organizing teams, the teams still need to exist within a broader organizational context. Having some rules in place to reduce differences between teams could have benefits, but you do want to use guardrails as much as possible, as opposed to the way of working being dictated.

What isn't clear to me is how the teams support the products. Ideally, you want a given team to be supporting only one product. That doesn't always work out for organizations for various reasons - they may have more products than teams. In this case, I suggest that each team should be aligned with a set of products. There may be cases where a team is working on two products at once, but if you have more products than teams, that is a risk. You'd have to go beyond Scrum for how to approach this.

Thanks for your reply Thomas.

By now we found out that it is merely an issue of higher ups not being available schedule wise and that is the reason the teams have to change their schedules. Even though it means changing maybe 50-60 schedules for the sake of 4-5 schedules. It seems pretty set in stone that they demand it this way without an open dialogue. Although I am trying to start the dialogue back up.

This is an interesting situation.

What events were these "higher-ups" interested in attending? It seems like they aren't on any of the teams, so the only event that I can think of is the Sprint Review. A Sprint Review without stakeholders is not valuable since that's one of the primary interaction points between a Scrum Team and stakeholders outside of the team.

Their methods for synchronization may leave something to be desired. Still, their desire to be able to effectively able to attend appropriate events is a valid concern that needs to be addressed.

I agree with everyting that @Thomas Owens has said but I still have a concern.  

By now we found out that it is merely an issue of higher ups not being available schedule wise and that is the reason the teams have to change their schedules.

I'm struggling with why the "higher ups" need to be available at all.  From my experience they are not stakeholders for products since stakeholders are usually external to the organization or proxied by Sales or Support.  I haven't experienced any situation where an executive manager was needed as a stakeholder and especially not as part of the Scrum Team.

"Higher ups" can be kept informed outside of Sprint boundaries so I don't see a reason to force Sprint boundaries to fit into their schedule. The Product Owner should be more than capable of providing insight into what is happening at any point in time.  And if the Product and Sprint Backlogs are visible, anyone can look into what is being addressed. 

As a Scrum Master I would continue to question why this is a good idea.  It is part of the Scrum Master's responsibility to help the organization and people external to the Scrum Team to understand how to best interact and how their interactoins are detrimental.