Cross-tem daily DScrum Representative
Hi,
I'm help to company I work with to move away from having all team mebers of a team in the cross-team daily scrum, which I am working with the teams to send only 1 team representative to the cross-team daily scrum, who then gives a summary back to the team. One team has questioned me what is the use, because the same amount of time would be used by all as the representative will report back to the team.
I think I'll mention to them that, the first reason is to minimize team context switching and because not everything mentioned in a daily scrum is valuable for their team and only a quick summary will be mentioned to their team. Correct? Or am I missing some other important reason please?
Since you do not mention the purpose of the "cross-team daily scrum", it is hard for me to offer any advice. There is no mention of this event in the Scrum Guide however many of the scaling frameworks have similar cross-team activities. Each of those frameworks provide clear definitions of the event purposes. As a Scrum Master, it would be your responsibility to share those definitions and help the teams to understand the significance and purpose. Then let the teams decide how they would best be represented in those events. It is not within your responsibility to decide how the team should participate.
I think I'll mention to them that, the first reason is to minimize team context switching and because not everything mentioned in a daily scrum is valuable for their team and only a quick summary will be mentioned to their team. Correct? Or am I missing some other important reason please?
I explain to people that one should not attempt to determine what is relevant to others. How could one individual know what everyone else needs to know in order to do their work? That is a trait of micromanagement and directly impacts the transparency of information. How do you know that something said in the cross-team event will not be useful to someone on a team? And it may not be relevant on that day but it could become relevant at some point in the future.
I also explain that providing full access to our Product and Sprint Backlogs to everyone is a good thing. That way everyone can be informed about what our team is working on and plans to work on in the future. It eliminates the need for status reporting, which is what a lot of these "cross-team daily scrum" events become. It facilitates the flow of information which can help others to understand potential impacts to themselves and prevent impediments from occurring.
If you can provide more insights into purpose the "cross-team daily scrum", I think you will get some better feedback from the forum participants.
Or am I missing some other important reason please?
The reason for having a Daily Scrum involving multiple teams, or their representatives, is to manage their integration dependencies for the next working day.
Hello, to make long story short, I understand that you are(just like many others) struggling with trying to scale the work of multiple Scrum teams working on a same product backlog. If so, WHATparticular scaling method have you chosen? NEXUS, Scrum of the Scrums, LESS, God forbid SAFe, or something else, may be of your own?
Hello to all and many thanks for all your answers.
I thank Daniel for reminding me that deciding for other people is micromanagement.
Nicholas, the scaling method in use is Scrum of Scrums.
I think Ian's answer helps the most, so far, and will emphasize this point.
The intended purpose of the cross-team daily scrum meeting, is for teams to help other team to complete their tickets, especially on tickets blocking other team work.
Having said this, teams prioritising work to help other team close off blocked tickets seems to be less important that the team closing stories related to their sprint goal, even though product first mentions the global sprint product goal and how team sprint goals will help to acheive this, and I'll start emphasizing "is to manage their integration dependencies for the next working day.".
Hope I'm not on a micro-management mindset :s