One of the great, decades-long, contradictions in the world is the saying that ‘insanity is doing the same things over and over again while expecting different results.’ Yet, in business, repetition is often considered the key driver to success.
These two mean different things when applied in various situations, yet their co-existence is one of opposing sides. While there is an inherent comfort in pursuing a well-known strategy or plan, one cannot risk repeating the same process while expecting the results to be different, especially if lessons aren’t learned or go ignored.
At the same time, it’s disingenuous to disregard repetition as a driver of success totally. Repetition or consistency is of paramount importance. The more you perform a task, ostensibly you get better at it.
So how do you reconcile these two opposing ideas?
The key is determining what lessons to learn from repeating a process and identifying things that don’t work to be stopped or paused. It requires honesty and a willingness to be upfront with what went wrong, and the solutions needed to right the ship.
One effective way to do this is to employ the retrospective; an important bookend to any Sprint cycle.
Many organisations apply some element of the retrospective but those that don’t work in the agile way may not fully understand the importance of a retrospective and how to conduct it in a structured and consistent manner to reap its many benefits.
In this article, we’ll discuss how to conduct a retrospective (commonly referred to as retro), the pillars to put in place, expectations and finally, why this is one of the most important parts of the Sprint cycle.
What is the retro?
If you’ve confused the sprint retro with the review, note that the retro is a timeboxed meeting that comes after the review and before the sprint planning. The review is an opportunity to gather stakeholders and market feedback on the work done by allowing stakeholders to get a feel of the increment or the Minimum Viable Product (MVP).
The retro is a genuine reflection of the work done in the Sprint, by the team, barring any interference or involvement from stakeholders. It is an examination of how well the Sprint went with regards to people, relationships, tools, and processes.
Basically, the review is about the outcome while the retro focusses on the processes and team collaboration.
The retro is a safe zone for the developers or the scrum team to be upfront and honest about challenges, issues, and anything else associated with the Sprint cycle.
In some retros, it might even be normal for the team to want to discuss issues regarding workload and how to cope.
The retro isn’t meant to be a session for the team to criticize people inside or outside of the team, however. A certain level of professionalism is expected.
How to retro?
Scrum.org lists the three pillars as:
- What went well
- What could be improved
- What we will commit to improve in the next Sprint
Some teams may adjust it a little to suit their preferences or simplify it based on their needs, for example:
- Start
- Stop
- Continue
Not wholly different, but it informs the type of conversation to follow. There are other variations out there but the takeaway here is to remember that these three pillars are your foundation. If you’re new to it, stick with the basics.
The conventional way to conduct the retro is basically a round robin. Depending on the size of the team, the timebox allocated to each member to speak uninterrupted will differ. After they’re done offering their thoughts and opinions on the three pillars, the next person goes and so on until all are done.
The information is noted by either the scrum master or product owner (both of whom are encouraged to participate) and used in conjunction with the team velocity to better formulate a way to improve for the next Sprint.
The expectation after the end of the retro is for the team to be more aware of the challenges and thought process of each other as well as having a clearer idea of how to optimise the next sprint for the better.
Why is the retro important?
It’s not that companies and team members aren’t interested in evaluating the work, workload, and the manner at which it was done, on the contrary, they are. It is a useful and important aspect of any work. Learning from failure is important to success.
The problem is the existing systems and traditional workplace processes either don’t allow time for such things to happen, or they do but fail to understand its importance and therefore do not incorporate it in the way where it will be beneficial.
This either means it happens haphazardly without a consistent schedule or the process is diluted by stakeholders being invited and the entire session used to review performance and/or devolve into finger-pointing.
For many people, the retro is often the best part of the Sprint cycle. It is the opportunity to share learnings, observations as well as highlight issues and personal challenges with the understanding that not only is this judgement-free, but there is an actual positive way forward.
And in recent years, with the COVID-19 pandemic forcing companies to adopt a work-from-home or hybrid model, the retro could also serve a slightly different purpose.
As people become more prone to silos and experiencing degrees of alienation while working from home, the mental toll it takes on an individual’s psyche can be brutal.
It’s common now for people to suffer cabin fever or struggle through long bouts of anxiety and stress which can lead to an inability to self-motivate, while attempting to remain focused on tasks as they bounce from one Zoom/Teams meeting to another.
While this is not the retro’s purpose, it can be used, toward the end of the session to check up on one another and help each other through this physical separation and mental stress.
Such things are dangerous slopes and failing a professional therapist to talk to, developing this sense of comradery and affinity for what each other feels can go a long way toward keeping the team together and motivated enough to tackle the next sprint cycle. There is unity in adversity after all and people are wired to want to form strong connections with like-minded individuals.
As Agile is about putting people at the forefront, the retro is a great way to check in and develop a strong understanding with one other as you nurture a people-first organisation.
In closing
Rather than repeat the same mistakes without applying learnings and hoping for different results, the retro enables the entire team to see the errors and human lapses of judgement, evaluate them, and make a concentrated effort to resolve them, without necessarily changing the entire process.
It is part of the iterative nature of the Agile way of working with numerous benefits (both seen and in the case of providing a therapeutic avenue, unseen) to the morale, productivity, and trajectory of the team.
The retro isn’t a process to be implemented for its own sake. Its primary purpose is to identify key learnings, that are then implemented at the beginning of the next sprint to ensure continuous improvement. It is a happy result that it has many secondary benefits as well.
As such, we don’t recommend implementing a retro without undergoing a full Agile transformation.
However, if there is one quick way to extoll the value that Agile can bring to your organisation, a structured session in which a retro is carried out after which learned lessons are implemented for the next task, might be a softer approach to convincing stakeholders resistant to an agile transformation of its value to the business and company.
Have a question?
If you'd like to know how we can help you become an agile organisation or even find out what being an agile organisation means, don't hestitate to reach out to us. Drop us a message.