• Retrospective Facilitator’s Gathering – Wiki website detailing the yearly gathering of people passionate about facilitating retrospectives
• Retrospectives – The first website Kerth put up describing the practice of Project Retrospectives.
• Links to retrospective resources – A good collection of links to blogs, articles, etc that are related to retrospectives

I’m really pleased to fin

I’ve pondered whether or not that this has been a bad thing for our project. I’m a huge advocate for using retrospectives to help encourage people to create change on their projects. I’m a huge advocate for using retrospectives to bring the team together and understand what’s going on. Fortunately I’m lucky that our team has some very strong people with probably 40% of them having true skin-in-the-game experience working on agile teams that things just get done and more importantly, things continuously improve.

I definitely believe that without all the experienced agile team members, we wouldn’t have overcome all the different and sometimes bizarre situations (ask me if you see me!) thrown our way. Do I think retrospectives still offer us some value? Yes, but probably not for the reasons that most people use it for.

It’s amazing what a bunch of energised, passionate and people with the “solve the right problem once” attitude can achieve. I’d only wish that more teams were made up of people like this more often!

I think the more interesting question is, “When are retrospectives most useful?” To help explain my thoughts, I’ve put together the following: A Model for understanding Retrospective Impact (click on it for a slightly bigger view).

What is a retrospective?
Being specific and clear about this term is important in the discussion about whether or not retrospectives are useful. Some people’s understanding of a retrospective can differ from other people’s depending on each of their experiences. The conversations on the Kanban list seem to imply retrospectives are solely an iteration focused ritual (and of course, there is no such concept of a Scrum or XP iteration in Kanban). Though I appreciate Kerth’s original definition, I think in the agile community, Derby and Larsen’s definition better captures its essence:

A special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork.

I like this definition best because its ties the concept of improvement (inspect and adapt) based on a shared understanding (the team) according to some unstated time period (an increment of work, noting it’s not specifically tied to an iteration).

What is impact?
I think it’s also important to define the term impact. One of the definitions by the Oxford Dictionary seems most appropriate:

a marked effect or influence

I want to emphasis that you can have a high impact retrospective without necessarily taking a lot of time, and that the opposite is entirely possible too (a long retrospective with a low impact). Note that I’m not going to discuss how to run retrospectives that have the highest impact (a totally separate topic worth its own set of posts).

Effect of team dynamics
The state of the team has an enormous influence on the impact of retrospectives. A high performing team will naturally have better communication amongst its members, and are more likely to fix things that get in the way of their goal. There will naturally be better and more frequent individual improvements, identified and implemented more frequently without the call for a specific meeting. This doesn’t mean that retrospectives are never a practice they call upon. Rather, it’s a practice that has less impact as there are many other items in the toolkit that get called upon. Sometimes it’s important for the group to get together, establish a common understanding and to inspect and adapt noting there may not be any specific regularity to these particular meetings.

In contrast, a dysfunctional team are less likely to call upon individual improvement practices, and thus, retrospectives play a more important role, providing an explicit opportunity to improve. I use the term dysfunctional in this sense to capture a broad category including newly formed teams, or simply groups of people. This does not necessarily mean the team cannot advance, nor that it hasn’t had a chance to advance, just simply the state it exists in.

Environmental Effects
I would classify a majority of environments as chaotic. In chaotic environments, improvement isn’t second nature. Through practices that start with good intentions such as auditing (“I want to have confidence you are doing what you say you are doing”), people in these environments become afraid to suggest changes, and are often fearful of attempting anything different because they’ve been punished for a failed experiment in the past. In these chaotic environments, retrospectives have a significant impact by providing an explicitly safe environment for teams to make, commit to, and hopefully be supported in making changes. Retrospectives have a higher impact in these environments because the majority of other activities doesn’t encourage learning, innovation and improvement.

In contrast, a nurturing environment welcomes fail fast innovation, rewards learning from failed experiments and supports continuous improvement in an explicit, non document centric approach. In these environments, the outcomes from implementing improvements and passing on tacit learnings is more important that meeting audits and compliance. Retrospectives have less impact in this environment because individuals are more likely to suggest and implement improvements without the need for a special meeting, and without the need for an entire team. Once again, it doesn’t necessarily imply that retrospectives are not useful (some issues require a shared understanding across the entire team) or that they are regularly scheduled events.

Avoid deciding between whether or not you run retrospectives. Consider when is it best for you to run a retrospectives instead.
Understand what situation you find yourself in using the model above and ask yourself whether or not retrospectives have the potential for the most impact (dysfunctional teams and chaotic environments), or where energy is better spent pursuing other activities because retrospectives have less, but not zero, impact (high performing teams and nurturing environments).

In the next set of posts, I hope to describe different situations I’ve seen first hand and what impact retrospectives had in relation to them.

Leave a comment and let me know what you think.

Unfortunately many teams suffer without realising improvements go beyond retrospectives. Everyday there is an opportunity to improve, an opportunity to learn. It sometimes takes a while to see them. It often takes much longer to unwind the restraints of organisational “process” on people’s desires to experiment and fail fast, and learn from those mistakes.

