Ask this question to Agile Team members. Around 80% will say ‘Yes, we are’ . Then ask second question – Are you doing retrospective after every Sprint? Now percentage will probably reduce to sixty. Now ask the last question – Are you tracking and implementing improvement actions identified from retrospectives? Consider yourself lucky if you get affirmation from 30% of the members. Because most of the Agile teams perform retrospectives but very few teams do it effectively; in the right spirit.
Retrospective is one of the most important and least appreciated practice in Scrum. It is important because it gives team chance to examine what’s happening, analyse the way they work, identify ways to improve and make plans to implement these improvements. It is least appreciated because some of us believe that it takes time away from real work – Design, Build, Test. So it is actually waste of time. But the reality is more than often poor retrospectives will result into Flat Velocity, low quality or both.
Let’s examine some of the common issues in Sprint Retrospectives.
Low attendance for Retrospectives
There can be several reasons for this. People are too busy in their work, they are allocated to multiple teams, team members are at remote locations, they have different time zones and they may see any value as nothing really changes after retrospective. Scrum Master should understand and analyse the reasons for low attendance. And if people don’t see any use of this event then it’s not a bad idea to allocate some time from next retrospective to elaborate the understanding of retrospectives.
Real issues are not discussed
Team members discuss all the issues in retrospective except the real burning one! No one is comfortable in bringing the real issue on table for discussion. May be the issue is sensitive or team is not sure about the reaction from management. Sometimes it is joint retrospective with client and the real issue is internal to the team Whatever may be the reason; such retrospectives will not benefit anyone.
Everyone does not speak
It is important that each and every team member should express his/her opinion in retrospective. More extrovert, aggressive communicators and senior team members often drive the entire retrospective. So the role of Scrum Master/ Facilitator is extremely important and should ensure everyone is getting equal opportunity.
Finger pointing session
Sometimes when sprints are not going well,people start playing the blame game. Facilitator should immediately stop this as soon as it occurs.
Objective of the retrospective is to improve the current processes. But unfortunately some people take this as an opportunity to complain about the way things are. As a result retrospective session degrades into complaint session.
Root cause of the problem is not identified
Team may end up in identifying causes such as insufficient unit testing or ineffective code reviews. These are not the root causes but symptoms of the problems. Actions taken on symptoms are more than often ineffective.
Actions are not tracked
This is very common pattern (Or anti pattern). Actions are not properly tracked and eventually not implemented.
These are some of the common issues I have observed in retrospective. Keep watchful eye on these issues and act on them immediately as they will prevent retrospective from being successful.
Now in next section let’s look at some of the best practices to make your retrospectives more fruitful
Get the most out of your retrospectives
Allocate 1 to 1.5 hours (Max) for retrospective. Anything more than this will be counterproductive. Remember you will be doing this meeting every two weeks.
Scrum Master should spend some time for retrospective preparation. As we want to keep retrospective timeboxed for 1 to 1.5 hours, all the objective data and facts should be ready before the meeting. If team is going to focus on topic which is currently important (for example how to make BDD more effective or Continuous integration practices), then it is important to gather all facts about the focused topic and communicate those to all the participants in advance. This will allow participants to spend some time on preparation before coming to discussion.
Scrum Master, Development team and Product Owner should participate in retrospective. Well, few eyebrows will be raised as I have included Product Owner. But Product Owner role is critical for achieving fast flow of Business value and his presence and inputs are important when team is discussing about the improving the flow of Business value.
Other stakeholders should not be present during retrospective unless absolutely required and invited by the team.
Don’t be too ambitious
Pick only one or two items which can be done better in next sprint. Prioritize you list of problems and address critical problems first. Less critical items can be addresses in next Sprint.
Set Ground rules
It is useful to set some ground rules at beginning. Objective is to make clear that the focus of the retrospective is improving system and processes and not the individuals. People should be able express their opinions freely but without blaming any individuals.
Make Sure everyone Speaks
This is extremely important. Retrospective will not be effective without active participation from everyone. So its good idea to ask simple questions to participants at the beginning, such as : How do you feel today? What it is your current energy level? How will you describe current sprint in 2-3 words?
If someone is still not engaged in discussion then Scrum Master should spend some time with the person after retrospective or during next iteration to understand reason and make person more comfortable in next meeting.
Work in your span of control
Work on the issues which team can address and not on how others can improve.
Identify and prioritize root cause
Use techniques like Five Why and Pareto charts to identify and then prioritize the root cause.
Add improvement items in Product Backlog
Simplest way to track improvement actions is to include those in Product Backlog. During next Sprint Planning session allocate some time for implementing these improvement actions.
Joint retrospectives with Client
Sometimes team cannot talk openly about all issues during joint retrospective meeting with Client. Though transparency is one of the pillars of Scrum, sometimes team cannot be transparent because of obvious practical reasons. In this case it is good idea to conduct short 30 minutes internal retrospective meeting before joint retrospective meeting with Client to discuss any internal issues. But the objective is to eliminate such type of internal meetings once the engagement with client is matured.
Some of you may have question on retrospective format. There are different formats available but I would recommend the most simple format suitable for most of the retrospectives. Simply put three sheets of paper or create three columns on paper labelled ‘What went well’, ‘What did not’ and ‘What can be done better’.
You will get few more ideas on conducting effective retrospectives Here
Initially retrospectives should be facilitated by Scrum Master but anyone from the team can facilitate the retrospective once team is comfortable with the process. Good idea is to rotate the facilitation responsibility. One can also choose different retrospective formats once process gets matured.
Effective retrospectives will result into improved productivity, improved capability, improved quality and increased capacity. Your teams will also feel more empowered and start enjoying their work more.
PS – Please don’t consider retrospective as the only time to do process improvement. Adhoc process improvements should happen throughout the Sprint. Retrospective is dedicated time for the team for continuous improvement but it is not the replacement of adhoc process improvement.