Retrospective: what is it and why is it useful?
It might seem relatively intuitive to most, or at least readily apparent to those managing teams over a long enough period, but the ability to look towards past experiences is one of the key components of truly learning and mastering a particular skill.
In school, we would often call this “reviewing”, where we would study our class materials, and past tests, and even answer practice questions in order to better prepare ourselves for a coming test. This essentially hard-coded the necessity of looking towards our past for clues into how we might better understand the future.
Those who are reading this article are likely to be far from those days studying in classrooms, but the concept still holds well into the professional world as a method of navigating often complex and new situations. This process of constant review and improvement of processes has even found its way into the agile framework techniques utilized in different industries. This technique takes the form of different strategic actions, but for the purposes of our discussion, we will call this the “retrospective”.
How Retrospectives Were Developed
The origins of retrospective techniques in business vary depending on how you might view them. One of the earliest developments of the retrospective as used in specific project management settings was by Alistair Cockburn, an American computer scientist and author of the book “Surviving Object-Oriented Projects”. In this book, Cockburn explores the different dimensions of project management and notes the importance of incremental improvement through regular regrouping with your teams.
He developed his concept further and eventually integrated it into what is now known as the Agile Manifesto, a guiding principle for agile software development. Here, he notes specifically a retrospective principle in that “[a]t regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.
Other experts have contributed to the development of the retrospective technique, such as Professor Norman L. Kerth who built upon agile’s retrospective focus through his book “Project Retrospectives”. In this book, he outlines various different ways to implement and execute retrospective techniques in your project as well as techniques for managing the possible issues that managers might run into.
Today, retrospectives are continually used by different businesses to better unlock insights that might not have been prevalent in previous iterations. Authors Esther Derby and Diana Larsen have further brought forward agile retrospectives in their book “Agile Retrospectives: Making Good Teams Great”. In this book, they focus on the concept of iterative and incremental retrospectives instead of the standard “post-mortem” that occurs only at the end of each project. It only goes to show that even something as ubiquitous as an insight hunting exercise can continually change into the future.
Applying Retrospectives in the Workplace
Irrespective of who or where these different agile retrospective theories were developed, it’s clear that the method is utilized in many different ways across equally different contexts. This falls in line with how agile methodologies were developed in order to address complex and constantly changing situations. As such, the agile retrospective needs to be just as capable of adapting to these situations.
The tricky tension between agile methodologies and the retrospective focus is agile’s inherent focus on generating the next iterative versions of a particular product or project. As such, the importance of looking towards the past for insights can be often overlooked in favor of direct incremental developments.
Agile retrospectives, when done right, necessitate that the team pause their processes to better reflect on the different aspects of what did and didn’t work in a particular process. While the overarching principles remain the same across the different industries, the implementation in different contexts will likely differ based on necessity and context.
Common Retrospective Meeting Formats
To better get started on developing an agile retrospective implementation within your business process, a standardized meeting format will better create a predictable expectation across all teams. Integral to these meetings is the cultivation of conversation across key stakeholders that have had involvement in the project. This includes different managers and team members across marketing, finance, sales, customer service, and more. A representative that can speak for these necessary stakeholders is required to get proper insights from the retrospective exercise.
Each retrospective meeting is usually led by different stakeholders as well. While product management teams usually lead things from an overall perspective, it can be beneficial to have specific functional roles lead meetings in order to allow each project stakeholder to have better ownership of the process and perspective into other tasks they might not have been aware of.
Rules and standard operating procedures will vary from company to company, but utilizing your organization’s set culture can be useful in developing a foundation for your retrospective meeting. But an important cultural touchpoint to develop in retrospective meetings is to ensure that these meetings remain a “safe space” as opinions and topics are likely to touch on specific responsibilities linked to individual stakeholders. Doing so allows organizations to foster a culture of idea-sharing that can help develop creative insights and reassure members that their thoughts matter.
A useful role to manage these different goals is to include a possible impartial third party, or what some might call a “devil’s advocate”. This can help settle disputes about what did and didn’t work in an objective sense, as well as which aspects had the most impact on a particular task or the project as a whole. Remember, these retrospective meetings should focus on both positive and negative aspects. Honing in too much on any particular one can affect the type of insights generated. Celebrate the wins alongside acknowledging the things you and your team could have done better.
A Retrospective’s End Goal
Because the structure of a retrospective meeting can be fluid and adaptable to many different contexts, the expected end goal of each meeting is likely to be just as free-form and dependent on the situation it tackles. At the very least, each retrospective meeting should have some output outlining what went well, what didn’t go well, and things that have the opportunity for further improvement. These can be laid out in a number of ways, but an excellent visual method to utilize is the Rose-Thorn-Bud framework, which helps separate the positives, negatives, and spots for improvement/development into three clear segments for others to analyze.
Adding information to this output could bring in a better explanation on why certain segments were noted as positive, or negative, and possible for further improvement. Context matters heavily in these different cases, so properly describing what led the team to these insights will be helpful when revisiting the output from each meeting.
Each retrospective meeting should have its participants learning something more about the project at hand, be it new efficiencies they can develop or even more ways to avoid commonly recurring problems that can hinder project development.
The “Speedboat”: An Agile Retrospective Tool
While we did mention that the agile retrospective meeting didn’t necessarily have a strict framework for you to follow, there are different templates you can borrow to help facilitate the discussion engagingly and effectively. One of these templates is known as the “Speedboat method”, which is an agile retrospective exercise that combines both visual elements and interactivity for the benefit of your participants.
Setting Up the Speedboat
To start a “Speedboat” retrospective exercise, you’ll need to have a proper space to begin collaborating with all the relevant stakeholders (some agile practitioners call this “Obeya”, meaning large room). Within this space, you’ll need to have a ready board for collaboration and enough materials such as papers, markers, and pens, that can allow your participants to be involved. Note that even those working online can utilize a digital collaboration space that will likely have similar tools that can help you host the exercise.
The meeting facilitator will then begin by drawing a sailboat on the waters. Don’t worry about the quality of the boat in particular as the design can be as simple as your facilitator can manage. The drawings will also need to contain visual representations of wind, anchors, and the sun, as well as a future “destination” island and some reefs in between the boat and the island.
As you may have figured, the sailboat is representative of the team proper, with the rest of the visual elements being factors in its ability to reach its end goal of the “island” which can represent any particular business objective. The wind and sun both represent actions the team made to push the project further and aspects of the project that the team liked. These different factors in a particular project can be tangible or intangible as long as they have a perceived effect on how your team experienced the project so far.
The anchor and reefs, on the other hand, represent obstacles both past and future. The anchors symbolize those different elements that slowed the team down or hampered their productivity, while reefs represent potential obstacles in the future that need to be identified to better “navigate” around.
The Exercise Proper
Now that you have the visual aspect set up, it’s time for your meeting participants to get engaged with the model. Firstly, you’ll want everyone to pitch in one key objective that the project is aligned with as well as any individual goals that a member feels warranted to be considered. These ideas can be written on sticky notes or any other appropriate medium in order to be placed on the “island” portion of the model.
Once you’re finished with this, repeat the same pitching-in process for all the remaining model elements on the board. Depending on the size of your meeting, you might want to limit concepts to around 5-10 different ideas per element focus. After this, the facilitator then ensures that each member is aware of the various ideas shared and posted on the board. This often overlooked step in the speedboat method is key to ensuring everyone is on the same page and aligned with each other’s perspectives regarding factors that affected the project. You can even explore grouping certain ideas to represent a specific functional role instead of an individual’s own perspectives to better accommodate particularly large groups in attendance.
After proper alignment with your stakeholders, it's key to begin voting on which items should be a priority for the company to handle in each different model focus. Limit your focus to roughly 3 to 4 different topics just to allow a holistic overview with different perspectives.
It’s only here that your team can begin brainstorming on possible next steps based on the priorities set by you and your team. Other tools can be useful here, such as the Rose-Thorn-Bud’s “Start, Stop, Continue” model. For example, those looking to maintain a particular benefit can note that proper monitoring is key, while others might need more hands-on management to tackle some of the more complicated issues that the project has faced and might face in the future.
In essence, you’ll want to ensure that you properly brainstorm, identify, and plan out your company or team’s next steps into an even better subsequent release. Through this exercise, you and your team can likely find some aspects that might not have jumped out at you at the time of the original release, but are now useful insights in gaining a practical competitive edge against market competitors.
.png)