multiple scrums code integration

Question

The company where I work has been trialling scrum on a project and is now looking to roll scum out to three or four different project teams. We are envisaging that these teams will work in separate feature branches (we are using SVN).

We are not sure if the different teams’ sprints should end simultaneously or if we should stagger the sprints so that the sprint ends and releases are separate. The product is a web site so deployment isn’t a problem.

We are concerned about code integration, if three teams integrate their code at the same time, is this likely to lead to conflicts. But if the releases are staggered this load may just be moved to the teams which are mid sprint.

Has anyone tried either approach and what have they found to work?

Answer 1

We have two teams with synchronized sprints and it seems to work quite well. Our strategy is to keep the stories small. Get the stories done and publish them up to trunk often during the sprint. Yes we do get merge conflicts but they are manageable.

Oh and make sure the teams communicate well with each other.

Answer 2

We also have several teams, our sprints are aligned, and we integrate continuously: when a story is complete. This is sometimes annoying, but that way we avoid long integration periods that could be painful. Each story is developped in a separate branch, and then integrated in the main branch. When two teams needs to share something that is not integrated, they work in the same branch.

We're building a packaged product, so deployment is not an issue for us.

The two questions are tied together: if you only integrate at the end of the sprints, which I'd not recommend, then you're better off staggering the sprints.

Henrik Kniberg (author of Scrum and XP from the trenches) wrote an article on Version Control for Multiple Agile Teams.

Answer 3

have a look at this article, explains these issues succinctly. http://www.infoq.com/news/2008/04/kniberg-agile-version-control

Continuous Integration. Integrate all the time, at every check-in, don't wait till the end of the day or end of an iteration to integrate. Have unit tests, and automated acceptance tests that run on every check-in to ensure that no one breaks the code.

Plan smaller features, work on smaller pieces of work. Smaller chunks are easier to fix when things break. Are all the teams working on the same product / code line ? You can try planning the features so that the features don't affect the features another team is working on. Try attending the other team's stand-ups so you can resolve integration conflicts earlier. Share the work if features conflict.