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:
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?