I doubt it’s luck. In every place I’ve ever seen Agile in use, they treated 2-week sprints like you describe iterations. It was generally expected that portions of stories would roll into the following sprint and there was a high degree of trust and autonomy in letting teams organically decide if & when any stricter deadline needed to be imposed.
One week sprints are also fine, but I’ve always found everyone hates them for doubling the number of planning / backlog / etc. “process” meetings.
One month is often too infrequent for these meetings, one week is too frequent, so 2-week sprints appear from this sort of naturally. As long as you don’t conflate the timing of the sprint with the timing of work tasks (eg accept there are single work tasks that cannot be chopped up into two week incremental subtasks) this seems fine.
The problem I've seen over and over again, and others have mentioned here in this great thread, is that when you have a 2 week sprint... if a feature misses the sprint, it is another 2 weeks before anyone sees anything... so now it is a month, which can be really unfortunate.
It gets especially bad if there is a lot of fire fighting happening as well because someone might get pulled off that feature and now the time goes to infinite...
The idea is to try to prevent that type of common delay.
That’s not how I’ve seen it work anywhere. If you do 2 weeks of work and the feature is a few days away, the portion of work that continues into the following sprint is just a few days, and then you see it.
Fire fighting is just as likely to prevent completion in one sprint as the other, so there is no net change in how the effects of context switching for firefighting slow progress.
Of course, restructuring teams and work so that firefighting effects are reduced is always the goal, I’m just saying it doesn’t matter at all in terms of when the arbitrary cadence for syncing and planning are chosen.
One week sprints are also fine, but I’ve always found everyone hates them for doubling the number of planning / backlog / etc. “process” meetings.
One month is often too infrequent for these meetings, one week is too frequent, so 2-week sprints appear from this sort of naturally. As long as you don’t conflate the timing of the sprint with the timing of work tasks (eg accept there are single work tasks that cannot be chopped up into two week incremental subtasks) this seems fine.