There is a post on InfoQ about insuring the changes proposed during retrospectives are followed through. This triggered a comment from me that focuses on the need for accountability in retrospectives.
Retrospectives are for the team to improve. The team should collectively own the meeting and not look at the scrum master or other leader to own the retrospective just because they are the facilitator. This is part of the self-empowered, self-managed team mantra.
When ideas come up in the retrospective, this same attitude should apply. Ideas aren't to be pitched over the wall for "somebody" to solve. The point of a retrospective is to uncover and improve. The team is doing something that can be improved, and unfortunately (Mr. Teammember) this means you have to be part of the solution.
Below is the comment I placed on the thread at InfoQ:
A by-product of working agile in a FDA regulated company was addressing this issue with documentation and therefore leading to a solution to this problem.
In retrospectives I ran then and still run today, each idea/topic is given an owner by the end of the conversation. Normally this is someone who volunteers, but sometimes we have to assign the closest person. The only time this wasn't true was if everyone agreed to do something, then the group was the owner.
In the next retrospective, we quickly review the prior retrospective topic list and review the outcomes. (Did we do it? Is it working?) If items are considered closed, we remove them. Sometimes items flow another iteration cycle or cause new conversations. The point is that there was an owner that should have run with it for the good of the team.
I call it the accountability cycle.
No comments:
Post a Comment