Looking back often, then you look further.
The postpone of review meeting endangered the retrospective again which made me very nervous.
However no matter what happens, I insist on having retrospective. Maybe for the team it’s just a meeting, but as for Agile process, it’s one of the most important check points.
Let’s first have a bit view on what we do in retro. The common retrospective meeting agenda is as following:
- review the result of the action point which was taken out from last iteration. Asking questions: how does it work? if the answer is positive, then we will continue; if not, then we will stop it;
- find out what’s next urgent point needed to be improved. There are many Agile retro games to facilitate this step. I only suggest using vote to decide the “to be improved candidate”.
- divide team into different groups to brainstorm feasible ideas and actions to the “to be improved” point. One remark is that the action must be concrete and detailed enough so it can be done immediately after the meeting. From my personal experience, filling the action into 4W1H(What? How? When? Where? Who?) question format will make it better to executed. For example,
- What? to add test cases example to one user story and then show to the team
- How? use TFS “test cases” functional to add test cases and link them the user story…
- When? Friday
- Where? at Li’s place
- Who? Li and Joey
After retro has finished, the ScM should make sure the action is well followed up and ask for feedback from team on this action in the next coming retrospective.
In the daily work or life, we need some changes to improve ourselves, then we work out some actions. But how do we guarantee the improvement will be finally achieved or not? Retrospective is such a ritual to keep you reviewing on those actions regularly, on one hand to pick out the meaningful-less changes, on the other hand to solid the positive changes we’ve made and then move on.