Geeks With Blogs
Aaron Feng Agile Software Development (XP), Test Driven Development, .NET, etc.....

Retrospectives are a way for a software development teams to discuss and figure out ways to resolve issues when an increment of work is done.  The strength of the retrospective comes from focusing on the team members and how to improve as a team.  For the team I am working on, the increment of work just so happens to be one week.  Our retrospective definitely helped us fine tune our team on the iteration basis.  At times, I feel like our retrospective has become routine and rushed because the sooner we can finish, the sooner we can start coding since we are on a short iteration.  I decided to check out Retrospective by Esther Derby and Diana Larsen to see if there is anything we can do to revitalize our retrospective.  Overall, I found the book to be really helpful and easy to read and understand.  The book encourages very structured and well planned out retrospectives, which I feel is our weak point.  The book suggested five phases listed below:

1.  Set the stage
2.  Gather data
3.  Generate insights
4.  Decide what to do
5.  Close the retrospective

Set the stage phase: Basically an ice breaker that the retrospective leader will facilitate in an environment that allows the team members to focus and participate on the retrospective.  According to the book, this is one of the most import phases of the retrospective, and many teams usually skip it.  As you can guess, we also skipped this phase with our past retrospectives as well.  In order to have a successful retrospective, all team members need to participate early, otherwise people are less likely to say anything in the later phase.

Gather data phase: This s a great way to put everyone on the same page before getting to the meat of the retrospective even if you are on a short iteration.  It is much easier to determine shifts and patterns by looking at hard data.  On our team, most of the time we do not have hard data, so at times we rely on team members’ subjective feelings as to how things went.  This can be problematic because it is hard to have a constructive discussion when people have different views on what went on.

Once the team starts to see some patterns and shifts, it is now time to move into generating insights by looking at the big picture and figuring out root causes.  We tend to have pretty good discussions in this phase, but it usually went on longer than needed because we do not have hard data to help us. 

Deciding what to do is the meat of the retrospective.  This stage is pretty self explanatory, but the important point here is whatever the team decides to do, the team must commit to it. 

Closing the retrospective is very helpful for the team to fine tune the next retrospective.  Like anything else, it needs to be tuned every once in a while, so do the retrospectives.

The description I provided above is by no means comprehensive.  If you feel your retrospective is not as effective any more, this book is for you.  The book provides many activities for each phase of the retrospective, so you do not have to stick with the same old activity over and over again.  We followed the format of the book, and ran two retrospectives with a great deal of positive feedback from the team members.

Posted on Sunday, August 27, 2006 12:37 PM Agile | Back to top

Comments on this post: Agile Retrospectives

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Aaron Feng | Powered by: