14

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?

Roland Tiefenbrunner
  • 253
  • 1
  • 5
Tamas
  • 141
  • 1
  • 3

7 Answers7

12

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.

Péter Török
  • 1,305
  • 7
  • 11
  • 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. – Joel Bancroft-Connors Sep 10 '14 at 20:17
4

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.

Placeholder
  • 451
  • 1
  • 3
  • 8
  • 3
    "A big stand-up with all of the members are too long." was part of the OP. – Péter Török Sep 08 '14 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. – Placeholder Sep 08 '14 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. – Péter Török Sep 08 '14 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 :-( – Péter Török Sep 08 '14 at 14:41
  • @Peter, sorry for not giving you much details, since I write those posts randomly at work. Currently I'm managing a team of 9 people and meetings are essential. When people are forced to talk about themselves in front of the other people they get a sense of responsibility and also they hear what the others have done. This gives you two things: How good you are compared to the others and you learn the progress of the entire project, so you actually know why it is important for you to finish this task today (because the QA team is waiting for you to finish that functionality so they can test it) – Placeholder Sep 08 '14 at 15:04
  • @Peter: I have tried avoiding such "big meetings" in order to "not bore" the developers and "waste their time" (since a meeting with 9 developers and 2-3 managers takes at least 20-60minutes). The result from avoiding those was people getting even more disconnected from each other and miscommunication rose. To put it simple: Force people to meet and talk to each other at any cost. Most developers (or workers in general) don't like that because they are either too shy or busy, but it is your responsibility to make sure those meetings happen. Hope I have helped. – Placeholder Sep 08 '14 at 15:06
  • 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. – Péter Török Sep 09 '14 at 08:22
  • I agree with Gangsta IRL - having everyone in a single meeting is very beneficial. If the meetings are taking too long, it's more a matter of making them "to the point". The knowledge that is shared in such meetings, in my experience, bring outstanding results. From time to time a developer who is working on project A will listen to a problem raised by someone in project B and will suggest a solution that will save multiple hours of work and frustration. In my team we also do monthly "Knowledge sharing" meetings where we discuss longer, selected, topics. – Joao Silva Jan 17 '17 at 07:48
3

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.

calejero
  • 141
  • 4
2

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.

Adrien
  • 251
  • 1
  • 4
1

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.

ShannOliver
  • 11
  • 1
0

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.

mehtak
  • 71
  • 2
0

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.

user2538865
  • 1
  • 1