I prefer a structure of: variable length sprints + optional 1 week interlude. I don't understand why the "sprint length" is this set-in-stone thing. "We do 3 w

I prefer a structure of: variable length sprints + optional 1 week interlude. I don't understand why the "sprint length" is this set-in-stone thing. "We do 3 week sprints, we never deviate". That's not very agile. Sometimes you've got very well-defined requirements on a large project and you could go heads-down for 3 weeks on something. Other times, you've got a good "phase 1" that would take 1 week to implement; so let's implement that, then plan the next sprint. Or you might want to take a sprint to just write more tests, upgrade dependencies, etc. Plan it, take a week, then lets resync. The interlude week is used to decompress and give engineers time to plan their own schedules. They can work on whatever they want; they create the plan, create the tickets, and execute. Ideally it should have some thread of connectivity with the team's overall mission, even if only slightly. Leadership uses this time to plan the next sprint. There's a natural "bulk up" on meetings during this week that were avoided over the sprint itself. Specifically: the planning and retros happen during this week. Most teams I've worked on put the Retro on the final day of the sprint. At one place it was at like 11am. This is crazy! Combine that with a typical Friday drop in productivity and you've just written off the entire last day! During a 2 week sprint, that's a full TEN PERCENT of the sprint. Instead, schedule the retro on Monday morning during the interlude, and full team planning on Friday before the sprint. Often those interlude weeks end with work that's best classified as either "hackathon-style" (this is cool, not sure if we can use it right now but lets bank the code and revisit) or "infrastructure" (we've wanted this done for a long time, but it never got priority, we've finally done it, awesome). Burntout engineers will naturally schedule themselves less to do or easier things, like dependency upgrades; this is a great signal to management that something is up and we should talk about it.