There are 3 Scrum teams (with ~15 people) whose work is tightly connected so it's necessary that teams to be up to date with the others' progress.

How is it possible to exchange info between teams on a daily basis in an effective manner?

A big stand-up with all of the members are too long. We've tried that each team delegates an "ambassador" who participate on the others' stand-up too but in that case the info flow was not the best.

Do you know a good way to keep updated connected Scrum team about each other?

  • 1
    What was the issues with delegating an ambassador? The Scrum of Scrums is designed to solve this problem, using representatives from each Scrum team. Have you considered looking at the representatives chosen, the meeting format, or other reasons why choosing ambassadors and holding a Scrum of Scrums didn't work?
    – Thomas Owens
    Commented Sep 8, 2014 at 12:37
  • 1
    @ThomasOwens, what the OP described is actually not Scrum of Scrums. Commented Sep 8, 2014 at 12:54
  • Have you looked at having an internal, twitter-like status system? Commented Sep 8, 2014 at 17:26
  • Is that ~15 people total in the 3 Scrum teams? Commented Sep 8, 2014 at 19:22
  • 1
    15 people: 105 communication channels. 45 people: 990 communications channels. Scrum teams should be kept to around 7 people, plus or minus 2, for an average of only 22 communications channels.
    – Todd A. Jacobs
    Commented Sep 10, 2014 at 16:56

7 Answers 7


As Thomas Owens noted, one of the solutions to scaling up Scrum is the Scrum of Scrums. What you describe in the OP, however, is different:

We've tried that each team delegates an "ambassador" who participate on the others' stand-up too but in that case the info flow was not the best.

Instead of each team sending an ambassador to other teams' daily Scrum, the Scrum of Scrums is a separate, higher level meeting including usually a single ambassador from each team. It may not necessarily be a daily meeting, often it is best for the team to have it 2-3 times a week. And its focus is somewhat different from that of the team level Scrums. Fairly obviously, it focuses on team level status and blockers. But it is also more oriented towards rapid removal of blockers, so it may not have a strict time limit, and it may (by common agreement) transform into a problem solving session when needed. The participants may - and should - vary, ideally each team could be rotating their ambassadors more or less regularly.

Another approach to help information flow is Communities of Practice.

A community of practice is a like-minded or like-skilled group of individuals who voluntarily come together because of their passion and commitment around a technology, approach, or vision. On a large project, these communities of practice are helpful for cutting across the boundaries of and pulling together individuals from the many crossfunctional teams.

  • 1
    We've used this format effectively in our projects for the last three years. One key learning we developed is the Scrum of Scrum meeting needs minutes taken and sent out. The topics at this level often have broad impact and sending out minutes keeps those who are not in person in the loop. Commented Sep 10, 2014 at 20:17

All of this below is from my own painful experience:

Be in the same room.

Talk to each other while working or at lunch breaks.

Most importantly

Make sure to have a general meeting with everyone gathered (standing or not) where every single person is being asked:

  • What have you done yesterday
  • What are you working on today
  • If there are any problems or he/she needs help

