4squareviews

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

The previous posts have covered the “Initiate”, “Plan”, “Iterate”, and “Control” process group of an agile project.   Now I am focusing on the “Close” process group.   I first want to define what I mean by that term of “process group”.   Why do I use this instead of the word “phase”?    Phase implies a sequence that goes more or less from one set of processes to another.   In reality, after the initiate and plan process groups, an agile project actually shuttles back and forth between the “iterate” and “control” process groups.   However, a project always ends with the “Close” process group, but the “close” control group also refers to those activities which are done at the close of an iteration and not just of the product itself–such as the process 6.10 Retrospectives which is covered in this blog post.

Today’s post is the second of several that cover 6.10 Retrospectives.   The last post covers the general features of retrospective meetings.    This post covers the best practices that are recommended for Retrospective meetings:

Here’s how the time should be used in a retrospective meeting, with the amount of time in percentage put in parentheses, followed by some best practices.

1. Set the stage (5%)

• Describe the goal of the retrospective
• Ask every team member to speak and be an active contributor
• Outline the process that will be used
• Establish an environment of personal safety so difficult topics and challenging conversations can occur
• Post and view and team working agreements, then suggest any adjustments needed during the retrospective

2. Gather data (30-50%)

• Create a shared picture of what happened during the iteration
• Give data about the features and stories developed during the duration, and add metrics
• Review decisions that were made during the iteration
• Encourage the team to refer to calendars and artifacts
• Create a visual depiction where patterns and connections can be recognized
• All of the above refer to the quantitative–add the qualitative, feeling part of the story
• Create a structured, comfortable way for the team to talk about feelings and topics that carry an emotional charge

3. Generate insights (20-30%)

• Have the team examine what conditions and interactions helped and which of them inhibited the success of the iteration
• Identify breakdowns, constraints, missing information, risks and unexpected outcomes
• Dig deeper to find possible causes and effects
• Analyze what changes could help the work flow more effectively

4. Decide what to do (15-20%)

• Based on the insights generated in the last portion of the meeting, create a list of potential changes the team can make and then pick one or two that the team can implement during the next iteration
• Make a plan with enough structure to guide the team’s actions–choose to test changes proposed in the last step to see if they produce a positive effect at the end of the next iteration
• Create stories and put them in the backlog to make it easier to integrate the changes suggested above into the work of the next iteration

5.  Close the retrospective (10%)

• Since the above steps 3 and 4 are intellectually and perhaps emotionally exhausting, it is important to close the retrospective on a positive and decisive note.
• Make sure the team makes the new practices developed in step 4 visible with posters or on a wiki page, including any tracking data showing progress against the metrics.
• Encourage, acknowledge and applaud the effort and risk taking of the team–not the results!

6.  Shuffle time (10-15%)

• This is the time is takes to shift between activities or topics during retrospective meetings–don’t overlook accounting for this in the schedule

These are general descriptions for the flow of a retrospective meeting.   There are specific exercises that have been tried by agile teams, and I will discuss these in the following posts.  For more complete information and tips on how to run a retrospective, I suggest you check out John Stenbeck’s book, “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”!

Filed under: Uncategorized |