As a child my parents used to take me and my brother to Wells next the sea for holidays. I have to say it is my favourite beach and it brings back many fond child hood memories for me.

Faced with what to do with my parents, my nephew and the dog for 4 days recently, I happened to be cruising the internet and came up with the brainwave to relive my youth and booked up a caravan for us all at the very same site. This was my opportunity to take my nephew on the same adventures his dad and I had when we were younger.

Now, those that know me wouldn’t expect the words Helen and caravan to be in the same sentence, but I took the risk and ensured that I ordered the luxury version. I must say though that caravans have significantly improved since my child hood!

Wells has a fantastic beach, pretty woods and a little train to take you to the quaint town centre. Once in town, there’s time for the rock shop, fish and chips and a spot of crabbing. I whole heartedly recommend paying a visit if you have never done so.

So whilst I was reminiscing and retrospecting with my nephew,  a couple of my friends were struggling to retrospect with their own teams. One was advised that ‘The team didn’t need a retrospective as nothing has happened’ and the other was encouraged to squeeze it into 30 minutes. Even the most mature teams would struggle in 30 minutes, but this team was only on sprint 3 and most certainly needed to discuss their issues.

This is not the first time I have seen these behaviours. Teams are not always seeing the value of retrospectives, and from my experience I would say the reasons are in the following areas:

• They are not engaging for the team
• Improvements or challenges get discussed, but nothing ever get resolved
• Not facilitated well so the lose momentum and focus

Let’s tackle these one at a time.

Making your retrospectives engaging

It never ceases to amaze me how many people I meet who don’t vary their retrospective techniques, and still use the classic (What went well, didn’t go well, etc).

I encourage 3 types of retrospectives;

• Team retrospective – A look at the last iteration from the Scrum Team perspective
• Release retrospective – A look over a release or period of time and could include people external to the Scrum Team
• Deep dive – A targeted retro to tackle a specific problem e.g. Why do we never complete all the stories?

There are great books and websites out there that host a whole plethora of techniques for every possible situation you find yourself in. Each team is different and will have their favourites, but variety is the spice of life. One of my earlier teams were extremely creative and so they got the most out of the drawing, word association and improve types. Others were more data driven around milestones.

Never be afraid to try out new techniques and if they don’t work, move onto the next. No one wants to be doing the same one forever! I also encourage that you get people up and active, no one wants to be glued to a seat.

Continuously Improve

Why wouldn’t you get demotivated if you are raising issues or improvements that never get actioned, and are talked about sprint after sprint. As ScrumMasters and Coaches we should be encouraging the teams to discuss these items, find solutions and take the actions into the sprint. We cap these at 2 or 3 per sprint to ensure that they are committed to and can be resolved. We need to ensure that we allow time to complete these activities as part of the sprint planning meeting.

We should also be encouraging those larger action items to be raised as user stories, and discussed with the Product Owner for scheduling as part of the Product Backlog.

Regardless of how we action them, all of the issues or improvements need to be stored, visible and brought to each of the retrospective meetings so they aren’t forgotten, and can be brought into play at any time.

Also as a ScrumMaster consider whether it makes sense for you to resolve any of these for the team yourself  E.g. Getting super sticky post it notes as the others fall off the wall.

Ultimately if the team see that issues are resolved and improvements implemented, it will encourage them to raise and resolve more. Leading to high performance  and self organisation.

Get organised

It is not acceptable to rock up unprepared. You need to prepare! Even seasoned professionals need time out to think about how they are going to facilitate the session, and help to drive out learning and information.

I usually book a timeslot of 2 hours for a retrospective and look to reduce this as the team matures. Conducting a release retrospective can take up to half a day depending on complexity of the release. Either way, leave yourself plenty of time to achieve the goal.

The book Agile Retrospectives by Esther Derby & Diana Larsen gives a good structure for us to follow and the percentage of time suggested for each section.

• Set the Stage 10-15%
• Gather Data 15-20%
• Generate Insight 15-20%
• Decide What To Do 20-25%
• Close 10-15%
• (Breaks 10-15%)

Using this structure,  slot in the format of the retrospective and maybe an ice breaker or closing game for the team enjoyment. Icebreakers are a great way to get people talking and can be used on teams that have been together for a while also. It is a fact that if you can get people to engage and speak in the first 5 minutes of a meeting, then their contribution to the meeting will be increased compared to those who did not speak.

Facilitation of this meeting is another important aspect. ScrumMasters need to be reading the unsaid word in the room through looking at the teams body language, and listening to what they are saying. Using these observations you can then interject with powerful questions to help draw out more information or feelings.

Sometimes I come across very laissez-faire ScrumMasters. There is nothing wrong with having a laissez-faire style of leadership, however some use it as an excuse to take a back seat. They can sometimes hide behind saying they want the team to solve their own problems. I agree that teams need to solve their own challenges, however sometimes the lack of facilitation by the ScrumMaster is not laissez-faire but lack of interest or they don’t understand the problem. Never be afraid to give options on how you have seen other companies solve similar problems. This can point them in the right direction, but ultimately they will implement what’s best for them.

Final thoughts

Retrospectives are a must have part of any team and the appropriate time and consideration need to be given to them.

I challenge you to take a look at your own practices in this area and see where you can make improvements.

Get in contact if you need any help or want to brainstorm techniques.

Tweet.