My name is Gregory Sedyh, I’ve been working at Sphere for almost 4 years and in the past 2 and a half years I’ve been working as a Scrum Master / Project Manager on projects with our client Groupon. Here, I’m going to talk about the importance of the Retrospective in Scrum Implementation. I’m going to share experiences of working with my team and the issues that the retrospective helped us to resolve.
What is Scrum?
Before we dive deep into the topic, let’s start with the definition of Scrum and what it offers. Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. Let me elaborate on this…
Scrum stands on 3 pillars. These are transparency, inspection and adaptation.
In scrum, you pick up a problem and start working on it, and as you work on it, you can look back and inspect and adapt. You can not only inspect and adapt the solution for the problem, but also the processes and how the team is implementing the scrum framework. Transparency here allows the team to be more effective because all the roles, interactions and meetings are designed to be clear for everyone about their work activities.
Scrum is not a technique or a definitive method. Rather, it’s a framework. Within it, you can explore various processes and implement them in different ways. Each team adapts according to their needs.
As we can see here in the next image, scrum offers roles, artifacts and ceremonies.
Scrum Roles
Product Owner
Let’s start with the roles. The Product Owner is the “captain of the ship”. The Product Owner is responsible for:
- Talking to stakeholders and users to understand their needs and vision of the product
- Provide description of the feature that needs to be built to the team
- Keep Product Backlog prioritized with minimum clutter
- Set priority to the Sprints
- Inspect increments and make adaptations for the next one
- Drive Sprint planning, Refinement sessions
The Scrum Master is the “servant leader” of the team. They’re not a decision-maker; the technical and business decisions are the responsibility of the Product Owner and the development team. The Scrum Master just facilitates the cooperation of the team and the Product Owner, and teaches them how to implement Scrum. The scrum master responsibilities are as follows:
- Servant leader of the team
- Facilitates the cooperation of the Team and the Product Owner
- Encourage the Team’s creativity, problem solving, and decision-making skills
- Remove all impediments to progress
- Tracking and promoting the Team’s productivity
- Drive Daily Scrum, Retrospective
Then, the 3rd role we have is the developers. Important here are cross functionality and self-organization; the team should include a variety of technical specialists and shouldn’t need any direct instructions from anyone on how to resolve blockers or deal with independencies. The development team responsibilities are listed below.
- Cross functional, up to 10 members (Dev, QA, arch, devops, design etc.)
- Self organized – manages itself and their work
- Makes a commitment and produces high quality shippable increments
- Owns and provides estimates
- Drive Sprint review session
Scrum Artifacts
Here is a quick overview of scrum artifacts.
Product Backlog:
- Ordered list of what is needed to accomplish the project vision.
- It is the single source of work undertaken by the Scrum Team
- Everyone contributes to the Product Backlog
- Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller items
Sprint Backlog:
- Ordered list of what is needed to fulfil the sprint goal
- Owned by the Dev Team
Increment:
- The Increment is a sum of all PBIs completed during the Sprint and some previous Sprints
- The Increment is a step toward the Product Goal
- Must deliver a business value, not just a part of technology
Scrum Ceremonies
I created this table as seen below to show how the inspection and adaptation are implemented in ceremonies. As you can see here, during the sprint planning, for example, we inspect the product backlog, and we have to adapt the spring goal, make a forecast and create a sprint backlog by the end of the meeting.
Let’s look at the last one on the table, the sprint retrospective, the main topic here. During this ceremony, we have to inspect our processes through collaboration, and those will resolve all existing technical questions and make adjustments to the definition of “done” if necessary. As a result, the team should make actionable improvements.
The Retrospective Objectives
Personally, I divide it into three main questions. These are:
- What worked or went well?
- What caused problems, failed to go properly, or didn’t go well?
- What can be done differently in the next Sprint to improve the process and overcome the problems occurring previously?
Next, I’ll show you how we make the retrospective on our team. Our process can be divided into four phases.
The Retrospective Phases
Information gathering
The first phase is information gathering. We use a tool called EasyRetro for that. I create the retrospective board in advance and share it with my team 1 or 2 days before our meeting. We do it this way now because previously, we spent 10-15 minutes working on the board at the start of the meeting, so we decided it was a waste of time to do it during the meeting and that it’s better to do it beforehand. In addition, it’s difficult to remember and add all the concerns and suggestions from the last sprint. I provide my teammates with more time to dedicate to work on the board outside of the meeting. The time during meetings is now better spent instead with bringing up any concerns or suggestions during the call, that they have already prepared.
Discussion of the items
Next we have the discussion of the added items at the Retrospective meeting with the team. After we discuss the items, we produce the action items and move to the third phase.
Defining and assigning the Action items
We produce the action items and decide on an owner for each of them. We make an agreement on what is important to us and what should be skipped.
Tracking of execution
Then, we have the final Retrospective phase. After the meeting, I add all action items to the Confluence page for further tracking.
Retro Board Example
Below you can see what our Retro board looks like! It has three columns. These are “Went Well”, “To Improve” and “Action Items”. Usually the “Action Items” column is blank at the beginning and during the meeting, we use the items from “To Improve” to create actions from those to be added to “Action Items”.
We start the call by sharing my screen showing the Retro board. We start by going through what went well, recognising personal efforts and achievements. This is an important column because it helps the team understand that we really appreciate each team member’s contribution. This meeting shouldn’t just address weaknesses and issues. Don’t forget to inform your team that you see all the extraordinary work they do and their achievements!
Next up, we have the “To Improve” column. Here, we have all concerns and suggestions from the team. Usually we go through them from top to bottom, but in some cases we have 10-15 cards in this column and I propose the team to start voting to pick the order to go through. Each teammate only has 3 votes and so can vote only for 3 cards. I provide them with approximately 3 minutes to go through all the cards and we start the voting process. After that, I sort out the column with the number of votes and we start with the most prioritized one by the team and work our way from top to bottom. When we start to discuss a specific card, usually I ask the author of the card to provide more information and we talk about the importance and proposed solutions.
Moving on from the “To Improve” column, we create the action items. Depending on the type of concern, for example something technical, I would talk with the developers on how to proceed. From there, we decide on the proposed solution and the owner of the item, the person who would be responsible for implementation.
Retrospective Action Items Document
As I mentioned earlier, after the meeting, I move the action items to the Confluence page. Below, you can see five columns which are the title of the issue or suggestion, the owner, plan of implementation, status and notes. At the beginning of each retrospective meeting, we review the Retrospective Action Items document and share the status and then we go to the discussion about the new items, because it would be nonsensical to have the Retrospective meeting without first reviewing previous decisions.
In addition, I’d like to share the 5 statuses for Retro action items. These are “OPEN”, “IN PROGRESS”, “ONGOING ITEM”, “ON HOLD” and “DONE”.
How has Retrospective helped us?
Below you can see our metrics. We started to maintain this document in summer 2021. You can see that near the end of the year, we have pretty good completion rates as well as turbulence rates. The big win here is from the teammates. The teammates know the weaknesses and can make suggestions for improvements.
Here are some of the achievements of our team using Retrospective:
- Reduced number of rollovers between Sprints (50% → <8%)
- Improved team’s engagement with Product Owner
- High level of effectiveness of Grooming ceremonies (40% → >90%)
- Velocity has been stabilized
- Team became more predictable with delivery
- Ownership of the team members on a higher level
Retrospective tools alternatives
Our team uses EasyRetro. In the free version, we get 3 boards per month, which is enough for me. Some alternatives you could use are GoRetro, Metro Retro, Retrium and Parabol.
Other Retrospective techniques
There are a variety of Retrospective techniques. I use the simplest one “Anchors” & “Engines”. We share our concerns, list our personal efforts and achievements. But below you can find some other techniques shown.
Words of advice
Don’t be afraid to complain
I tell my team of technical specialists, designers and developers to not be afraid to complain. If you have any concerns or difficulties, raise them and talk to the team, talk to the manager and don’t hide them. It would help you to avoid burnout.
Don’t be afraid to make suggestions
You as a team member have the most visibility of any weaknesses in the processes, and you have the influence to make them better. It’s difficult to understand all the engineering and QA processes from the top. It’d help the team and we really appreciate our teammates.
Don’t be afraid to try
This is a message mainly to the managers and the scrum masters to listen to your teammates — in most cases, they bring really cool solutions on how to improve processes. Be brave and be ready for changes. If you never try, you will never know.
Final thoughts
As a summary, I’d like to say that the spirit of friendship and honesty should be in the team. This is the key of the Retrospective meeting. It can be compared in some way to a visit to a psychologist, as you have to be ready to talk about the problem and work on solving it. I’d like to finish here with a quote “Small changes eventually add up to huge results.” So don’t be afraid to make changes and be ready for these changes.
This blog post has been created from a session I presented to my team at Sphere Partners. If you’d like to hear me do a Q&A with my team, check out the video at the top! The Q&A part starts at about 24 minutes in. Watch to hear me answer questions related to the tools and processes of scrum addressed in the session I covered.
Have a technical project in mind you’d like our help with? Reach out to us to request a consultation today.
