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?

Release Vision Exercise

In late 2014 the delivery team working on the Copyright Hub as part of the Digital Catapult UK where a bit confused about the upcoming Beta Release. They were getting mixed messages regarding what the release was for, when it was due, and what were the most important features to be included. To resolve this situation I gathered the delivery team and the customer representative and ran a collaborative Release Vision Exercise, which is described below.

Release Vision (45 minutes)

Who? 
Who is the audience of the beta release?

What? 
At a high level what will the beta release contain? Aim for no more than five bullet points.

Where? 
Where will it be used? All industry sectors? All parts of England? Europe, etc.

Why? 
Why would the users and stakeholders make the painful effort to change their existing habits and migrate to this new product? 

Strap Line…
What is a one sentence summary that we could use internally? LITMUS TEST: Can the delivery team come up with a strap line that they and the customer representative agree with?

The list was brainstormed, then discussion followed by dot voting determined the winner.

Release Levers (10 minutes)
What is the order of importance of the following items? Please note they must be ordered, i.e. there cannot be two priority one items.

• Scope – number of features included in the release (more is important)
• Cost – project budget / number of people involved (low costs is important)
• Schedule – when will it be released (earlier / on time release is important)
• Value – Usefulness and usability of the included features. (user experience is important)
• Aspects – ilities of the system, i.e. Security, Maintainability, Performance, Adaptability, etc. 

The blue numbers are the aggregate result of the Product Owner and Customer Representatives separate votes.

The end result

This process surfaced some key issues that the customer representative and Business Analyst (acting as Product Owner) disagreed upon and allowed them to resolve these differences. It also provided clarity to the delivery team regarding what they were being asked to do. The end result was a successful release that has changed the face of copyright on the internet forever.

Tree Root Diagrams, a powerful problem solving addition to the Five Whys

Solving problems in this complex world can be a huge challenge. The Five Whys is a powerful technique in our hunt for the root cause of an issue; however it rarely provides the full answer. Combining Tree Root Diagrams with the Five Whys can ensure that your team gains a full understanding of the root cause(s) of the issue. Once you know the root cause(s) a permanent solution is only a few simple actions away.

A Tree Root Diagram captures all of the causes linked to an issue in a downward expanding tree of causes. These diagrams often look like the root structure of a large tree. They are most useful when a group of people is collaboratively solving a complex problem.

The approach is straight forward: on a large whiteboard write your issue (really the symptom) in the top middle part of the whiteboard. Ask “What caused this to occur?” Write a very brief summary of each cause that is mentioned and draw an arrow from the symptom to each cause. Now repeat for each cause, building up your tree as your examine each cause. For each Root Cause you identify, circle it and come up with an action or two to address it. List the actions near the Root Cause and draw a line from the actions to the Root Cause.

Benefits of Tree Root Diagrams

• Finds multiple causes of a single symptom; including related issues.
• Visualizes the relationship between the symptom and its many causes.
• Visually links actions to the Root Cause the group is addressing.
• Allows the group to discuss tangential topics then return to the core issue without losing track of what they were up to.
• Acts as a record of what the group discussed and agreed upon.

More Examples

A simpler example

An example of when it is quiet linear.

A complex example

How I stumbled onto Tree Root Diagrams

Around July 2015 I was coaching some new Scrum Masters in effective problem solving and usage of the Five Whys. I keep hearing myself suggest to them to write down each answer to Why that the team called out. My intention being to get them and the team realized that the first answer is rarely the root cause. I quickly realized I was not doing this myself and set out to walk my own talk. What I found when I made a concerted effort to write down the causes, was that there were often multiple possible answers to each Why. Hence my notes quickly turned into tree diagrams which I labelled as Tree Root Diagrams and have used ever since.

Ishikawa diagrams

Tree root diagrams are similar yet different to Ishikawa diagrams turned 90 degrees. Ishikawa diagrams focus on categorizing the different causes in a hierarchy. Tree Root Diagrams focus on the linkage between causes; of potentially very different categories.