(Or Avoiding The Blame Game)
A Brief Introduction
Do Reflect Repeat
A positive feedback loop lies at the heart of the iterative methods popularized by the agile movement. Millions of words must have been expended on the do. Effective reflection is equally essential but often seems to be neglected. Retrospectives are a tool for reflection advocated by agilists, helping teams to build and bond, and to continuously improve their technique.
Do, Reflect, Repeat
A Longer Introduction
The Blame Game
Teams bond and learn by doing together. If the only time that a team reflects together happens after things have gone so wrong that something must be done, then the team is likely to lack the collective experience required to succeed under pressure with this review. So reflect regularly and work hard to continuously improve.
Are All Retrospectives Agile?
When failure is both likely and costly, individuals start to think about themselves first and the team last. Post-mortems (and related forms) applied after failure risk reduction of team morale and reinforcement of failure, substituting blame for reflection. Retrospectives (by contrast) are concerned with positive collective reflective, not negative individual blame. If you must play the blame game, use different tools (for example, semi-structured interviews with individuals).
Developers Have Feelings Too
Retrospectives verses Reviews
An emphasis on the emotional is a distinctive aspect of retrospectives, and sets them apart from more conventional review methods. Given popular beliefs surrounding technologists, encouraging them to talk about feelings might seem - at first - an unintuitive tactic but it's time to stop reinforcing these stereotypes by acknowledging that developers have feelings too.
Making Good Teams Great!
Modern tools popular with agile developers present plentiful information about what happened: version control systems track (in a finely grained and irrefutable manner) individual contributions to the collective work; build plugins exercise and assess the code; continuous integration servers collect, collate and correlate these metrics; every issue pulled from a task tracker creates a record. By contrast, review meetings seem a wasteful substitute.
San Francisco Agile User Group
Agile techniques specify the process side of why: stories recorded in the language of the customer domain are translated to statements in course grain controlled vocabularies; harnesses bind and automate empirical validation of these statements; finely grained tests close to the code in the language of development discover regression.
Use The Language Of The Customer
Agile tools and techniques reduce waste by automatically creating a quantitative record of the iterative. This allows more time to be devoted to reflecting on the qualitative, human aspects. So agile approaches are a better match for reflective tools which play well with the emotional side - such as retrospectives - than more conventional reviews.
All this adds up to an increased emphasis on maintaining and continuously improving the health of the team.
Form Follows Substance
Bringing Structure To A Retrospective
Collective ownership is critical for successful agile retrospectives. Retrospectives should be by the team, for the team, and so should be structured by facilitation (and never directly managed). Always appoint a facilitator early, allowing plenty of preparation time. Teams with retrospective experience often find that rotating the facilitation role helps to build confidence and knowledge, as well as keeping retrospectives fresh.
Facilitation Basics
The form taken by a retrospective should be flexible, and should follow from the expected substance. Think about the aims of the retrospective, and about expectations. Then choose an appropriate form.
Stand Up Meetings
I find stand up retrospectives are surprisingly successful, especially when learning, building teams, or using short iterations. When time is short, or when the project is progressing well, I find it better to use this form than to skip the retrospective.
Learning Using Stand Ups
When the content is expected to be more substantial (for example, at the end of long sprint), prepare a more structure form. Use physical exercises to gather data, generate insights and move forward. But prepare to be flexible, and adapt the form to the emergent substance.
A Minimal Structure
Regardless of form, a minimal lightweight structure helps a meeting to flow and the team to focus. A good patten is for the facilitator to start the retrospective by setting the stage, establishing the tone and engaging the team; to stand back (metaphorically and physically) and observe, measuring interventions carefully; and to close the meeting at the end of the timebox, bringing everyone together to create a clear collective memory.
Space Physicality Location
Retrospectives benefit from a less directed, participatory style. For those with less confidence and experience in this style, the loss of direct managerial control may seem intimidating. So, I'd like to close by considering how direct control can be traded for influence.
Cafes In Space
I like to think of facilitation acting at the meta-level. Direct control over the proceedings is traded for the ability to step back from participation and observe. The psychological distance created between the facilitator and the group of participants creates a separation of concerns. The facilitator deals with process layer aspects (such as timeboxing, flow and engagement) whilst participants deal with the substantive content.
Meetings With Tables
But a key influence on the health of a retrospective is the environment - the space, ongoing physicality and the location chosen. And this is within the control of a facilitator. Consider location and choose appropriately. Prepare the space carefully. Observe team physicality during the meeting, and step in quickly to remove impediments.
And Finally...
Some Agile Humour
Posts
