Scrum is defined as a framework, based on Agile approach for managing activities, with an emphasis on knowledge work development (mostly software these days).
Scrum uses time-boxed cycles of events and activities – that fit into a time-frame called Sprint – in order to bring in the scope, work on it, check on the progress and flow, and complete the committed work and deliver.
The Retrospective session is the opportunity for all members of the Scrum Team to reflect back on the “Quality” of the Sprint that has just come to an end, identify the areas of strength (to make sure they get more of it or even improve on it) and the areas of weakness (to review, analyze, decide on solution and define action items, in the shape of scope for the upcoming Sprint(s) to fix them and keep them off the team’s path).
The main purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to: People, Relationships, Process, and Tools;
- Identify and order the major items that went well and those which didn’t! (potential for improvements) and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.
But there is more …
Sprint Retrospective, is also a great opportunity for the Scrum Team to have some fun activities for team building and learning!
The Scrum Master ensures that the meeting is positive and productive (keeping the focus on root cause analysis of identified issues and away from blaming and finger pointing) and ensures it is kept within the time-box.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the upcoming Sprints.
Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.
Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.
We need to make sure to Create and Add stories to the Product Backlog for implementing the improvements!
Let’s take a closer look…
Empirical evidence from observation of hundreds of Sprints across several companies within multiple industries shows that well structured and well performed Retrospective ceremonies, help Scrum teams achieve significant improvements in Productivity, Quality and Capacity
They allow teams to find problems earlier and address them early enough to keep them away from stressing the team close to the release dates and allowing for more thorough testing cycles away from the pressure of approaching release deadlines.
They also free up teams from having to fix unnecessary bugs that could have been avoided in the first place … and …
Shows where are weaknesses in the cross-functionality of the team; If we are overwhelming a team member due to their expertise, we could take pairing and knowledge transfer steps to extend the expertise across the team and level the workload … and
… many more benefits
Keeping it Real
Retrospective sessions are part of Scrum Teams’ investment in their own performance and productivity improvement.
All members of the Scrum Team and whoever that have worked with the team during the past Sprint is invited to contribute to the work.
What we want to cover in Retro
Start with a Personal-Status-Check:
The Scrum Master will ask everyone to make themselves comfortable and then to describe in a couple of words, what is their current feeling or state of mind (this is to change the mood and get the attendees to open up from the beginning.)
We can expect answers like Okay, Relaxed, Confused, , Tired, Bummed, Overwhelmed, Relieved, …
Quickly Review the Steps in the Process with the Attendees:
1. Review of Past Retrospective: (how successful we have been in implementing the action items for resolutions we chose the last time)
2. Looking at “What Went Well” and “What Didn’t Go Well” in Sprint we just finished and note them down.
3. Looking for common sources of trouble behind the items on the “What Didn’t Go Well” list.
4. Voting on the importance of items listed on “What Didn’t Go Well (or as planned)”.
5. Selecting the Top n (normally top 3) for Root-Cause Analysis.
6. Performing Root-Cause Analysis and – potentially- re-wording the issues in the lights of the further reviews (or to add new issues identified as revealed by further discussion.)
7. Brain-storming on solutions for the updated list and defining Action Items in the shape of Stories to address the issues. (add them to the Product Backlog.)
Looking at What Went Well
Scrum Master asks attendees to write down – on a sticky note – what went well for them or the team that they want to mention and bring it to the board. It is okay if they may want to share more than one item.
The purpose of this practices is to:
1.Get the team to remember and appreciate things that went well (esp. on successful action items from the previous Retrospective session!)
2.Build up on the good experience and try to make it happen again and seek ways to improve it to even better levels.
Looking at What Didn’t Go Well
Scrum Master asks the Scrum Team to identify key problems with how the Sprint proceeded through the past iteration. Each identified item is to be looked at by the team in order to identify or resolve the problem.
Scrum Master can also add more areas of discovery if the team would welcome the idea of expanding their classification beyond the two basic classes of “Went Well” and “Didn’t Go Well”:
Classes such as
“What Sprint Goals we missed”, or
“What we want to try next”, or
“What was confusing to us”, or
“What we hoped for”,
and similar categories can be added if there is appetite!
Identification
Decide if it was indeed an issue (To avoid working on the wrong item!)
Decide if it can be recurring in the future (To avoid planning to fix something that won’t happen again!)
Identify the components, contributing factors and parallel / co-existing issues around the identified problems (To ensure we are looking at a complete picture of the issue!)
Try to find repeated or shared patterns / common causes across identified problem (To find solutions that would address multiple issues!)
Add feeling markers to each one; things like: Frustrated, Confused, Surprised, Stressed…, (To help the team remember the importance of a resolution and to help them recover from their bad feelings once the issue is resolved!)
Vote on which ones had the highest impact (To help focus on the highest positive impact through solutions!)
Vote on the Issues that we would want to address in this session (top n high impact items).
Solutioning
Brain-storm on “Approaches” to address each one
Decide on “Success Criteria” for each Approach.
Executing The Session
The Process followed by the Scrum Master to execute the session:
(% shows the suggested portion of time allocated to the process step)
- Open the Session, 2-5%
- Engage Attendees, 5%
- Encourage them to participate and collect information, 25-30%
- Encourage them to share insights, 30-40%
- Get consensus on Solutions, 10-15%
- Close the Session. 2-5%
Then Help Product Owner to create Stories to capture Approaches
1. Open the Session:
Proper opening to the session assists the attendees to engage in the work that needs to be done. It also helps them remember the steps and sets the mood for sharing experiences, insights and solutions when needed.
Scrum Master starts with welcoming participants and appreciating their contribution in advance.
Scrum Master then reiterates the purpose of the session and the timing.
2. Engage Attendees:
At times it may look difficult to have everyone participating in the activities. It is very important to ensure everyone shares and participates.
Scrum Master asks everyone to share a word to describe how they feel about the Sprint that they just finished, then …
Scrum Master asks them to share a word to describe why the hope this retrospective will achieve.
Note: You don’t have to do both … but if it goes, let them have a laugh about it and choose funny words to lift up their mood esp. if you just finished a tough Sprint!
3. Encourage them to participate and collect information:
It is important to lay out rules for the session to help the team focus and stay involved.
Scrum Master asks the team to avoid multi-tasking (get them the leave their computer at their desk and don’t let anyone browse their phones)
Scrum Master makes sure their team champion – the most senior member – would not take ownership of the session. (if you see he/she is the only one talking, thank them and say it is now someone else’s time to contribute).
It is very important to get the perspective and opinion of everyone on the team when discussing issues. No single team member could have seen everything and have known about every incident or root cause.
Scrum Master starts the team to look at the “hard facts” (what we know already in the shape of events and things that happened during the Sprint, Metrics, meeting minutes, milestones, QA reports, defect counts, Velocity, Amount of code refactored and so on); These are facts with records and no need for assumption or recall from someone’s memory.
Helping the team visualize the past events and recorded facts using a timeline would enable them to better re-construct the past Sprint in their minds and identify patterns and find connections between events.
4. Encourage them to share insights:
At this point we get the team to look for the reason behind the issues and try to come up with ideas on how to do things in a better way.
Scrum Master leads the team to study the situations, conditions, interaction and patterns that had good or bad outcomes and encourages them to try to look at each from a variety of perspectives, and try to find additional possibilities (gets the team brain-storm them one at the time).
Scrum Master may want to lead the team to perform the fish-bone analysis on the more complex issues to identify the root of the problem.
The Team then chooses the top priority issues and suggests solutions for them.
Scrum Master then gets the team to use dot-voting to select the top priority issues (average 3 issues) they want to take to the next phase (solutioning);
Scrum Master will now lead the team to brain-storm on the solutions. Every team member write their suggestions on sticky notes and brings them to the board.
Scrum Master ensures each suggested solution is clear enough for the team (and helps the team to add more clarification if needed).
Scrum Master groups the solutions by context and works with the team to merge solutions that are close to each other and to eliminate duplicates.
5. Get Consensus on the Solutions:
By now that the team has identified the key issues and has come up with a variety of solutions for each. Next, we put each solution to the vote to select the action items we want to execute for each.
Scrum Master gets the team to use the dot-voting on the solutions for each issue.
Scrum Master works with the team to ensure everyone is clear on the context of each selected solution (including the Acceptance Criteria) and the timing of their execution and ownership of each item.
Scrum Master ensures that the Product Owner has the needed details to create Stories for the action items selected.
6. Close the Session:
At this point we get the team to decide how they want to keep track their experience today (mostly we take picture of the board that was put together and make sure we add the stories to the product backlog).
Scrum Master thanks the team for their participation and contribution.
Scrum Master ensures owners of action items are aware of their accountability over the execution of the stories created.
Scrum Master then performs a mini-retrospective on the finished session and asks for feedback on the quality of the session and adds new action items (if needed) for relevant owners.
Tips:
1. Delegate:
Scrum Master may want to delegate the hosting responsibilities of each Retrospective session – in a rotating model – to members of the Scrum team to help them get more engaged and create more excitement and perspective. (with the Scrum Master supervising the session)
2. Stories vs. Things:
Scrum Master may want to get the team to vote on “Stories” that went well and those which didn’t if the team is having a hard time pinpointing “Things” that did not go well. (This helps new teams to target areas of trouble without pointing at each other).
3. Three-tier Classification:
Scrum Master may want to get the team to use a 3 classification setup of “Liked / Learned / Lacked” instead of the standard “What Went Well / What Didn’t Go Well”, to change the approach slightly and get the team to open up further.
4. The 1% Fix Philosophy:
Scrum Master may want to turn one of the Retrospective session into discovery of “Quick Wins”, and work with the team to identify small areas that benefit from small improvements. By small improvements we refer to things that can be done within an hour or two that can improve something one step forward. This is based on the 1% Fix Philosophy by Dave Brailsford: “It’s very difficult to improve 1 thing by 100%. It’s much easier to improve 100 things by 1% for the same effect.”
5. Effort-Pain classification approach:
Scrum Master may want to use this approach in occasions when team finds it difficult to decide on the priority of issues to addressed.
Using the graph, Scrum Master asks each team member to mark their identified issues in the proper location.
The issues can be sorted along two vectors of Effort (amount of effort it would take to fix them) and Pain (the amount of pain they have been causing).
Naturally the higher the pain and the lower the effort needed to fix (i.e. higher return), the higher the priority for fixing! Naturally we would avoid the area with higher efforts and lower Pain.
Anti Patterns To Avoid
The following “Bad Practices / Habits” would need to be avoided:
- Retro Shmetro!: Team has lost faith in the value or Retro and not attending anymore!
- Retro Sacrificial: Team keeps cancelling Retro because they keep needing more time to finish their work.
- Speedy Retro: Team is forced to wrap up the work due to time shortage and cannot do a good and deep analysis and solutioning.
- Intangible Solutions: Solutions suggested and voted cannot be put into action items due to their vague or unrealistic form.
- No Accountability / Ownership: Action Items are not followed and no one is asked about them, thus they may or may not happen.
Team Building
Retrospective ceremonies are great opportunities to setup the Scrum Team with some fun, Team Building activities. The Team Building activity can be on-site or off-site but it would work best if done face-to-face.
The Team Building section can be done at the beginning to boost team’s morale and raise their interest in participation further into the Retrospective’s Issue Id/Resolution practice.
It can also be done at the end of Retrospective to help the team change mood and energize before getting back to work (Just make sure you will have enough time to complete the activities chosen for that session).
It is recommended to have large celebrative events held after successful delivery of large initiatives to get the team feel appreciated and lift up their spirits for another set of hard work.
Buying Lunch for the team or taking them to a group playground or any group events would be a great idea.
Over the course of time, a good collection of ideas regarding Team Building games and group activities during Retrospective has been created and tested by the Scrum Team.
Some of these ideas are suitable for new teams and some for more mature team setups.
These ideas can be found on internet through a number of links. A good collection of these ideas can be found in the website: Fun Retrospectives
You can also purchase their book online containing a large number of ideas.
Cheers to improved Retros!
Arman Kamran (The Agilitizer)
