Sprint Retrospective - what attendees are right and who should see the outputs of it?
I'm wondering about sprint retrospective in terms of who can attend the meetings and whose not?
The second questions is about output of it. Who can/should see it and whose not?
I understand that retrospective is for Scrum Team and the purpose of it is to inspect and plan improvements.
From this point I would say that retrospective is for the team and no one else. So there shouldn't be any other participants and also output from the meeting does not have to be sent/distributed to anywhere else.
On the other hand the scrum highlights transparency. So why any other people cannot attend on retrospective and see the summary of it?
Why I'm asking. In my company sprint retrospective is sent to Line Management and also Program Management plus QA responsible person would like to see the outputs. Also the last two (or one) would like to attend retrospective meetings.
I'm afraid that the retrospective may start to be painting grass to green instead of open meeting also with construct criticism. This also in my opinion is lowering the feeling of responsibility for things within the team.
From my perspective retrospective and it outcomes are for the team. This shouldn’t be by default sent to anyone outside of the team and also if anyone form outside of the team would like to attend retrospective, he can if the team agrees.
Of course it does not mean that Line Manager, Program Manager of someone form QA cannot come to the team and ask about team spirit, way of work etc.
What do you think? What is the right path accordingly to the scrum?
If the Scrum Team is not alone in the retrospective, it won't dig freely into the actual problems.
I have let a manager be in a retrospective once, and the retrospective was very poor. Really a "ScrumBut" to me.
But the output of the retro should be some actionnable improvements, like some "special" tasks on the board or a more stringent DOD and this is highly transparent and visible to everyone.
A Sprint Retrospective is an inspect-and-adapt opportunity for the Scrum Team. It isn't appropriate for others to participate in a Retrospective given that they do not participate in the team's process.
There's nothing in Scrum that says observers can't attend a Retrospective, but if it impacts the team's ability to inspect matters thoroughly then they would be required to conduct the session in isolation. Transparency is not an issue given that all three Scrum roles are expected to participate in each Retrospective.
ok Ian, I got your point. But what about an outcome of retrospective. Should it bi sent/visible to anyone outside of the team?
> But the output of the retro should be some actionnable improvements, like some
> "special" tasks on the board or a more stringent DOD and this is highly transparent
> and visible to everyone.
The output of the retro should be *actual* improvements that are highly transparent and visible to everyone. That's different to whatever special tasks may go on the board or a more stringent DoD agreed by the team. There can be reasons for keeping such artifacts private, and for restricting the transparency that is afforded to other stakeholders to the actuals.
For example, I once coached an InfoSec scrum team who did not have a board that was visible to others at all...it had to be locked in a special room. Transparency of process including retrospectives was limited to the team itself. Other stakeholders got to see improvements as they occurred on a sprint-by-sprint basis, including sanitized metrics.
> But what about an outcome of retrospective. Should it bi sent/visible to anyone outside of the team?
In Scrum the outcome should be actual improvements to the process, not promissory notes about how things are going to change. Any minutes, new tasks, action items, or associated notes - if needed at all - are the property of the Scrum Team. These artifacts can be transmitted further at the team's discretion but they certainly don't have to be.
Its ounds to me like your management team want to manage everything and see every little output, which defeats the purpose of Agile.
Yes, this is exactly what I was think and afraid of.
I act as a Scrum Master. I treat a retro as internal team meeting. I would afraid that any participated external leads to make the meeting artificial, hence it would be waste of time. I've never shared any internal upshot outside the team, till I believe the team can deal with. But when we identify problems during retro that can't be handled by the team, I always send an email to managers, especially when I need their help.
Moreover I put on our webpage such information with an assignee, status and arrival date. So my whole organization can follow how the managers proceed with the issue. Believe me, works fantastic. :->
I suppose that your managers ask you for the summary of the retro to help you, if needed. Treat it as benefit.
I would agree with your point Bartek. About the help... Here you can look at it on two ways... I'm afraid of that old waterfall approach is here something what is applied... Control everything from the top and don't give responsibility to the team...
Of course that escalating something what cannot be deal with inside the team is something natural, but no other way round.
I do Sprint Retrospective is with the team. What team would like to stop, start, continue doing and improve. If the list of improvement is big, then identify what top two items team would like to improve / start doing in next sprint.
We can publish outcome of sprint retrospective for the visibility. We need to set the right expectation with the managers where we need help, then it becomes their accountability to provide necessary help in order to remove impediments.
Attendees : Team, Visibility : Everyone, Action : Team, Management