The Importance of Retrospective Meetings in Agile
The Retrospective Meeting (or ceremony) is typically associated with Scrum and is one of the five Scrum events. The purpose of this Retrospective within Scrum is to inspect the prior Sprint and examine how well things went and identify those areas that could use some improvement. Many Scrum teams will take this as an opportunity to work on improving their actual development processes or focus on improving their own skills.
The 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 potential improvements; and,
- Create a plan for implementing improvements to the way the Scrum Team does its work.
– The Scrum Guide, Sutherland, J. & Schwaber, K.
While the Retrospective name may be associated with Scrum, all Agile approaches should carry out a formal process similar to a Retrospective. A means for handling the continuous improvement processes is vital to a successful Agile implementation, and many Agile frameworks do identify activities identical to the Scrum Retrospective.
Agile just isn’t very Agile without a focus and drive to improve. In fact, that commitment to improvement is so important, one could say you aren’t even practicing Agile without it. If your chosen Agile variant doesn’t define Retrospective activities, or you believe those activities are a waste of time, you should consider the below reasons for adding those Retrospective activities to your Agile instance.
Retrospectives Promote Adaptability
A core component, arguably an extremely vital part of Agile, is this idea that a team and an organization need to be adaptable. To be Agile, you need to be able to adapt. To adapt, you need to learn. And to learn, you need to inspect.
Part of adaptability is making sure that you work on improving those elements that aren’t functioning as effectively as they could be. But before you can adapt, you need to learn what you are adapting to. This is where the Retrospective comes in.
A Retrospective is an opportunity for the team to collaborate and learn together what may not be functioning effectively. It serves as a means to identify issues that could possibly be hindering the team’s progress or development efforts. During a Retrospective, the team discusses those areas where they encountered problems, and they may even make some initial plans for how to go about eliminating those problem areas. If you don’t have a formal method for identifying these issues, the continuous improvement process can be impeded, and that limits the team’s ability to adapt to current and future problems that may encounter.
A Retrospective Encourages Discussion and Collaboration
In Scrum, the Retrospective event must occur at the end of each Sprint and the whole team must participate. The benefit of this is the consistency of a Retrospective occurring at regular set intervals of time, making it easier for team members to plan around.
You won’t get a whole lot of disagreement from me regarding the somewhat dogmatic nature of Scrum, but when it comes to continuous improvement, Scrum has it right to focus on the consistent and collaborative approach to the Retrospective. There is a need for that regular and structured process. Scrum might require it at the end of a Sprint, but it can ultimately be held whenever it works best for the team as long as it maintains a set day and time to promote team involvement.
What often occurs in teams that do not adhere to a formal and regular collaborative process, like a Retrospective, is that continuous improvement becomes an afterthought. The entire continuous improvement process becomes something they do in their spare time, but then they rarely get any spare time to devote to it. It is less of a focus for the team, and as a result, it effectively kills most improvement efforts within the team.
Retrospectives Help Create A Culture of Improvement
In a properly conducted Retrospective meeting, each member of the team will need to come up with their own items to discuss. They should prepare to do so in advance and present things that worked well during the Sprint and things that could be improved upon in future iterations.
It has been my experience that when a teammate says that nothing can be improved, they usually didn’t prepare in advance. Comments of ‘nothing’ are never acceptable and should be discouraged at a Retrospective because you can always find something that ‘went well’ or ‘not so well’ if you carry out the inspection of your working process. By default, if it didn’t ‘go well,’ then it falls into the ‘not so well’ category.
A regularly occurring Retrospective that focuses on gaining everyone’s input helps to reinforce the organization’s dedication to continuous improvement. When teammates know in advance that they will need to discuss something at a meeting, it is more likely to pop into their mind if they see something that isn’t going as well as it should be and they will be able to bring it up at the next Retrospective.
It also usually works out better when continuous improvement efforts are standard within the development process. It can be built-in to the development process and become part of the organization’s culture to help reinforce the importance of working to improve. This ensures that the team is focused on figuring out ways they can do things better as they learn more.
Retrospectives Reduce Risk
In addition to occurring at regular set intervals of time, Retrospectives should also happen frequently. Scrum may have Sprints of a month, but that can be too long in between Retrospectives. Ideally, Retrospectives should occur no more than two-weeks apart to help ensure they remain in focus for the team and progress towards improvement occurs.
Often you will find that a risk isn’t even known by a team until they sit down to talk during a Retrospective. The act of collaborating with a focus on spotting issues can be a trigger for members of the team, and that trigger can lead to a greater understanding of potential risks.
Making the Retrospectives occur more frequently can aide the team with better risk identification and tracking of those risks. Additionally, If a team member spots a potential threat or opportunity, it can be addressed by the whole group almost as soon as it is detected with the use of frequently (and regularly) occurring Retrospectives.
Conclusion
Retrospectives help to make Agile adaptable, promote and encourage discussion, enhance the culture of improvement, and they can reduce risks to the project or product. Retrospectives can be crucial to the successful Agile project for far more reasons than listed here, but these are some of the most critical areas a team needs to address during a complex Agile project.
Most people who work in Scrum do not need to be told of the importance of a Retrospective meeting. Many Non-Scrum Agile teams have even adopted the Retrospective, or they recognize the importance of similar activities identified within their chosen Agile framework.
But there are Agile teams out there that don’t practice it because they believe it wastes time and isn’t worth doing. I have been on those teams before, and they have almost no way of addressing or correcting issues that the group finds, assuming they even care about trying to improve at all. This creates a team of people who begin ignoring possibly easy to fix issues. Poorly working tools become accepted as they are, and slow-moving processes are just dealt with; even when they delay the iteration.
Sources
Sutherland, J. & Schwaber, K. (2012-2018) The Scrum Guide. Retrieved from https://www.scrumguides.org/scrum-guide.html