InfoQ

News

Frequent Retrospectives Accelerate Learning and Improvement

Posted by Deborah Hartmann on Jun 04, 2007 11:10 AM

Community
Agile
Topics
Leadership ,
Teamwork ,
Agile Techniques
Tags
Management ,
Retrospectives ,
Continuous Improvement
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.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

5 comments

Reply

Post mortem or post partem? by Dean Schulze Posted Jun 4, 2007 12:20 PM
Re: Post mortem or post partem? by Chris Rimmer Posted Jun 4, 2007 3:18 PM
Re: Post mortem or post partem? by Michał Kłujszo Posted Jun 4, 2007 3:47 PM
Re: Post mortem or post partem? by Deborah Hartmann Posted Jun 4, 2007 7:25 PM
Re: positive post partem? by Indyana Jones Posted Jun 5, 2007 7:00 AM
  1. Back to top

    Post mortem or post partem?

    Jun 4, 2007 12:20 PM 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.

  2. Back to top

    Re: Post mortem or post partem?

    Jun 4, 2007 3:18 PM 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...

  3. Back to top

    Re: Post mortem or post partem?

    Jun 4, 2007 3:47 PM 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...

  4. Back to top

    Re: Post mortem or post partem?

    Jun 4, 2007 7:25 PM by Deborah Hartmann

    Great idea! :-D

  5. Back to top

    Re: positive post partem?

    Jun 5, 2007 7:00 AM 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....

Exclusive Content

Dan Farino About MySpace’s Architecture

Dan Farino talks about the system architecture and the challenges faced when building a very large online community. Dan explains how a .NET product scales on hundreds of servers.

The Maxine VM

Bernd Mathiske discusses Maxine VM, Java compatibility, swapping major VM components, research areas, Object handling, code examples, optimizing compiler, snippets, bytecode generation, JNI and JIT.

Joe Armstrong About Erlang

Joe Armstrong speaks on various aspects of the Erlang language, presenting its roots, how it compares with other languages and why it has become popular these days.

The Limits of Code Optimization: a new Singleton Pattern Implementation

The java double-check singleton pattern is not thread safe and can’t be fixed. In this article, Dr. Alexey Yakubovich provides an implementation of the Singleton pattern that he claims is thread-safe.

Pressure and Performance – The CTO's Dilemma

Diana and Jim talk about patterns observed in CTOs' activity. CTOs emerge as real people caring for other people in their organization, and are put under a lot of pressure and constraints.

Biztalk Services in the Cloud

Cloud computing feels like a tomorrow technology. Simon Thurman shows how developers can use Biztalk to create an Internet Service Bus which can be deployed locally or in the cloud.

Java FX Technology Preview

InfoQ takes a look at the JavaFX preview build and talks to Sun Staff Engineer Joshua Marinacci about the upcoming version 1 release expected this autumn.

Jeff Sutherland: Reaching Hyper-Productivity with Outsourced Development Teams

Jeff Sutherland, co-creator of Scrum, and Guido Schoonheim, CTO of Xebia, present an actual case of reaching hyper-productivity with a large distributed team using XP and Scrum.