Difference between revisions of "Rob's Guide to Effective Retrospectives"

From Agile Retrospective Resource Wiki
Jump to navigation Jump to search
 
(19 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
 
===Retrospective facilitation is a skill===
 
===Retrospective facilitation is a skill===
Ensuring the meeting is not being driven by whoever shouts the loudest or ending up as a long ineffectual debate takes thought and practice.  
+
The first section of Derby and Larson's book [https://pragprog.com/titles/dlret2/agile-retrospectives-second-edition/ Agile Retrospectives: Making good Teams Great] remain essential reading for how to effectively facilitate retrospectives.
  
Conversely, and something more common with remote working and online meetings is highly transactional transactional meetings which are no more than [https://twitter.com/chrismdp/status/1493155571154833413?s=20&t=UagX05G8gwHBwSBrI1hdbA Improvement Theatre].  
+
Ensuring meetings are not being driven by whoever shouts the loudest or ending up as a long ineffectual debate takes thought and practice.
  
''"Retrospectives should be where people truly critique the status quo.
+
Conversely - and something more common with the increase in remote working and online meetings - is highly transactional retrospectives which are no more than [https://twitter.com/chrismdp/status/1493155571154833413?s=20&t=UagX05G8gwHBwSBrI1hdbA Improvement Theatre]:
  
A place with tension, difficulty and honest searching for a better way.
+
''"Retrospectives should be where people truly critique the status quo.<br/>
 +
A place with tension, difficulty and honest searching for a better way.<br/>
 +
Where people make themselves vulnerable and do the hard work of forging agreement.<br/>
 +
With these kinds of retros, things actually change."'' - [https://twitter.com/chrismdp/status/1493155573965090818?s=20&t=UagX05G8gwHBwSBrI1hdbA Chris Parsons]
  
Where people make themselves vulnerable and do the hard work of forging agreement.
+
===Start each retrospective with [[The Prime Directive]]===
 +
The purpose of the Prime Directive is to assure that a retrospective has the right culture to make it a positive and result oriented event. It makes a retrospective become an effective team gathering to learn and find solutions to improve the way of working:
  
With these kinds of retros, things actually change."'' - [https://twitter.com/chrismdp/status/1493155573965090818?s=20&t=UagX05G8gwHBwSBrI1hdbA Chris Parsons]
+
'''''"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."'''''
  
The first three chapters of Derby and Larson's book [http://pragprog.com/book/dlret/agile-retrospectives Agile Retrospectives: Making good Teams Great] remain essential reading.
+
--Norm Kerth, Project Retrospectives: A Handbook for Team Review
  
===Start each retrospective with [[The Prime Directive]]===
+
===Achievable actions and owners for each action===
The purpose of the Prime Directive is to assure that a retrospective has the right culture to make it a positive and result oriented event. It makes a retrospective become an effective team gathering to learn and find solutions to improve the way of working.
+
A common failing with retrospectives is either not taking actions away or the actions not being completed. My first tip here is make your actions small, really small. Big vague goals like "write more unit tests" are pointless. A great retrospective to encourage small achievable actions is the [[Plan of Action]] retrospective.
  
'''"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."'''
+
Once you have your achievable actions make sure someone is responsible for each and every one you choose to take away. This doesn't have to be the person who is going to do the work, just the person who is responsible for making sure it happens before the next retrospective.
  
--Norm Kerth, Project Retrospectives: A Handbook for Team Review
+
Track the actions as you would with the rest of the work in your team in your favourite work tracking tool
  
 
===Rotate the facilitator role===
 
===Rotate the facilitator role===
It is common for it to be one person's job (e.g. Scrum Master, Team Lead) to facilitate/lead retrospectives. This can result in bias towards their point of view and prevent a team from feeling engaged and empowered to solve their own problems. Whilst it may be one person's job to make sure they happen, that doesn't (and shouldn'tt) mean they also have to run every retrospective too.
+
It's common for it to be one person's job (e.g. Scrum Master, Team Lead) to facilitate/lead retrospectives. This can result in bias towards their point of view and prevent a team from feeling engaged and empowered to solve their own problems. Whilst it may be one person's job to make sure they happen, that doesn't (and shouldn't) mean they have to run every retrospective too.
  
 
Get everyone to take turns facilitating. Not only does this ensure no one feels retrospectives are being driven by one person's agenda, there are many other side benefits, including:
 
Get everyone to take turns facilitating. Not only does this ensure no one feels retrospectives are being driven by one person's agenda, there are many other side benefits, including:
Line 30: Line 34:
 
* Retrospectives are less likely to become dull or repetitive.
 
* Retrospectives are less likely to become dull or repetitive.
  
Really easy to do if you have more than one team - '''ask for someone from another team to facilitate your retrospective''' and when it's their turn return the favour and has the wonderful side-effect of being a great way to cross-pollinate ideas between teams.
+
Really easy to do if you have more than one team - '''ask for someone from another team to facilitate your retrospective''' and when it's their turn return the favour. This has the wonderful side-effect of being a great way to cross-pollinate ideas between teams.
 
 
===Achievable actions and owners for each action===
 
A common failing with retrospectives is either not taking actions away or the actions not being completed. My first tip here is make your actions small, really small. Big vague goals like "write more unit tests" are pointless. A great retrospective to encourage small achievable actions is the [[Plan of Action]] retrospective.
 
 
 
Once you have your achievable actions make sure someone is responsible for each and every one you choose to take away. This doesn't have to be the person who is going to do the work, just the person who is responsible for making sure it happens before the next retrospective.
 
  
Track the actions as you would with the rest of the activity in your team in your favourite work tracking tool
 
  
 
===Start each retrospective by going through the actions from the previous one===
 
===Start each retrospective by going through the actions from the previous one===
Before doing anything else, begin the retrospective by going through the actions from the previous retrospective have been completed. If not, why not? Time box this to 5 minutes.
+
Begin the retrospective by reviewing the actions from the previous retrospective. Have the been completed? If not, why not? Time box this to 5 minutes.
  
If the team took 5 actions but completed none, agree to take fewer actions away from this retrospective. Once the team has got better at completing the actions they've committed to then maybe they can increase the amount of actions they take away.
+
If the team took 5 actions but completed none, agree to take fewer actions away from this retrospective. Once the team has got better at completing the actions they've committed to then consider increasing the amount of actions they take away.
  
  
 
====Who is Rob?====
 
====Who is Rob?====
 
I'm [https://twitter.com/@robbowley Rob Bowley], the person who set up this wiki.
 
I'm [https://twitter.com/@robbowley Rob Bowley], the person who set up this wiki.

Latest revision as of 01:44, 2 April 2024

Retrospective facilitation is a skill

The first section of Derby and Larson's book Agile Retrospectives: Making good Teams Great remain essential reading for how to effectively facilitate retrospectives.

Ensuring meetings are not being driven by whoever shouts the loudest or ending up as a long ineffectual debate takes thought and practice.

Conversely - and something more common with the increase in remote working and online meetings - is highly transactional retrospectives which are no more than Improvement Theatre:

"Retrospectives should be where people truly critique the status quo.
A place with tension, difficulty and honest searching for a better way.
Where people make themselves vulnerable and do the hard work of forging agreement.
With these kinds of retros, things actually change." - Chris Parsons

Start each retrospective with The Prime Directive

The purpose of the Prime Directive is to assure that a retrospective has the right culture to make it a positive and result oriented event. It makes a retrospective become an effective team gathering to learn and find solutions to improve the way of working:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

--Norm Kerth, Project Retrospectives: A Handbook for Team Review

Achievable actions and owners for each action

A common failing with retrospectives is either not taking actions away or the actions not being completed. My first tip here is make your actions small, really small. Big vague goals like "write more unit tests" are pointless. A great retrospective to encourage small achievable actions is the Plan of Action retrospective.

Once you have your achievable actions make sure someone is responsible for each and every one you choose to take away. This doesn't have to be the person who is going to do the work, just the person who is responsible for making sure it happens before the next retrospective.

Track the actions as you would with the rest of the work in your team in your favourite work tracking tool

Rotate the facilitator role

It's common for it to be one person's job (e.g. Scrum Master, Team Lead) to facilitate/lead retrospectives. This can result in bias towards their point of view and prevent a team from feeling engaged and empowered to solve their own problems. Whilst it may be one person's job to make sure they happen, that doesn't (and shouldn't) mean they have to run every retrospective too.

Get everyone to take turns facilitating. Not only does this ensure no one feels retrospectives are being driven by one person's agenda, there are many other side benefits, including:

  • Learning how to facilitate is great for developing communication skills and generally how to have effective meetings.
  • The burden of planning retrospectives is shared across multiple people.
  • Retrospectives are less likely to become dull or repetitive.

Really easy to do if you have more than one team - ask for someone from another team to facilitate your retrospective and when it's their turn return the favour. This has the wonderful side-effect of being a great way to cross-pollinate ideas between teams.


Start each retrospective by going through the actions from the previous one

Begin the retrospective by reviewing the actions from the previous retrospective. Have the been completed? If not, why not? Time box this to 5 minutes.

If the team took 5 actions but completed none, agree to take fewer actions away from this retrospective. Once the team has got better at completing the actions they've committed to then consider increasing the amount of actions they take away.


Who is Rob?

I'm Rob Bowley, the person who set up this wiki.