What are the possible/likely pitfalls of having async scrum teams?

Question

In our game project we currently have 2 teams that work in 2 week iterations. In the past we've repeatedly had issues with larger features (bad planning/estimates, unforseen issues before code freeze causing the stories to not getting closed, etc), and we've discussed those problems in many retrospectives.

Since the features we're supposed to implement are not getting any smaller or easier (actually quite the opposite), we've been thinking about ways to help us reduce the risk of each iteration. One such idea I had, was going with a setup similar to what ArenaNet does with Guild Wars 2:

[...] “And they’re all staggered, so even though we ship every two weeks, the development time for any one of these releases is around four months, it’s just that it’s a smaller team working for an extended period of time which allows them to give it the level of polish that players have come to expect. But it is intense!” [...]

The basic idea was to stick with the 2 week release cycle, but move the teams out of phase with each other, so that each individual team would have a total of 4 weeks to work on content. So basically, the setup would change from this:
to this:

Of course, the releases would be bigger than before, but at a first glance it seems at least somewhat beneficial:

• More time to react to unforseen issues (bugs, system failures, bus factor, ad-hoc design changes, ...) without endangering the whole sprint
• QA could focus on one team/feature/release at a time, instead of having to check everything from both teams at once
• Ability to work on larger features without having to chunk/split them into artificial segments to fit the sprints

Now I wonder if this was actually a good idea, or if I'm missing something obvious and it would just screw up everything. Are there any other resources on this topic? Are async scrum teams workable, or is it generally just a bad idea?

Answer 1

In the past we've repeatedly had issues with larger features (bad planning/estimates)

If you encounter planning/estimation problems just for two week sprints in advance, do you really believe this will get better if you now have to estimate your team's work for four weeks instead of two? Honestly, I think this will make things worse, not better (and it does not make a difference if your teams work synchronously or not).

Ability to work on larger features without having to chunk/split them into artificial segments

The need for splitting big features into smaller slices is IMHO a strength of the process - if you sacrifice this, your planning/estimation will become worse, your testing cycles will get longer and your ability to control the process will decrease. Thus I would heavily recommend against this. Better try to make the splitting of features not-so-artificial.

If you have bigger features to work on which cannot be completed in one sprint, split them up into smaller ones, but do not make those partly completed features available to your users immediately at the end of each sprint. Better, learn to utilize "feature branches" and "feature toggles" for your needs.

A better branching/merging strategy might also be an approach to untie your teams from the fixed "two weeks" sprint cycle - if the next feature slice fits better in 9 days instead of 14, whilst the other team needs 16 days, this should be perfectly possible. And your QA team can still get a new version every 14 days. You have to establish a strategy for this which allows you to prohibit the delivery of half-baked features from the development branch to "staging" in the middle of a sprint, without stopping your teams from work. There are different approaches how to accomplish this with Git, and of course, your configuration management effort will probably increase, but that is probably outweight by the benefits you get from this.