If Sprint Retrospective Meetings are so Helpful, Why Isn't Everyone Having Them?

A sprint retrospective meeting offers the scrum team a chance to review itself through reflective analysis. The scrum team reviews its overall operations to gauge if the sprint is performing as required. During the meeting, issues discussed primarily includes:

• The average performance of the sprint
• Which aspects of the sprint need improvement?
• What should be the focus of the sprint?
• Evaluation of the past working cycle
• What are the recommendations for the future working cycle?
• Gathering team members feedback on what was a success or failure.
• Which skills made the sprint a success?
• What was the role of the team members?
• What strategies led to the success or failure of the project?
• How do we approach the next sprint?

Despite the sprint retrospective meetings being so useful, most development teams are reluctant to adopt them. The myths and rumors surrounding the meetings make most scrum members unwilling to embrace them enthusiastically.  

Some of the prevalent myths that drive the teams to abandon the scrum retro meetings include:

1. Retrospective Meetings are Dull

Most people have wrongly branded the retrospective meetings as repetitive, useless, and consume too much time.  You probably find the aspect of talking about the same thing over and over quite monotonous and frustrating.

But according to my experience, you are not doing things right. The turn of events can be reversed, and it's quite possible to have an interesting and engaging moment (or two). The retro meeting needs to have a well-defined structure and a more vivid focus for it to be interesting.

Of course, you can always use:

• Games and ideas to make retrospectives fun 
• Fresh retrospective ideas to achieve a fun retro meeting, or 
• 5 creative sprint retrospective ideas to spice it up  
  

2. Only the Product Owner (PO) Organizes and Discusses Various Issues in the Meeting

The PO's main job is to define the specific team backlog and maximize the value of the particular product from the development team.  Letting the PO organize and control the entire meeting significantly compromises the effectiveness of the retro meetings.

Team members should be proactive in airing their opinions concerning the sprint. The PO should not dictate the whole meetings or forcefully incorporate strategies.  The facilitators and PO should only contribute a certain percentage of action evaluation or implementation yet is encouraged to find other ways of making scrum retrospectives fun and productive

3. Retrospective Meetings are Opportunities to Identify Poorly Working Team Members

Most scrum team members dread the retrospective meetings as they view it as an opportunity for their seniors to review their work performance.  The thought of being condemned because of your performance standards is quite infuriating.

However, it is important to debunk that myth. The retro meetings are not a blame game opportunity; the meetings' primary aim is not to humiliate team members for their allegedly weak points. Conversely, it is a neutral meeting to strategize improvement tactics and consequently grow as a team.

An agile project development team avoids intentionally pointing fingers at a specific team member. Additionally, the focus of the meetings is overall team development rather than individual perfection or imperfection.

We’ve actually interviewed 6 engineers on running blameless retrospectives; below are just a few of the gems they shared:

The goal of "blamelessness," at least as I understand it, is to induce honesty and impartiality in devising and assessing solutions to problems. - Andrew Lim, Data Scientist at Amperity

The goal here isn’t to “fall on the sword.” It’s actually to defang and plan for failure. We all make mistakes, and that’s critical to acknowledge. The focus should be on how we build systems and processes that are resilient to human error.  - Jake Shorty, Sr. Software Engineer at GitHub

The key to running a blameless retrospective is creating an environment of trust. If trust isn’t there, you can introduce whatever processes you want – but team members will still worry about repercussions and look for ways to cover their asses.  - Sam Dallas

I really like the notion of going hard on process and soft on people. It assumes good intent from all parties and steers folks more to problem-solving than trying to focus too much on who did something wrong/why they did it. - Martin Gordon, Tech Lead at Amperity 

4. Meetings Consume too Much Time.

The reflective scrum sessions are things that make the team members panic. The thought of spending many hours brainstorming in meetings with the PO and higher management can raise concerns for the team.

The truth is the rumors are unfounded; in a real case scenario, with proper planning, the meetings take less than three hours. It is possible to structure the sessions in a fun and engaging manner, which avoids redundancy and a boring environment.

The reflective sessions should be quick, efficient, and enhance a clear understanding of the team members. Prioritizing the subject of discussion reduces the time spent on the meetings.

5. The Retrospective Meetings are Meant for Managers

The meetings are not entirely established for managers. They can opt to be present or absent during the sessions depending on their involvement in the project development.

Remember, team members, are actively involved in the product formulation and implementation. Thus blocking them during the meeting, and only consulting managers is not reasonable and is often impractical. Every team member needs to be actively involved, and all blockers must be eliminated.

The main goal of the meetings is to solve problems concerning the sprint. Team members should work diligently and transparently in the identification of impediments. Having daily meetings is crucial to ensure accurate monitoring of the progress of product development.

6. Documentation is not necessary.

Viewing the retro meetings as an informal way to express your opinions regarding the sprint is the wrong approach. Documentation is necessary for future referencing of suggested action points.  The inclusion of the documentation in repositories is intrinsic for future learning and evaluation.

Essentially, there is no predefined method of documenting the retrospective meetings. But you can incorporate some effective tips to ensure a seamless process of recording the opinions:

• Members documenting before the meeting ensures that important points are not left out during the session. Team members can spend ample time articulating their issues on the paper or electronic tool before the meeting.
• Documenting during the meeting allows a seamless interaction when team members are giving out their views. You can strategize a timebox for each member to give their opinion regarding their opinions towards the sprint while the meeting is in session.

7. Retrospective Meetings are Expensive

Retrospective meetings provide a unified platform for team members to celebrate successes and discuss major failures. A discussion about what improvements need in the upcoming sprint is discussed.

In my opinion, the value of the reflective sessions is higher than the resources and time dedicated to the meetings. Establishing a business culture that seeks better results in software and process development is crucial.  The regular process adds worth to project development.

Take Advantage of Free Retrospective Tools

Retrospective meetings are inappropriately branded as being too costly to implement in an organization. However, you can take advantage of the completely free retrospective tool available with GoRetro: seamless, simple, fun retro, colorful, and productive, with unlimited boards and for unlimited team members. 

Additionally, the different retro formats offer a defined structure (and variety) for seamless meetings, enabling better organization and tracking of actions.