Collaborating on a single mobile project with three teams



Recently at BAM, we started a new project so ambitious that three teams were collaborating. Here is what we learnt and how we adapt our methodology and organisation for such projects.

Adapting scrum framework in order to share more information

In the Scrum methodology, Daily Meetings are the appointments during which everyone in a team syncs up with its teammates on four different subjects: sprint success, planning, issues and technical changes. Thus, the maximum period of desynchronisation for a member of a team with its teammates is one day.

With three different teams, we need a time for everyone to sync up with every one else from the other teams. We decided that the maximum period of desynchronisation for a member of a team with the other teams members is one week. To sync up on the four main subjects which are sprint success, planning, issues and technical changes, we organised four new weekly Scrum events.

The following events can replace or can be added to existing ones depending on the availability of the Product Owner and the stakeholders. On the project I am writing about, we replaced all reviews and retrospectives by the following Global review and Global retrospective. But from time to time, we held a one team retrospective.

Sprint success sync: Global review

The global review aims to present each team work and advancement on the project's roadmap.

  • It starts with a demo of each team recently added features (~8min/team).
  • Then each team spends ~8 minutes presenting upcoming features.
  • The Product Owner validates the sprint goal of each team.

Planning sync: Global sprint planning

Each team plans the next week on the same day. After all of them have finished (it could be just after, or the day after), a global sprint planning with one member of each team is organised. Then, each member present to the others which reusable feature its team is going to develop the next week. From time to time, two teams need to develop the same feature. In that case, the team who needs the feature first commit to deliver the feature for a certain date. The other team delays every dependant features after this date.

We identified two kind of feature that need to be shared to everyone during global sprint plannings:

  • UI components: it can be button or a more complex component such as forms' inputs.
  • UI assets such as fonts and icons: in that case, one member of one team is responsible to integrate all needed assets in one shot. Doing so, we reduce the integration time of all assets needed for the coming week.

Issues sync: Global retrospective

In order to share issues, a global retrospective allows anyone to pitch what he thinks are the most important issues on the project. We timeboxed this event to 1 hour. In order to keep the timing right for everyone to speak out and help one another, we used Retrium.

Technical changes sync: Technical dojos

A Dojo's objective is to go faster and share knowledge by repeating actions. Thus, technical dojos are perfect to show everyone the best coding practices or to present technical changes to all team members.

Between two technical dojos, any improvement made by a team on a technical subject (it could be either a way to do something faster, or a refacto, or an operation mode) is added to the agenda of the next dojo with the estimation of the time needed to explain the subject.



At the end of the day, each member attends to:

  • daily meetings,
  • a weekly backlog refinement,
  • a weekly technical refinement...

... and in addition to those classic events, ...

  • a weekly global review,
  • a weekly global retrospective,
  • a weekly global sprint planning,
  • a weekly technical dojo.