Meeting are a must and if you compromise them the results may be devastating.

  • 3
    "A big stand-up with all of the members are too long." was part of the OP. Commented Sep 8, 2014 at 12:53
  • 1
    Look, I would like to write code without thinking and spend a day without dealing with explaining simple things to clients but it just won't happen. Some things cannot be avoided for good. As a Project Manager you are a leader figure and you are supposed to enforce procedures in order to make sure the project is finished and everyone is paid, instead of pleasing everyone and failing the project. Commented Sep 8, 2014 at 14:09
  • 2
    I am a Scrum master, not a project manager so luckily I am not involved with team members' pay checks :-) I understand this has worked in your team, and that is fine. However that doesn't mean it would automatically be the best solution for all teams on the planet. If the OP feels daily Scrums are too long, rigidly enforcing a process is IMHO not the right answer (espcially not from the Agile perspective). It is part of the definition of Scrum that the recommended Scrum team size is approx. 5-9 persons. Above that soft limit Scrum needs adjustments in order to scale. Commented Sep 8, 2014 at 14:30
  • 1
    Btw I would be interested to actually read some more concrete details about the experiences you refer to above. How big was your team? What problems you encountered and how you solved them? I think all of us here are open to solid arguments and happy to learn from well written answers. Unfortunately, your answer as it currently stands does not give us much to learn :-( Commented Sep 8, 2014 at 14:41
  • 3
    I fully agree that just because team members don't like something, it is not a good reason to not do it if otherwise it provides clear benefits for the team in the long run. However, the team must understand - and eventually experience themselves - why it is required and why it is good for them. So IMHO we should educate them and convince them, rather than forcing them to comply. If they don't see the benefit, can we show or demonstrate it to them? IMHO that's a challenge to the Scrum master / PM, not the team's shortcoming. Commented Sep 9, 2014 at 8:22

Some months ago I have an experience with two teams: Product and Data scientists. In their moment, we change what have you done yesterday for What you get yesterday.

It's a simple change but I think a very important change facing that situation. It's more important explain the goal obtained that the way for doing it.

I agree with the Hellen experience.


Pay attention to information overload. There shouldn't be that many interactions that each one needs to keep up with everyone's status

  • Super-stand-ups have limited interest for members. Their role is to keep the management posted.
  • Get a team chat tool. If someone has a public announcement, he can get it across over the chat. Atlassian's HipChat is especially tailored for teams, for example if someone mentions you in a public room or if you're away, it emails the chat you.
  • Get a team wiki. E.g. in Atlassian Confluence, every time someone updates a page you watch (such as the status on every major change), everyone gets notified.

This way, there is less pressure on the completeness of the daily stand-up and everyone can keep up with information that is relevant to them.

Disclaimer: I used to work at Atlassian and I'm still a fan, so feel free to replace the tools I suggest with competitors.


For this context, I actually highly recommend iDoneThis.

Basically, iDoneThis sends an email to everyone on your team (so in this case, everyone on your 3 Scrum teams) and every person writes a quick reply to the email about what they've done that day (you can have it sent out whenever you want). The next day, iDoneThis sends a digest to the entire team with those replies.

It's fantastic; everyone can see the information, but if something specific needs to be addressed, those people who it applies to can deal with it between themselves. In this way, it doesn't waste others time who aren't involved. Those people can then include an update on the next day's email if needed.

I did find that it wasn't efficient for smaller teams. For example, we used it on my 6-person team and loved the idea, but found that we could just easily have a short daily stand-up in addition to a chat client. But for a large team, I bet this will be invaluable.

I think it is still important to have occasional all-hands team meetings, but for an everyday update, this is perfect.

It's not free but it's only $5/member/month, and worth it in my opinion.

Side note: this is also great to just use as a tool just for yourself (a "work diary", if you will). For this purpose (1 person), it's free. This is how I use it now and love it.


In my opinion, the 3 team can conduct their scrum meeting individually. But the Scrum master being the common factor in all 3 meetings can pass on the info/dependencies from one team to another.


There are two issues to the problem.

  1. Coordinating between multiple teams which can be achieved with scrum of scrums as discussed in some of the answers above.
  2. The other one is the stand up meeting should be kept short and crisp otherwise people lose interest over time. In the case with multiple teams or even a team with reasonably more number of people, stand ups can be effectively facilitated with the help of a tool.

Wizergos is one such software which will help your team to have more engaging short stand ups with following features.

a. It fetches the required data (mostly tasks accomplished and are scheduled for next meeting) for each person and data is visible to all attendees. Only human intervention is required if somebody is blocked on anything.

b. It creates the automated minutes at the end. Each attendee gets notified with the summarised minutes. Also the scrum master gets the list of blocked items.

c. A timer to finish the meeting in time.

With the above features , even a stand up for 15 people will take hardly 15-20 mins.

You can register and start using it for your team for 30 day free trial period.

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.