Saturday, December 10, 2016

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.


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.

Sunday, December 4, 2016

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


  • 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?


  • 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?


  • 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?