An Experience of Review Meeting: Teams' Observations on Teams
I am a part of a project that consist of 4 scrum teams. We aim to support continuous learning, the continuity of the information flow within the project and make the review meetings of the teams converge (in other words; we aim for teams to observe each other's experiences while exploring their "best".). In order to do that, we initiated the trial of developers in scrum teams to attend review meetings of other teams. These teams have been working together for an average of 1 year. We found that the participation of the audience from different teams to the review meetings caused stress on the teams and they spent extra time for review. We also do not want people to see it as a race, although there is no comparison between teams.
I am curious about your thoughts on this experience. Do you find it appropriate to invite a listener to review ? How are the reactions of the teams when you invite participants outside the stakeholder to the review? Would it be appropriate to attend the audience only in meetings that the product owner has approved by agreeing the development team?
Do you find it appropriate to invite a listener to review ?
From what you say, that isn't what happened. Teams did not *invite* listeners to their review. They were told that others would be there. I'd suggest that might be part of the problem, and a contributory factor to the feeling of stress you have identified.
Would it be appropriate to attend the audience only in meetings that the product owner has approved by agreeing the development team
Getting the team's agreement first would be a good idea.
I am fully with Ian on this one (as usual). If you want teams to learn, provide a safe, open, transparent en trusting environment to do so. Do not direct and organize on their behalf, but let them explore and organize themselves.
I csn totally understand their response, and I would have the same.
Why not ask them what they think will work? make clear the goal (the what) "continuous learning" and let them deside HOW
I also agree with Ian, I'd also want to know why the 4 teams are holding their own reviews.
If the 4 teams are indeed working on a single product, then it may be a good idea to take some lessons from scaling frameworks such as Nexus and LeSS. Both of these models call for a single Sprint Review across all of the teams contributing to a single product. The review should focus on the integrated Increment.
If the 4 teams are not working on a single product and the teams are not stakeholders in each others work, I'd question the value of inviting non-stakeholders to the Sprint Review. It seems like the teams don't like this approach, either. I don't see any reason to continue with this experiment.