I have been a scrum master of one single project of a co-located scrum team for last one year. Our program has been expanding rapidly and we are forming multiple scrum teams. The plan is to have one more local scrum team and also one distributed scrum team across a different time zone. So the questions are:

  1. How do I setup continuous integration in a multi-team distributed environment without running into issues of broken builds?

  2. How do I plan for the frequently shippable increment Sprint on Sprint basis of all three projects combined?

  3. Any other things I need to watch for or take care of for setting up such an environment? My idea is to make it first time right from process standpoint (at least most of the process).

  • Re item #3, worth reading: pm.stackexchange.com/q/4254/430
    – Tiago Cardoso
    Mar 24, 2014 at 13:35
  • I can't decide if this is a Scrum-of-Scrums question or a CI engineering question (which would be off-topic). I think the question needs a bit of clarification to narrow the scope of possible answers.
    – Todd A. Jacobs
    Mar 24, 2014 at 19:41
  • The question is from process perspective on how to deal with issues related to CI rather then implementing CI. The idea is to make sure that all the teams involved will not have to deal with fixing issues with such as broken build considering the teams are distributed and in different time zones. One example on the kind of response i am looking for is how do we have a handshake between teams when one team finishes their day and the other team begins their work etc.. Similarly what other things i need to take care more from process perspecive than implementating from engineering perspective
    – ramu
    Mar 25, 2014 at 10:27

2 Answers 2


This is actually a challenge the Scrum team should figure out, under your guidance. You should be sure the challenges listed in your post is understood by the team members, and then let them sort it out.

Your role as a ScrumMaster is not really to come up with solutions - that's the team's job - rather it's up to you to remove obstacles for the team. Say they come back to you with a solution which requires someone funding a new server - that's an obstacle you can handle.

But the CI system design itself, that should be handled by the people who are going to use it.

Also keep in mind that developers might highly resist a solution forced on them from above. Regardless if the system is beneficial to the development process or not.

Getting buy-in is much simpler, if the developers are involved in the setup themselves.

If however you for some reason want or need to do this yourself, I'd suggest asking over on Stackoverflow.com or Programmers.stackexchange.com as it really is a quite technical question.


How do i setup continuous integration in a multi team distributed environment without running into issues of broken builds

There should be a CI server accesible by all teams. It's understandable that due to the timezone difference, broken builds may cause issues. When one team breaks the build, the other team might not proceed with that issue. So in order to have a healthy CI environment, some rules should be set.

  1. Never leave the office if a build is in red (i.e. it is broken, some tests are failing)
  2. Everyone is responsible for the commits. So before pushing the commits, the committer should make it perfect by checking if tests are passing, if the commit message is in standards, etc. I advice you (or someone else) to monitor CI builds closely and give immediate feedback if the rules are not obeyed.

How do i plan for the frequently shippable increment Sprint on Sprint basis of all three projects combined

I collected my opinions as listed below.

  1. Product owner should be capable of managing the product and the PBIs.
  2. You can create builds for deploying products of the 3 projects by checking the dependencies. We have such kind of builds and these should be designed with the help of the teams working on those projects.

Any other things i need to watch for or take care of for setting up sucha na environment. My idea is to make it first time right from process standpoint (at least most of the process)

I think continuous integration, continuous builds, 10-min build rule, continuous deployment, emergent architecture, test driven development, multiple enterprise environments (like uat, test/qa, prod environments) are the key concepts you should dig into. The topic is quite wide, but it is achievable if you consider all these topics. There exists very satisfying information in internet about these concepts.

I hope that helps.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.