Feb

28

Agile Concept of the Week: Retrospective

Posted by Keith McMillan

February 28, 2013 | 1 Comment

This week, we’re going to take a look at retrospectives. The principles behind the manifesto include “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behavior accordingly”. The most common way this is done is the retrospective.

In “traditional” project management, we have the “project post-mortem” or “lessons learned”. The big weakness of these activities is they come too late. They’re not helpful to the team that’s actually working on the project, because they typically occur at the end of the project. They’re also not helpful to the next team, for a variety of reasons: the next team isn’t doing the same project; they don’t have the same team members; they have different obstacles to face than this team.  While the idea of learning and adjusting your behavior is a great one, it makes much more sense if we do it throughout the project, when this team and this project can take advantage of the lessons. That’s where the motivation for the retrospective comes from.

Just to level-set, most teams have a retrospective after every sprint. They typically review the goals they set out to achieve for the sprint, and whether they met their goals. While there are probably as many ways to have a retrospective as there are teams, they all hopefully address what the team would like to do to be more effective.

When I coach teams through retrospectives, I frequently use the common “do more”, “do less” and “keep doing” categories for provoking thoughts about what we could do to be more efficient. There are some common things I try to get teams to think about. I encourage them to think about activities they are doing that add little value to their work, such as documenting changes to the design of software. Even if a team is performing some activity and must continue to do so, I encourage them to think about whether what they are doing is the most efficient thing both for them, and for whoever consumes the product of their activity. Continuing the thought of updating a formal design document, are the updates taking the form that’s easiest for the team to do, and most easily used by whoever is reviewing that design.

One common problem I notice with teams is that they’re unwilling to challenge what they perceive as organizational requirements outside of their control, and that’s where executive sponsorship of an agile transformation is invaluable. If “we’ve always produced a detailed design specification” even though nobody really uses it, having an executive on your side to say “we’re not doing it any more” helps tremendously.

Another problem is when the team feels they’ve optimized their behavior, and doesn’t think they need to change any more. “We’re doing pretty darn good!” they say, and it’s very difficult to get them to adopt additional changes to the way they work. This one is much harder to deal with, but having competition between teams seems to help drive innovation and optimization.

Some teams have difficulty coming up with something they’d like to try, and in that case, I’ve used additional categories beyond “do more/do less” such as “interesting” and “frustrating” to help talk about what could make a difference to the team.

Some teams retrospectives unfortunately devolve into complaining about what other teams should do, or complaining about things that are one-time occurrences, such as David being sick for most of the sprint. These teams need to be carefully steered back to “what are we going to do differently going forward to make this better.” Clearly, things that can’t be foreseen we can’t change our behavior to avoid.

Retrospectives are a valuable tool to help a team identify ways to achieve the dramatic performance improvements possible with agile, but only if they’re focused on what the team can do differently, and if the team has the support to make the changes they identify.


Comments

RSS feed | Trackback URI

1 Comment »

Comment by Fareed Quraishi
2013-08-29 08:35:35

How has no one commented on this yet!!
This is an amazing article on how retrospectives work and can be improved. Thank you very much for your insights.

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll