Your teams 1st retrospective will be your hardest retrospective

High emotions, Intertwined issues and Inexperience are the key challenges that will all combine to make your 1st retrospective the hardest retrospective you have to facilitate. This situation is similar to your first driving lesson being on a rainy night, while you are surrounded by drunk drivers. Luckily there are steps you can take to tackle all three key challenges, and run the teams first retrospective successfully.

High emotions

For teams that have not had an effective avenue to express and tackle their day to day work issues; there tends to be a lot of emotion released in their first retrospective. During the retrospective team often realise they have a voice and are being listened to; hence a lot of the issues they have been frustrated about are vented. The emotional venting that occurs is hard to hear yet often therapeutic for all involved. If you and the team can turn those emotions into actions that address some of the teams’ frustrations they will not just like retrospectives they will love them.

Mitigation actions 

1. Display the Prime Directive and read it out as part of your introduction.
2. Acknowledge all input provided by the team, even if you disagree with it. You only have to acknowledge what is said, you do not need to agree with it. Merely the simple act of acknowledge is enough for the team to feel heard and hence reduce the level of emotion in the room below boiling point. The easiest way to acknowledge their input is to read out all of the post-it notes that they write out in the gathering data phase.

Intertwined issues

New teams and existing teams that have not held retrospectives previously; will often have their first retrospective dominated by a tangled mess of intertwined issues. The trouble is that one or two root causes are creating many, many symptoms and likely a lot of frustration. So no matter which symptom the team selects to analyse; it is intertwined with several other symptoms. This tangled mess drives the team conversation around in useless circles unless structured techniques are used to untangle the mess.

Mitigation actions

1. Ensure you have plenty of time to discuss the first topic
1. Schedule 90 minutes for the retrospective, one hour is just not enough time
2. Time box the early parts of the retrospective to ensure enough time for discussion at the end.
2. Accept it is likely that the team will only get to analyse the top priority issue. The good news is that addressing just one issue will be big success for your first retrospective!
3. Use Tree Root Diagrams to help untangle the intertwined symptoms.

Inexperience

When this is the first retrospective for the team, yourself or both, there are likely to be feelings of excitement, anticipation, apprehension, uncertainty, etc. Also the role of facilitator is challenging at the best of times, as you attempt to juggle time-boxing, active listening, note taking and group facilitation. Thankfully there are plenty of resources available to prepare you and the team. Here are just a few approaches to get you started…

Mitigation actions for your inexperience

1. Observe retrospectives run by more experienced facilitators.
2. Pair with an experienced facilitator for your first retrospective.
3. Delegate Time keeping to someone in the team.
4. Delegate taking notes to someone in the team.

Mitigation actions for the Teams’ inexperience

1. Circulate the retrospective objective and agenda ahead of time
2. Provide the team with Retrospective Prompting questions a couple of days prior to the retrospective.

Retrospective Prompting Questions

Retrospectives can generate an enormous amount of input in the right circumstances; which allows for a rich investigation of how to improve the team. However there are some situations which can lead to an input drought; and the prevention of team improvement. I have found that the list of questions at the end of this article can be used to easily prompt a team to generate input which leads to an effective retrospective and steady improvement of results.

There are four situations in which these questions prove particularly useful:

One: Team transforming from command and control culture

When transitioning to agile from a strong command and control environment, many team members say as little as possible in Retrospectives. They are used to being told what to do, and do not want to seem like the ‘trouble maker’ by pointing out obvious issues. The prompting questions help them to find something that the feel comfortable providing input on. The more often they provide input in retrospectives and don’t get in trouble for it, the more useful information they will provide in the future.

Two: Team is new to retrospectives

Teams that haven’t done retrospectives in the past often don’t understand the scope of what can be discussed. To aid the explanation of scope and to help bring out information from quiet team members the following list of questions is often useful. 
Again for teams transitioning from a command and control culture the scope of what they could change in the past was very limited. This compounds their reluctance to speak up. 

Three: Retrospectives stagnating; due to repetition

For teams that have done many retrospectives; there can come a time where they run out of things to discuss. The prompting questions help them to broaden their view and finds topics worth discussing as a team.

Four: Scrum Masters

For the Scrum Master it will be worth reading these questions prior to each Retrospective and working out which questions could be used to prompt discussion within the team.

Retrospective Prompting Questions

Delivery

• Is our team delivering as fast as possible? If not, why not?
• Why did the extra tasks appear in the sprint? 
• Why were User Stories/Tasks not completed?
• Why were some User Stories/Tasks, only partially completed?
• Did the team over commit? 
• Was the team reliant on one person/skill set to complete a task? 
• Were any milestones missed?
• Were last Sprint Retrospective actions items completed?
• Where our estimates accurate? Both Story Points and hours?

Quality

• What was the quality of our deliverables appropriate?
• Did the Review/Demonstration make you proud to be a member of this team?
• Was the test coverage (both automated and manual) sufficient for our needs?
• Did our documentation provide the information that we required to complete our jobs?
• Did rework hold us back this sprint?
• What was the cause of the bugs/tickets that we worked on this sprint?

Scrum 

• It has now been X sprints that we have been using Scrum, do we think our situation is better or worse since starting? What is better? What is worse?
• What did everyone work on immediately after the Planning meeting? Why did people work on items other then high priority User Stories?
• Why were low priority tasks being worked on, while high priority user stories were on hold?
• Was the Product Backlog ready for use at the planning session? Prioritised, estimated, enough detail?
• Did the Burn-down Chart realistically represent the progress of the team?
• Did everyone view the Burn-down chart as useful?
• How did everyone contribute to User Story value?
• Is everyone happy with how the Stand ups are working? Can they be improved?
• Is everyone happy with how the Reviews are working? Can they be improved?
• Is everyone happy with how the Retrospectives are working? Can they be improved?
• Were the actions created from our last Retrospective completed?
• Were the actions created from our last Retrospective beneficial?

Communication and Team work

• Did anyone in the team do outstanding work that should be acknowledged?
• Did team members just at the chance to help each other?
• Did anyone have difficulties obtaining timely information/assistance from people in the team? I.e. Architect, Test Specialist, Documentation Specialist, Scrum Master, etc.
• Did anyone have difficulties obtaining timely information/assistance from people outside of the team? I.e. Product Owner, external Technical Expert.
• How is the morale of the team?
• Was everyone clear on the team goals?
• Was everyone clear on their personal priorities?
• Did internal knowledge transfer occur in a timely and effective manner?
• How was the team internal communication? Was it clear, concise and timely?
• How was the intra-team communication? Were expectations and dependencies clear?

To my blog readers

• What questions would you add to this list?
• Are there questions you would remove, or change?

Promoting constructive discussions in Retrospectives

When transitioning to agile from a strong command and control environment, many team members say as little as possible in Retrospectives. They are used to being told what to do, and do not want to seem like the ‘trouble maker’ by pointing obvious issues. Over time they will realise that it is a good (and safe) thing to point out issues so that the team can work on solving them. 

The scope of what they could change in the past was very limited, which compounds their reluctance to speak up. Usually it takes a while for them to realise that the scope of what they can now change is vast. The task board is quiet often seen as something the team owns and due to its highly visible nature is one of the first areas that teams start to make changes. After the team has implemented their first couple of changes, the Scrum Master should explain to the team just how big their scope for change through Retrospectives really is. 

To aid the explanation of scope and to help bring out information from quiet team members the following list of questions is often useful. For the Scrum Master it will be worth reading these questions prior to each Retrospective and working out which questions could be used to prompt discussion.

Delivery / Completion

• Why did the extra tasks appear in the sprint? 
• Why were User Stories/Tasks not completed?
• Why were some User Stories/Tasks, only partially completed?
• Did the team over commit? 
• Was the team reliant on one person/skill set to complete a task? 
• Were any milestones missed?
• Were last Sprint Retrospective actions items completed?
• Where our estimates accurate? Both Story Points and hours?

Quality

• What was the quality of work produced like?
• Was the test coverage (both automated and manual) sufficient for our needs?
• Did our documentation provide the information that we required to complete our jobs?
• Did rework hold us back this sprint?
• Did the Review/Demo make you proud to be a member of this team?
• What was the cause of the bugs/tickets that we worked on this sprint?

Scrum / Continuous Improvement

• What did everyone work on immediately after the Planning meeting? Why did people work on items other then high priority User Stories?
• Was the Product Backlog ready for use at the planning session? Prioritised, estimated, enough detail?
• Did the Burndown Chart realistically represent the progress of the team?
• Did everyone view the Burndown chart as useful?
• Were last Sprint Retrospective actions items beneficial?
• How did everyone contribute to User Story value?
• Is everyone happy with how the Stand ups are working? Can they be improved?
• Is everyone happy with how the Reviews are working? Can they be improved?
• Is everyone happy with how the Retrospectives are working? Can they be improved?
• It has now been X sprints that we have been using Scrum, do we think our situation is better or worse since starting? What is better? What is worse?
• Why were low priority tasks being worked on, while high priority user stories were on hold?

Communication and Team work

• Was everyone clear on the team goals?
• Was everyone clear on their personal priorities?
• Did internal knowledge transfer occur in a timely and effective manner?
• How was the team internal communication? Was it clear, concise and timely?
• How was the intra-team communication? Were expectations and dependencies clear?
• Did anyone have difficulties obtaining timely information/assistance from people outside of the team? I.e. Product Owner, external Technical Expert.
• Did anyone have difficulties obtaining timely information/assistance from people in the team? I.e. Architect, Test Specialist, Documentation Specialist, Scrum Master, etc.

Photo Credit: https://www.flickr.com/photos/ajc1

Top Tips for Project Retrospectives

Project Retrospectives tend to be high stakes, emotionally charged, cross teams events, with managers in attendance. This all adds up to an environment that is not ‘Safe to Fail’ as you would expect in a typical Sprint Retrospective. While my Top Tips for Sprint Retrospectives can still be applied to Project Retrospectives; the several significant differences between these Retrospectives, means a different style of approach is needed.

Project Retrospectives are useful when a project spans multiple teams and multiple sprints. During the project I would expect that each team would hold a Sprint Retrospective every Sprint. The Project Retrospective is an additional ceremony that occurs after the project is completed. This could also apply to Release Retrospectives, i.e. a Retrospective for all of the agile teams involved in a multiple sprint release.

What follows are my top tips for running a successful Project Retrospective. i.e. A Retrospective that allows the real issues to be identified and action taken to resolve them.

Tip: Choose the attendees wisely

The attendees that you invite will have a significant bearing on the issues that are identified and importantly on how successfully those issues will be addressed. I recommend you invite:
• Representatives from all teams involved in the project.
• Representatives from all disciplines involved in the project (e.g. product owner, leaders, project managers, business analysts, developers, testers, designers, architects, support). 
• People who will speak honestly in front of management.
• Stakeholders/Management that will hear the issues first hand; then be available to own and resolve those issues. This is crucial to a Retrospective leading to real change.
• As few people as possible, certainly less then 15. To help with this mix up the discipline you invite from the separate agile teams. e.g. Developer from one team, tester from another, business analyst from a third.

Tip: Get all attendees to prepare ahead of the meeting 

About a week ahead of the Retrospective, hand out post it notes to all attendees and ask them to pre-write their thoughts: what went well, what went poorly, what can we improve? This will save a lot of time in the meeting.

You can also get prepared yourself. I recommend researching a timeline of important events from the life of the project (e.g. Customer signs contract, First Release, huge technical issue first identified, original targeted delivery date that was missed, Final Release). Just prior to the start of the meeting you can draw up this timeline on the whiteboard.

Also just prior to the start of the meeting you can write the objective of the meeting up on the whiteboard. Such as ‘Objective: Assign Owners to the Key Issues we identify.’  This will prove useful when discussions in the meeting start to get off track. You can point to the written objective and ask if the current discussion is helping us to achieve our goal?

Tip: Schedule it promptly after the Project ends

Timing is crucial. It should not be immediately after the project ends, because some peoples feelings will be raw. It should definitely be within one month of the project end, so that it is still fresh enough in everyone’s memory.

Tip: Use a structured yet simple agenda

The agenda that I recommend is:
• Facilitator provide an introduction [1 minute]
• Gain shared acceptance of the meeting objective [2 minutes]
• Attendees to post their ideas on the timeline & cluster them as appropriate [5 minutes]
• Facilitator lead discussion of the clusters in priority order (large clusters first) [75 minutes]
• Facilitator summarise the issues and owners [5 minutes]

Tip: Focus the meeting on assigning owners to the key issues

While facilitating the meeting you should try to focus the discussions on 
• Bringing out the issues; and moving towards the root cause. 
• Agreeing which issues are the priority issues to be addressed.
• Getting agreement on who in the room should own each issue and hence resolve it.

Tip: Follow up after the meeting

Send the list of agreed issues & agreed owners to all of the attendees. You may want to consider posting this in a public location such as a Wiki.

The real key is regularly following up the owner of each issue. You need to ensure that they are working on resolving the issues. Otherwise the whole exercise will have been an expensive whinge-fest. 

Retrospectives are meant to lead to Real Change, you can make it happen.

Interested in more tips?

• Top Tips for Planning Poker
• Top Tips for Retrospectives

Photo by: Rafael Anderson Gonzales Mendoza  

Top tips for Retrospectives

Tip: Change ‘Five Whys?’ to ‘Five What Caused that?’

“No problem can be solved from the same level of consciousness that created it.” Albert Einstein 

This quote is one of the many reasons why I am a big advocate of using the Five Whys techniques in Retrospectives. My experience shows me that finding and then fixing the root cause has a much longer lasting effect then fixing the reported problem (aka symptom). While the Five Whys technique is great; there a little twist that can make it even more effective for new teams.

Teams are new to Retrospectives find it a big challenge to raise issues that they are used to ignoring or hiding. Creating an environment where they feel safe to bring up issues is critically important for the success of the Retrospective.

‘Why’ is a word that puts people into a defensive state of mind.  As it focuses the respondent on their own involvement in the issue and hence, they are inclined to play down the issue for fear of making themselves look bad. Hence I prefer to phrase the Five Whys as the Five ‘What caused that?’ Using the word ‘what’ takes the focus off the respondent and lets them look at the issues that caused the symptom. This allows them to stay in a problem solving state of mind as opposed to a defensive state of mind. 

Lastly when looking at a tough problem, writing up the Five ‘What caused that’ items on a whiteboard as the team discusses the issue helps to give the discussion focus.

Tip: Validate the input of all attendees

One of the most effective techniques for creating a safe environment in Retrospectives is a simple one; validate the input of all attendees, especially the quiet people. What I do to validate their input is summarised in these points:

• Validate each idea that is raised by either reading the idea aloud or repeat back the idea that was raised verbally.
• Treat all people and ideas equally (even if I strongly disagree)
• Keep the Retrospective to one conversation at a time so that everyone is involved in all of the discussions.
• Specifically ask quiet people what they think about issues under discussion.
• Support quiet people to get their ideas across when they do voluntarily speak up.

Tip: Prioritise and cluster

The Retrospective format that I most often use is ‘Puzzle, Problem, Try, Keep’ from Agile Retrospectives by Esther Derby and Diana Larsen.

Starting the Retrospective with five minutes for participants to write up their thoughts onto Post-it notes in silence is a method that allows everyone to provide their own unique input without being influenced by other participants. I suggest one thought per Post-It note, as it makes arranging and discussing each thought much easier. You can stick the Post-Its notes into the Puzzle column to begin with and it is usually a good idea to cluster similar thoughts.

Image 1: The teams ideas clustered in the Puzzle column by theme

With the initial thoughts clustered into the Puzzle column any important issues will stand out as a big clump. If you have lots of separate thoughts, it will be worth asking the team if there are any burning issues before proceeding. 

With the large clusters and burning issues identified you now have a set of thoughts to address first.

Tip: Use a workflow

I see the ‘Puzzle, Problem, Try, Keep’ Retrospective as a workflow. Thoughts start out as Puzzles and either stay there or move to be a Problem. Problems link to Tries. Tries from previous Retrospectives were either successful and hence become a Keep, or need to be re-tried or are dropped. In general this results in a left to right workflow.

After gathering the Thoughts of the participants into the Puzzle column it is always worthwhile discussing the Tries from the previous Retrospective. Was the Try successful and hence should become a Keep. Did the Try have issues that we think we can overcome; hence it stays as a Try. Is it an abject failure, hence dropping off all together? Discussing previous tries shows the team that Retrospectives are for delivering outcomes not just suggesting Tries that are never followed up on.

Image 2: The Try's from last Retrospective being reviewed and placed accordingly.


Now it is finally time to address the new thoughts. I suggest discussing each thought in turn.

For puzzles and problems, use the ‘Five What Caused That?’ approach to identify the root cause, aka Problem. Once it is clear that you have a Problem move the Post-It to the Problem column and list the root cause.

Image 3: Put the top priority discussion topic into the Problem column and noting its root causes.


With a Problem in the Problem column that is well understood and it has a root cause identified it is time for the team to recommend one or more Tries. These are written in the Try column and you should draw arrows from the Problem to the matching Tries. The arrows represent cause and effect, ensuring that we put effort into Tries that will have some lasting impact.

Image 4: Linking the Problem to its Try's.

For thoughts about things that went well, or items you should keep; be sure to discuss with the team why it was successful and how we can ensure it will be successful again in the future.

Tip: Find the Problem that Tries are attempting to solve

Often participant’s thoughts will be suggestions for Tries, e.g. ‘Run the tests in parallel’, or ‘Use Gradle for our build process’. In this case it is very important to understand what Problem they are attempting to solve before just adding the Post-It note to the Try column. You can use the ‘Five What Caused That?’ approach to ensure that you attempting to solve the root cause.

Image 5: What the board could look like at the end of a Retrospective.

Tip: Make sure Tries are turned into action

I have seen several teams that where good at coming up with Tries, yet were poor at acting on those tries; hence they did not improve as fast as they could have. The reasons for the lack of action were many and varied. Here are a few of things that I have found to help teams follow through on their Tries. They can be used in isolation or in combination.

• Assign a single person as an Owner of each Try during the Retrospective.
• Display the list of Tries near the teams Task board.
• Create a Task cards for each Try and put it on the Task board.
• Discuss the progress of each Try during Daily Stand ups.

Interested in more tips?

• Top Tips for Planning Poker
• Top Tips for Project Retrospectives