Organizations need to continuously improve to stay in business and keep delivering value. The classical model of improvement using large programs takes too long and is often inefficient and/or ineffective.
To excel in today’s fast-paced world, businesses need to make better, faster, and cheaper improvements – for there are limited resources to spend and too many choices to make. An iterative approach to change is thus needed to achieve short-cycled improvements which can also provide frequent feedback while maximizing learning.
Retrospective is one such method of achieving sustainable continuous improvement. In contrast to the traditional method of making changes at the end of a project which may be too late for meaningful improvements, retrospective enables teams to inspect and adjust their approach early on.
Retrospectives are owned and performed by teams who decide when, where, and how they will change their way of working instead of having the changes dictated by others. It gives them the power to become self-organized and make lasting improvements that stick.
Origin of Retrospective
The roots of retrospectives are intertwined in agile methodologies which provide software development frameworks centered around collaboration, iteration, learning, and value delivery.
The broad idea is for teams to break large efforts into small, manageable increments and tackle them in time-boxed cycles, known as iterations. This practice has vastly improved flexibility, time to market, risk mitigation and quality of software development and has found applications beyond the software industry.
The twelfth principle of the Agile Manifesto states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” [1]
This is where retrospectives play a role. They are about reflecting on the past to improve the future. At a granular level, a retrospective helps in:
- Evaluating how the last iteration or a work item went, specifically around the team dynamic, processes, and tools.
- Articulating and ranking the items that went well and those items that did not.
- Creating and implementing a plan for improving the team’s workflow.
- Providing a safe place to focus on introspection and adaptation.
The Retrospective lifecycle
Since one of the goals of agile development is to achieve the shortest possible lead time, agile teams execute a full cycle of Plan-Do-Check-Adjust (PDCA) [2] as quickly as possible. Each PDCA cycle represents an iteration and includes a retrospective:
Each retrospective has five steps which repeat in every iteration:
1. Setting the stage
The goal of setting the stage is to help people focus on the work at hand and create an atmosphere where people feel comfortable discussing issues. This can be achieved by:
- Welcoming and showing appreciation for people’s investment of time.
- Restating the purpose of the retrospective and the goal of the session.
- Encouraging everyone to speak – since the point is to group think and learn together, everyone’s participation is vital. Long conversations must be avoided at this stage. The idea is to encourage a word or two from each participant. This could be, for example, describing expectations for the retrospective.
- Setting the timeline – time is precious, and people would want to know if their time will be well spent. Setting a timeline helps keep progress on track.
- Establishing an environment to discuss difficult topics and have challenging conversations – team values and working agreements are helpful social contracts to establish acceptable behavior and interactions. They enable people to talk about tough issues, bring up emotional topics, or even deliver unwelcome news.
For example, simple agreements such as “Come prepared to meetings” or “Everyone has an equal voice” can significantly improve the quality of retrospectives.
It is a good practice to monitor adherence to working agreements during the retrospective. When the team takes responsibility for their interactions, they can focus better on facilitating.
Many retrospective leaders do not see setting the stage as the “meat” of a retrospective and like to skip the step. This can prove costly later because when people don’t speak early, they may not contribute at all, and may not buy into the team’s insights and decisions.
It is important neither to skip or skimp setting the stage.
2. Gathering Data
Gathering data for an iteration that lasted a week or two may sound silly but even when someone misses one day in a weeklong iteration, 20% of the insights could be lost.
People seldom see everything the same way and can have different perspectives on the same event. Gathering data expands everyone’s perspective and helps create a shared understanding. Without this, individuals tend to verify their own opinions and beliefs.
Gathering data involves accumulating information on:
- Hard data such as events, metrics, features, or completed user stories (a user story is an informal, general explanation of a software feature requirement written from the perspective of the end-user).
- Meetings, decision points, changes in team membership, milestones, celebrations, adoption of new technologies.
- People’s feelings about the facts and the team.
Team members can either report verbally on data and events or use visual aids such as task boards and big visible charts. Visual depiction makes it easier to identify patterns and connections.
While hard facts are important, they are only half the story. The other half is made of emotions, without which, many important conversations can never happen.
It is important to create a structured way for people to talk about feelings and make them comfortable to raise topics that have an emotional charge. Avoiding this can sap energy and motivation out of the team or may manifest into anger which goes against the goal of retrospective.
3. Generating insights
In this step, the team asks “Why?” and begins thinking about what to do differently. The team begins by examining the conditions, interactions, and patterns that contributed to success while investigating breakdowns and deficiencies that led to unexpected events or outcomes.
While it is easy to jump to solutions once problems emerge, it is important to consider additional possibilities, look at causes and effects, and think analytically. It’s also the time for the team to think together.
Generating insights is about stepping back, seeing the big picture, and delving into root causes. Time spent generating insights helps ensure improvements will make a positive difference and have a lasting impact.
4. Deciding actions
By this stage of the retrospective, the team has a list of potential improvements. The task at hand is to pick the top items (no more than two) as having too many initiatives can overwhelm the team and its ability to change.
The team must choose items based on how well they can commit to it, and the positive impact it is expected to have. For example, if the team is already recovering from a stressful change, it must choose something less complex this time.
Taking action during the retrospective helps build momentum. However, encouraging individual commitment is crucial to ensure task completion. When people don’t commit individually, there’s a tendency to assume that someone else will take care of the task, often resulting in inaction.
5. Closing the retrospective
Ending the retrospective decisively is important to ensure that the team’s energy doesn’t dribble away. This involves documenting the experience and the follow-up plan. The team must decide how to retain what they have learned during the retrospective.
It is important to close the retrospective with an appreciation for the hard work everyone put in both, during the iteration and the retrospective. It is also a good practice to conduct a small retrospective of the retrospective.
The Start-Stop-Continue Retrospective
The Start-Stop-Continue Retrospective (SSCR) is one of the several approaches to conducting retrospective sessions. While SSCR follows the general retrospective steps detailed earlier, it frames the conversation around what to start, stop, and continue doing based on goals and resources:
The team performing SSCR generates insights by asking itself three questions:
What can the team START doing to help things that didn’t go well?
- How can processes be streamlined better?
- What challenges did the team fail to account for?
- What skills, opportunities, or tactics were not fully leveraged?
- How can the scale of operation be increased?
What happened that shouldn’t happen again (STOP)?
- What made the job harder or wasted the team’s time?
- What errors or snags crop up repeatedly?
- Which elements of the workflow require the most effort but have the least payoff?
- Are there initiatives that aren’t serving larger organizational goals?
What went well in the past iteration that must CONTINUE?
- What strategies and tactics made the process easier and in what ways?
- Which goals were achieved consistently?
- What aspects of the workflow are indispensable?
- What helped when things got tough?
The best order is Continue, Stop, Start
While there is no prescribed order, it is beneficial to begin SSCR with Continue, progress through Stop, and finish on Start. This is because “Continue” shows what the team does best and starts the discussion on a positive note. This also encourages the team to highlight things that may be blocking its full potential – things that need to be “Stopped.”
Finally, the team can discuss things that need to be started which often requires a trade-off as a new process/activity often substitutes an existing practice.
Collecting and refining SSCR inputs
The team begins by providing inputs (answers) to the three questions. Given the diverse nature of the team activities, it is unlikely that an individual will have the complete picture, hence active participation from everyone is crucial.
Responses are then listed on a whiteboard or a screen for everyone to read. While this list can be long, the goal is to prioritize and pick one or two items to focus on for the next iteration. This can be achieved by:
Grouping
Duplicate or related ideas can be grouped. It is also natural for them to take priority as they tend to resonate with most of the team members.
N-votes
A form of voting where each member gets a fixed number of votes to rate items. For example, if each team member gets three votes, they can either apply them all to one idea if they feel that’s most important, or they can vote for two or three different items. The items with the most votes are then selected as focus items.
Ease vs importance matrix
Each action is ranked based on its importance and ease of implementation. The team then chooses actions that score high on both parameters. Such actions are both relevant and practical.
Actions that are important but difficult to implement can be reserved for lean periods when the team’s workload is relatively low.
Discussion
Sometimes, even after grouping and voting, a tie of ideas can necessitate further discussion. In such cases, the team can set a time limit to discuss each section. Those in favor of an idea must not only explain “why” it must be the business’s top priority but also address the “how” – the practical aspects of incorporating the idea into the workflow.
Advantages and limitations of SSCR
SCCR is a fast, easy, and non-threatening way of conducting retrospectives that works most of the time. SSCR meetings are very direct, to-the-point and action-oriented where each item directly leads to a change in team behavior. The team starts doing something, stops doing something, or continues doing something until it becomes a habit.
However, one limitation of SSCR is that it primarily focuses on actions while not explicitly encouraging discussions on feelings – an important requirement of retrospectives. In contrast, several other popular retrospective methods such as Sailboat, “Mad, Sad, Glad”, WRAP, 4Ls, Safety Check, and Team Happiness Radar actively encourage discussing team feelings [4]
SSCR beyond retrospectives
The SSCR framework is versatile and has been applied beyond retrospectives to drive continuous improvements in areas including project management, individual performance reviews, customer feedback, business strategy and personal development.
Irrespective of the area chosen, the concept remains the same – structuring inputs along the lines of what to Start, Stop, and Continue doing.
Sources
1. “Principles behind the Agile Manifesto”. Agilemanifesto.org, https://agilemanifesto.org/principles.html. Accessed 20 May 2024.
2. “PDCA”. Wikipedia, https://en.wikipedia.org/wiki/PDCA. Accessed 21 May 2024.
3. “Agile Retrospectives: Making Good Teams Great”. Esther Derby and Diana Larsen, https://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649. Accessed 20 May 2024.
4. “10 Retrospective techniques to try with your agile team”. Retrium, https://www.retrium.com/blog/10-retrospective-techniques-to-try-with-your-agile-team. Accessed 20 May 2024.
5. “16th State of Agile Report”. State of Agile, https://info.digital.ai/rs/981-LQX-968/images/SOA16.pdf. Accessed 20 May 2024.
6. “Agile Testing: A Practical Guide for Testers and Agile Teams”. Lisa Crispin and Janet Gregory, https://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468. Accessed 22 May 2024.
7. “Agile Retrospectives”. Atlassian, https://www.atlassian.com/agile/scrum/retrospectives. Accessed 22 May 2024.
8. “Agile Retrospective Resource Wiki”. Retrospective Wiki, https://retrospectivewiki.org/. Accessed 22 May 2024.