Coaching Retrospectives - Starting Off Right!
Join the DZone community and get the full member experience.Join For Free
As an Agile Coach, one of the key principles I teach teams is how they can benefit from meeting up regularly to discuss the way they are working. This principle is often referred to as 'short feedback loops'.
There are a number of different ways the team can do this, but the one I want to write about in this post, is arguably the most common one; the team Retrospective.
When working with a new team, there are 3 things that I'm thinking about as I approach the first Retrospective. They go something like this:
1) RETROSPECTIVES - EXPLAINING THE WHAT, THE WHY AND THE HOW
By this I mean, WHAT is a retrospective? WHY do we do them? HOW do we run them?
This sounds easy right?! Whilst I've done this many times before, I frequently like to remind myself that people are different and every team is different, even within the same organisation.
So with this in mind, I will vary my answers to these 3 questions (above) dependant on the group of people who are sat in front of me. I'm thinking how can I describe this in a way that will instantly click for this team, in order that we can hit the ground running.
Example 1 - with a Team who have done retrospectives before - 'So to recap guys, Retrospectives are an opportunity for everyone in the team to openly discuss the ways we are working and focus on how we continuously improve. There are a number of different formats we can use to run a retrospective which range from round robin feedback format to themed games, but they all aim for the same output.
Example 2 - with a Team who don't know what a retrospective is -'Ok everyone, so this session will be new to you all. It's called a Retrospective. It is basically a team feedback session which focuses on the way we are working. Now this session is positive, it's certainly not something to worry about. We discuss the way we are working in a constructive and aim to break out tasks to help us improve in the next 2 weeks.
2) HOW CAN I ENCOURAGE TEAM MEMBERS TO OPEN UP AND SHARE?
I can't stress enough the importance of this! Without the team members opening up to share their experiences, the team can't have a fluent discussion and get a consensus of what problems they face or what areas they feel they can improve in.
This relates back to Point 1, in the sense that I use the first retrospective to convey to the team that this is their session, to get across their views and discuss what matters to them.
To encourage team members to share I use a variety of Facilitation techniques. For example using a soft tone (non managerial), probing the guys by asking them to elaborate on points and encouraging quieter team members to share with the group.
KEY TIP : Lead by example. Kick off the first retrospective by giving an update yourself to show how it's done! Alternatively, if you have a team member who is very enthusiastic/championing this way of working, I've found it works well to chat to them about how the session will run beforehand.
This is to give them an overview of how the session will run and ask them if they'd mind giving the first update in session. Doing this means the session kicks off with a good example, allowing momentum which will also encourage other team members to share.
3) HOW CAN I HELP THE TEAM BREAK OUT AND COMMIT TO TASKS THAT IMPROVE THE WAY THEY WORK?
I've always found it effective to visually capture (on a wall/board/chart) the feedback the team are giving me as it's coming in. It gives assurance to the person speaking that you've captured their point and also helps the point being made register in the minds of other team members.
A way of doing this is capturing the feedback as posts its on a wall that are grouped into 2 categories; a) Things we are doing well and b) Things we could improve on.
With things you're doing well - I like to open it up to the team if they want to do anything with this information, visualise it? If so, how?
Now... focusing on the b) Things we could improve on - by visualising these feedback items as they comes in, we haven't yet focused on tasks, but that's ok. Once this feedback is collected we can then have a follow up activity where I ask the team if the feedback is in the form of a task. If not I ask the team to agree on the conversion of the feedback to a task. By forcing the conversion of this feedback into tasks, we would be restricting the flow of this feedback as it's coming in and thus stifling creativity.
The fact that we've collected this feedback is all good.
It means we have the key information brain dumped and out of everyone's head. We can then at the end of the session work as a team to discuss each 'could improve' post it and say is this in the language of a task? If not, discuss together and give me a task that would help us achieve the improvement we want.
WHAT IF IT DOESN'T START RIGHT?
You can sometimes do the above, feel you've done a good job preparing, facilitating the session and it still doesn't get off to a good start.
The important thing here is don't panic!
Take a step back and do what you're asking the team to do: reflect on it. Why didn't the session go to plan and how can you mix up next session with the aim of overcoming the issues the first one had.
Like anything in Agile, there's no magic formula, no one silver bullet! Don't be afraid to experiment, to fail fast and with perseverance you will get there :-)
Opinions expressed by DZone contributors are their own.