Who should and should not be included in a sprint retrospective

A lot of things can go wrong in software development and even if the Scrum team had a good sprint, there are always a lot of opportunities to improve. The team should set aside a brief period at the end of each sprint to discuss how they did, inspect the performance of each team member and plan for improvements for the next sprint. This meeting is the sprint retrospective.

Project Management Methodologies

Essentially, a project management methodology is a set of principles for managing a project. The methodology chosen will have a profound impact on how a certain project develops as it defines how each team member works and communicates.

There are tons of project management methodologies. Some have been around for decades such as the Waterfall which is considered to one of the oldest methodologies still practiced today. It was outlined by Dr. Winston Royce in 1970 as a response to managing the increasingly complex nature of software development. Some are fairly recent, such as the Agile which formally came into being in 2001 at the release of the “Agile Manifesto”.

The Agile project management methodology was designed to be flexible and iterative. Agile projects are a series of tasks that are conceived, performed and adjusted as the situation demands, rather than have them go through a pre-planned process. This methodology is great to use in the dynamic environment of software development where there’s a lot potential for changing or evolving requirements. But because it’s just a set of principles, Agile is not considered to be a methodology on its own. The project team still has to define a structured process for delivering projects.

This is where the Scrum framework comes in.

The Scrum Framework

“Scrum” and “Agile” are often used interchangeably, however, the two concepts are not the same. Agile is the defined set of principles, while Scrum is a specific framework of action in line with Agile’s principles. The best analogy to define the difference between the two is to inspect the relation of a diet and a recipe. A diet prescribes what is okay to eat or not okay eat and the recipe is the framework used to apply the said principles of a diet. In this example, Agile is the diet whereas Scrum is one of the recipes.

In Scrum, work is divided into sprints which is defined by the Scrum Guide as “a time-box of one month or less during which a useable and potentially releasable product is created”. Once a sprint begins, its duration is fixed and cannot be shortened or lengthened.

Each sprint is consists of the following events: Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

The Sprint Retrospective

The sprint retrospective is the last thing done in a sprint and is the time when the whole team comes together and discusses the team’s performance. The meeting should be a safe place where team members can share their feedback on what aspects of the product development can be improved and have a discussion on how to implement positive changes in the next sprint. Makes sense, especially since the focus of the agile methodology is continuous improvement.

If run well, a sprint retrospective can help the project team identify areas for improvement for individual roles as well as have conversations around how to work better as a team. If run poorly, the meeting can turn into a bashing session which ultimately results to missed opportunities for growth.

Collaboration: The Essence of a Good Spring Retrospective

Let’s face it, not all teams are collocated. Today, many software development teams are virtual organizations. Good thing there are tons of online tools and platforms to facilitate sprint retrospectives for distributed teams. One good example is Fun Retro, which allows teams collaborate remotely. This is an effective tool which have been used by thousands of teams to improve their retrospectives.

The Sprint Retrospective Attendees

Because the spring retrospective is the time to reflect on the project’s development process, the full Scrum team needs to attend. This includes the Scrum Master, Product Owner, and the development team.

• Scrum Master - The Scrum Master is the facilitator of the team, the person is responsible for promoting and supporting by helping everyone understand Scrum theory, practices, rules, and values.

• Product Owner - The product owner is the leader responsible for maximizing the value of the products created by a scrum development team.

• Development Team - Everyone who is designing, building, and testing the product.

The Scrum Master should always be in attendance during spring retrospectives because he or she is an integral part of the whole process. This person serves as the coach of the Scrum team and points out where the team is not adhering to its rules and values.

There is an existing debate as to whether or not the product owner should attend sprint retrospectives. Some think that his or her presence is vital but on the other hand, some feel that the product owner’s presence defeats the main purpose of retrospective meetings which is to provide a safe and open place for feedback discussions because it might inhibit the team from being completely honest or revealing difficult issues.

However, the Scrum Guide defines the Sprint Retrospective as “an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint”. This means that the event is meant for the Scrum Team as a whole: Development Team, Scrum Master and Product Owner. There is no way that the Scrum team will reach its full potential if only the developers discuss which areas they should improve on.

If the product owner is not considered to be a part of the team, then this is an issue that needs to be overcome; in fact, it is a good topic to be discussed in the retrospective. If you and your team are tempted to hold a sprint retrospective without your product owner, think about why and have a discussion about it. The Scrum team and the product owner needs to have complete trust. This is the only way that the team can perform on its maximum capacity.

Who Shouldn’t Be Attending the Sprint Retrospective

The meeting should be a “safe place” where the Scrum team discusses their recent sprint and the improvements they are going to implement on the next one. According to The Disciplined Agile Framework, the “safe place” is affected by the presence of people with positional authority, potential agendas or other implicit impact. Having outsiders as guests at the retrospective will definitely change the dynamics. However, it is the decision of the team if they will allow outsiders in their sprint retrospectives.

Tips for Product Owners in a Sprint Retrospective

• Be part of the Scrum Team

As stated above, there are instances where product owners are not invited in the sprint retrospective. If you are a product owner and you’re not being invited to the meetings, discuss this issue with the team first. If you are deliberately not attending the meetings, you are wasting opportunities to strengthen your relationship with them.

• Take part in the discussions

If you are already attending the meeting, make sure to take part in the discussions in the improvement of the team’s work. If you have any concerns, say it in a constructive way. Don’t attend just to tell everybody what to do.

Tips for guiding a Sprint Retrospective

• Start, stop continue

Start, Stop, Continue is an action-oriented retrospective technique that encourages participants to come up with practical ideas for team-based improvement. This method is very action-oriented. Instead of asking team members how they feel, they are directed to discuss behaviors they want to start, stop and continue for the betterment of the entire team.

• Measure results

In order for the meetings to serve their purpose, there needs to be a measuring of results. The Scrum Master should be the eyes and ears of the team once the meetings are over and analyze if the whole team is implementing the changes they talked about in the retrospective.

• Talk about what went well

Most teams only discuss the negative issues during sprint retrospectives but it’s important to talk about the good stuff as well. Dwelling too much on the negative can decrease team morale. “If your retrospective is an hour long and the whole hour is about what went wrong, no one is going to eagerly participate in them going forward.” - Marco Corona for Agile Connection