How to deal with weird development cycles?

Are others on the team also aware (and acknowledging) that this is a problem? I wonder if you could document several examples (in a non-confrontational written doc) which clearly shows the compressed time for actual execution based on your current planning cycle.

I imagine the main people responsible for the current setup are your manager and some sort of TPM or PM. Can you explain the benefit of having a more regimented planning timeline? It sounds like the issue now is that the planning consistently takes longer than expected, and you can brainstorm how to improve that:

• assign a DRI to make the decision
• move synchronous debates to be async to make them faster
• gather more of the project requirements earlier, so planning is not as taxing

Another thought is to ask why the planning/execution phases have to be so distinct? It feels like an anti-pattern to me to only do planning for weeks, and then execution for a few weeks. (I imagine it's not actually that extreme due to things like on-call and ad-hoc requests). Could you have some longer-running (perhaps lower priority) projects that cut across sprints? Then you have an outlet (pressure release valve) when things become stressful.

Without too much context, I think you can do a few things to start with

• understand why the planning is so long?
  • too many dependencies?
  • lack of domain experts?
  • hard to size?
  • hard to get alignment?
• Plan for longer? there are times it takes long time to plan out a long term roadmap. From sprints to sprint, you really should not re-plan lots of milestones.
• are there lots of disruptions where your requirements to deliver changes?
  • then that's a different set of problems to address.