Don’t get me wrong. Retrospectives also have their place. Sometimes teams don’t have an environment safe enough and retrospectives are one way of helping establish some safety. It takes commitment from leaders to create this environment of safety, and something I encourage greatly when I work with teams.

Do you recognise your team falling in this pattern? Break out of them, and remind them that improvements don’t have to wait for a meeting to be attempted.

When I’ve sat in teams new to retrospectives and the goal is not made clear, people start to bring up too many different issues, and it’s difficult to resolve anything. One hour seems to be the maximum that teams are willing to set aside, and when you’re dealing with team issues, technical issues, process issues and more, all that time literally flies by. The result… nothing is improved and people get frustrated with the vehicle that brings some visibility (the retrospective).

What you can do about it
I use a rule of thumb, “One Goal Per Heartbeat Retrospective”, and make it clear at the start of the retrospective. It helps, if you’re the facilitator, to agree on what that goal is before you start, and do whatever you can beforehand to make sure everyone agrees. It helps if you’re working with a team that is already is formed (see the Tuckman Model) and you confirm this before hand.

Place the goal in front of everyone where they can see it, both as a subtle hint, and as an aid if you feel the retrospective veering off. Run retrospectives with a different goal in mind to address those that you don’t get around to talking about.

Photo of the cross signs taken from Gregkendallball’s Flickr stream under the Creative Commons licence.

Image taken from Dr Pat’s Flickr photostream under the Creative Commons licence.

Photo taken from Opheliates Flickr stream under the Creative Commons Licence

What you can do about it?
Sumeet writes about using SMART (Specific, Measureable, Achievable, Relevant and Timeboxed) to help focus forming better action items. He also writes about giving them an owner and a time frame. I will often use this to guide the discussion – “Is this achievable in two weeks time? How can we break this down to ensure we make some progress? Does everyone understand what you need to do to call this item complete?”

I also like Bas’ Plan of Action approach, linking short term actions with long term goals – allowing people to break down large changes into more achievable ones, or to help align short term tasks with longer, more strategic goals.

As a facilitator, be aware that how you deal with the last part of the retrospective will influence the result, for better or worse. Learn how to facilitate the group towards something more likely to result in an observable change.

Image taken from Meredith Farmer’s Flickr photo stream under the Creative Commons licence.

What to do about it?
In preparing for the retrospective, I like to go through this list of questions:

• Who is the sponsor for the retrospective? – Sponsors may have extremely different agenda. Some of it may be about spreading lessons learned, others just want to understand the root cause of some major problem. You want to be clear about who the sponsor is and why you’re even running a retrospective. Is there just one person, or are there more of them?
• What are their goals, and what are you going to end up by the end of it? – Looking for ways to improve client relationships will have a completely different focus than understanding what new technical innovations came out of the project. The goals will heavily influence what exercises you plan for.
• Do you know how long the retrospective will be looking back? – Planning to look back over 1 week will be different from 3 months and different again from 1 year.
• Do you have an idea about what topics might come up? – A retrospective for a project where significant negative events dragged the team at certain stages will be different from a retrospective for a project that had less troublesome issues.
• Have you planned for enough time to cover everything? – You want to have enough time for people to tell their stories, unload any emotional baggage and get to understand what lessons are worth sharing.
• Do you have a good representation from team members? – Just having development members in a retrospective will skew what you talk about, perhaps missing important elements all the way from the sale, client relations, etc.

Just before starting the retrospective, also ensure that you have all the materials prepared – this may includes markers, pens, paper, sticky notes, handouts. Also ensure you have the room prepared with any posters or whiteboards you plan on using.

An important aspect to the role of the facilitator, is to do as much as they can to sustain the energy of the group and to tap into everyone’s capacity for embracing and dealing with change. Helping people contribute their story to the retrospective helps. Letting people tell their story in full helps. Facilitating difficult conversations towards a non destructive outcome helps. Moving the team towards specific, tangible actions or concrete lessons learns helps.

After the retrospective, I’ve always wondered what responsibility the facilitator has for ensuring change. My conclusion is that, in reality if they are truly independent, it’s none. Of course, the facilitator may care (and I can assure you I do) about following through on the change, yet all the systemic forces that push for and against change tend to be out of the influence of a truly independent facilitator.

In short, retrospectives are agents for change, yet ultimately it comes down to the empowered team to make sure the changes really happen. My advice to managers is to give teams responsibility and, with that, the decision making authority, to help them make the changes they need to.

What is it: A variant of the Art Gallery exercise except using a common drawing to start the creative juices.

Time needed: 10 minutes

What you need:

• An index card per participant prepared in the same way (see below)
• A marker pen

How to run it:

• Before the retrospective, prepare each index card by drawing a set of symbols on it (I started with two lines and a circle)
• Hand out the cards
• Explain that you all have the same set of symbols and you would like everyone to spend the next five minutes turning it into a picture that represents the state of the project
• After five minutes, ask participants to share their story with the group

Tips for facilitating Mr Squiggle

• Ask participants to avoid writing words as this exercise is meant to be a visual, creative process.
• Provide other colours and markers to help with the creative process.

Summarising:
Mr Squiggle brings a different take on the Art Gallery picture at demonstrating how a simple set of symbols can be converted into completely different stories when explained by participants.