Frequent Retrospectives Accelerate Learning and Improvement

Posted by Deborah Hartmann Preuss on Jun 04, 2007

Sections

Process & Practices

Topics

Agile ,

Leadership ,

Teamwork ,

Agile Techniques

Tags

Continuous Improvement ,

Management ,

Retrospectives

Retrospectives are a tool that a team can use for positive change to shift from following a process to driving their own process, becoming self-managed. In this article, Rachel Davies, a founding member of the UK's XP community, offers help for teams who have ideas for improvements but aren't sure how to get them off the ground. This article covers the steps required to run a retrospective and implement its results.

Some teams already run formal or informal "post mortem" meetings at the end of each project, but for Agile teams this is too long an interval. Retrospectives must be frequent to remain adaptable to change. This improves team communication and increases their rate of learning. Agile teams want to learn during the project, not after, to improve their chances of success.

But do teams need formal instruction? How hard can it be to run a retrospective?

Expecting magic to happen just by virtue of bringing the team together in a room to discuss recent events is unrealistic. Like any productive meeting, a retrospective needs a clear agenda and a facilitator to keep the meeting running smoothly. Without these in place, conversations are likely to be full of criticism and attributing blame. Simply getting people into a room to vent their frustrations is unlikely to resolve any problems and may even exacerbate them.

Davies proposes that thoughtful facilitation can help teams fearlessly talk about past experiences without resorting to blame. Strategies include setting ground rules, using the "retrospective prime directive" and allowing team members to attend voluntarily.

One common complaint heard about retrospectives is "It's a waste of time, we never implement what we learn!" In fact, looking back is only half of the retrospective pattern. Reflection is not learning. To bring about learning and improvement, it is necessary to identify areas for improve and explicitly document a brief action plan for which the team becomes accountable. When a team is doing this regularly, it may seem that retrospectives are not needed because they never encounter dramatic crises. But Davies reminds us:

The power of regular retrospectives and regular exercise is that they prevent big problems from happening so there should be no war stories or miraculous transformations! Embracing retrospectives helps a team find tune their process at a sustainable pace.

Read the InfoQ article: How To: Live and Learn with Retrospectives by Rachel Davies.

Related news: click on the Retrospectives tag below to see all news and content on InfoQ about this topic.

1. Back to top

   Post mortem or post partem?

   by Dean Schulze

   My (nurse) wife pointed out to me that a retrospective at the conclusion of a successful project should really be called a post partem because there was a birth, not a death. (And usually everyone feels like they've got the baby blues from the end of project stress.)
   
   It's also a more positive term. Post mortem is pretty morbid sounding.

   Reply

2. Back to top

   Re: Post mortem or post partem?

   by Chris Rimmer

   I think part of the point is that having these exercises *only* at the end of a project is a bad thing. So from an agile perspective the analogy is not a bad one. By the time you get to a 'post-mortem' it is too late to make the necessary changes needed to save the project/patient...

   Reply

3. Back to top

   Re: Post mortem or post partem?

   by Michał Kłujszo

   I think that ther is a big difference between a retrospective and post-mortem. We do our retrospective after every 2 week sprint, and they work great, we tuned our development process and had some good success stories...

   Reply

4. Back to top

   Re: Post mortem or post partem?

   by Deborah Hartmann

   Great idea! :-D

   Reply

5. Back to top

   Re: positive post partem?

   by Indyana Jones

   Tell that to Rosemary and her baby :)
   
   Anyway, the trick (at least for me and Michał) is to review you process (and the iteration itself) just after the iteration. And even this way, the post-mortem still applies - after all who wants to miss the traditional blame party, when everyone goes home full of digitals from the finger pointing special moment ?
   Jokes aside, (for me) usually this practice must be introduced in a covert way, to not be perceived as an 'audit' by the team - the first 'sessions' often go great after a (no so) few beers during a happy-hour....

   Reply

• Older >