Sprint Retrospective – A way to become more effective with Scrum

Did you ever feel that your team is not learning from their past mistakes and repeating them again and again? Being a scrum master, are you expecting your team to be self-organizing and work collaboratively?  Then you might have heard “Sprint Retrospective” which is quite popular among agile development teams.

Whether as an individual or together as a team, there is always some scope for improvement. Since the core principle of the “Agile development ” is continuous improvement, and the agile team always sets aside a brief period to retrospect on how they are working, to find out the pitfalls and better ways to improve.

Well, if one is new to what a sprint is, it is a timeboxed iteration of one month or less during which a potentially shippable product increment is created. After each sprint, usually the following three sprint meetings are conducted in the sequence.

The retrospective is one of the crucial scrum ceremonies conducted after every sprint to analyze the pitfalls and best practices followed during the last sprint and list out the actions that have to be taken to improve the effectiveness of the team and increase the quality of the product. 

More often than not, many people and teams treat retrospective as the non-essential scrum event as usually nothing from the retrospective displayed on the sprint or kanban board, as a result, the scrum teams do not use it to their full advantage.

According to the scrum guide, “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints.

The formal structure of the retrospective:  Usually team discusses and addresses the following four questions with the help of scrum master.

Why teams usually consider retrospective as a monotonous activity?

Most often, many team members consider Retrospective as a boring meeting, and in most cases; the following are the main reasons for such an assumption.

• The structure of the meeting: scrum master requests each team member to voice their opinion based on the four key questions mentioned above. This approach may not always lead to a healthy discussion among the team members, and few members may be reluctant to express their ideas as the focus of the whole team lies on a single member. Instead, if the question is put to the whole team and encourage for the healthy discussion, may yield better results. Overall, it is the scrum master’s responsibility to synthesize a suitable meeting structure based on team feedback.
• List the retro items on the sprint board: Without proper monitoring, the resultant ideas of the retrospective will not turn into actions.  Instead of listing retro improvement items on a separate board like Trello, it is advisable to place the important items part of the next sprint goal. So that they can be monitored regularly along with other sprint items and teams can imbibe them eventually.
• After gaining enough experience, the scrum teams think that they are too good for retrospectives and they do not have any pitfalls to identify. This assumption will never ever be true as knowledge is always limited and as a team, there is always some scope for improvement.
• Continuous long sequence of meetings:  All three sprint meetings are continuously conducted, which may appear monotonous.  It is the scrum master’s responsibility to sense the team members’ feelings and use various strategies to keep Retrospective fun and engaging.

Example:

• Retrospective can be pulled out of this sequence and conducted in informal mode during a T-break.
• Give the opportunity to someone else to conduct the meeting.
• Employ a team bonding activity to boost the team’s energy before going to the core of the retrospective.

An example tripple ‘I’ questionnaire based mind-map to guide the Retrospective meeting pattern.

Why Retrospective be conducted for each sprint?

There are a bunch of benefits of running a sprint retrospective.

• Scrum is all about sustainable development and the team should be able to maintain a constant pace indefinitely. Without proper retrospective, no team will be able to achieve this.
• The three pillars of empiricism are transparency, inspection, and adaptation. They are guiding forces for the retrospective meeting to make progress and help the Development Team improve how they deliver projects.
•  In Scrum, an empirical process is implemented where progress is based on observation and experimentation instead of blindly following processes or theory defined upfront. By not having a productive Retrospective meeting,  the team misses an opportunity to be empirical.
• The main purpose of the frequent delivery model in scrum is to identify the bottlenecks and resolve conflict areas at an early stage, and with retrospectives, agile teams can continuously improve the processes by evaluating each sprint.
• Scrum does not define any hierarchical authority model within the team. Retrospective enables the right environment to  Each member to express his/her concerns, ideas, opinions and make them feel heard and their inputs are valued.

Difference between Sprint Review and Retrospective: 

The Sprint Review is like a user acceptance test for every item which met the definition of done and focuses on the product and maximizing the business value of the results of the previous sprint work. Here the team member demonstrates the work finished during the sprint to the stakeholders and get the feedback on purely functional and technical terms. Team members may also review the unfinished tasks and determine the reasons for not meeting the definition of done.

A Sprint Retrospective is a sprint post-mortem focused on the process and continuous process improvement. Its main purpose is to reflect on what went well, and what didn’t go well of the past sprint and find out how it can be improved in the next sprint.

Conclusion

Scrum advocates that we ought to experiment and learn during the projects. The sprint retrospective is undoubtedly the best platform to identify, discuss, and ultimately implement these learnings. Last but not the least, innovate different approaches to make the retrospectives fun and enjoyable.