InfoQ

News

Frequent Retrospectives Accelerate Learning and Improvement

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

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

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.