4squareviews

In the last post, I discussed how the retrospective in an agile environment has effected the “lessons learned” process in a traditional project management environment.

In this post, taken from section 5.2.1 of the Agile Practice Guide, I will discuss the characteristics of the retrospective in agile.

It’s interesting that of the 8 practices that the Agile Practice Guide discusses in section 5.2, they say the single most important practice is the retrospective.   Why?  Because it allows the project to adapt its process in the face of changing circumstances.   This is why I have heard it said that traditional project management copes with change, whereas agile project management uses change to transform the process.   And part of that transformation process is the retrospective.

Many teams uses 2 or 4-week iterations for the “sprint”, or timeboxed iteration, of the project.   The Guide says that the 2-week iteration is the most popular of these two setups.

The team CAN do a retrospective at other times if some sort of significant milestone has been reached, such as the completion of a release or ships a significant portion of the product.   It can also be done if there is some problem which causing the team to be stuck and completed work is not flowing through the team.   The retrospective is then used to gather data and process that data in order to decide what to try as an experiment to get the team un-stuck.

Here are some important points to remember about the retrospective.

1. It is NOT about blame, instead of focusing on WHO, it is focusing on WHAT was done since the last retrospective and finding out what worked and what didn’t, and also where the impediments were.
2. Eventually the analysis of the data about the completed work should lead to root causes, the designing of countermeasures, and developing action plans to remove any impediments discovered.
3. There should be a limit of the number of action items to the team’s capacity to address improvement.
4. With each action item, decide how to measure the outcome to know precisely when it is done.
5. After listing the potential action items, the facilitator should lead the team to ranking them; the highest ranked items up to the limit set in step 3 are the ones that will be focused on.   IF these are all completed before the next iteration, then you can go to the next ones on the list.

The important thing to realize is that the standup meetings are for recognizing problems, and the retrospective meetings are there for solving them.

According to the Agile Practice Guide, it is possible for a team to have a standup meeting to recognize problems, and then to follow it up right after the standup by a retrospective meeting that will work on solving those problems.   But the important takeaway here is that they are separate meetings with their own flow and dynamics.

I would like to put in a brief word about personal retrospectives, that is, the importance in organizing systems like the Full-Focus Planner by Michael Hyatt of doing something like a personal retrospective on a regular basis in order to increase your own productivity and to decrease your frustration when you become “stuck.”  That will be the subject of my next post.

Filed under: Uncategorized |