Agile Retrospectives (II): Phases

Tuesday, August 10, 2010 4 Comments

In the last article I talked about general concepts related to retrospective meetings and several issues to take into account when planning a meeting.
This time I'll describe the different phases of a retrospective in detail. As all of you already know, these phases are:
  1. Set the stage.
  2. Gather data.
  3. Generate insights.
  4. Decide what to do.
  5. Close the retrospective.
Set the stage

Introduce the meeting; try to make that everyone gives his/her opinion, how he or she feels about the last sprint (or iteration in general terms, remember that I'll focus mainly on SCRUM). Be brief, but the most important thing here is to make that every member of the team says something. The best way to achieve this is asking how everyone feels about the last sprint, and what they want for the next one.

Establish the duration of the meeting and the different points to discuss. In addition to this, describe a list of objectives or rules that identify the team and that must be accomplished during the meeting. Example: "Every one must participate".

Gather data

Not only gather data, but also share it with the team. This information improves the perspective that every member has about the context, making that the team talk about their general impressions instead of their personal insights. It is essential that every member shares his/her
feelings about the last sprint. Don't ask directly about feelings, but indirectly, such as: when did you come to work happier? which task did you enjoy more? when did you come to work simply because you had to? which task did you find boring/less interesting?

Generate insights

This is the appropriate moment to think about 'why?' and to decide what should be done in a different way. Make that the team think about conditions, interactions and patterns that may lead to success. Identify and study problems, risks and bad results.

Decide what to do

Select two improvement points (no more) for the next sprint, and plan to do them. Too many points of improvement tends to overload the team, it creates stress and in the end it is probable that none of them are achieved.

Plan a break between the retrospective and the plan meeting, so that the people think about what and how to plan taking into account the decisions made in the retrospective meeting.

Close the retrospective

Close the meeting properly and decisively. Summarize the conclusions. Write all the issues covered during the meeting in a blackboard, so that everyone can see them. Include the improvement points to do and the decisions made. It is very important to remark that those decisions adopted are property of the team, not of the manager. Thus we'll avoid that when everyone leaves the meeting room they forget everything until the next meeting.

Upcoming...

Activities to do during the retrospective meeting, which aim is to make that every person participates in the meeting, promoting insights, fresh ideas and points of improvement. See you, then.



Bibliography:

Agile Retrospectives: making good teams great

Esther Derby & Diana Larsen

Agile Retrospectives: how to improve the meetings and the results
(Part I of the series)

4 comments:

  1. I am curious where one leaves feature requests? Specifically, with the new support for explorer extensions in SCM 3, will support be included for non-case sensitive recognition of file extensions for determining binary / text format?

    ReplyDelete
  2. Hi anonymous! :)

    You sure you commented on the right post? :)

    File extension recognition is already case insensitive on windows and there's always a filetypes.conf file that let you customize the types prior adding them.

    ReplyDelete
  3. Haha! But where else to post?

    Are you sure filetypes.conf is actually case insensitive for detection of file type? I quote David here:

    "I'm afraid the filetypes.conf syntax is case sensitive since we support platforms other than Windows and the system needs to be aware of that."

    ReplyDelete
  4. You can always use the forum too. :)

    Well, yes, you're right, filetypes.conf is sensitive, but the builtin detection is not.

    ReplyDelete