Teams not achieving the intended velocity. Missing deadlines and forecasts. We have all been there. As Scrum Master's, we have faced such issues and tried to understand the root cause. And the tool to understand underlying causes to the teams performance is a 'lessons-learned' or 'retrospective meeting' activity. In Waterfall process, PMBOK guide tells you to conduct this during the 'Closing' phase of the project. In Agile process, since iterations occur frequently, it is held after every iteration. However, even if we adhere to the prescription in letter, not maintaining it in spirit does not help us. How many times have we conducted the retrospective without having any impact whatsoever on our projects? In this article we will identify a template of retrospection based on a real life scenario which helped bring change in team morale, boosted productivity and ensured better metrics all round.
What is a Retrospective Meeting?
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" - Agile Manifesto
Case Study
I was handling a scrum team for a particular product line in late 2017. The team strength was 7. We had worked for 2 Sprints. However, the forecast had never been met. This was a project which was supposed to be a derived product line - hence, the velocity had been verified in the actual product line. The EPIC burndown forecast after 2 Sprints looked as below:
As can be seen, velocity has completely deteriorated. Sprints have failed miserably. Questions were being asked about the capability of the team in progress review meetings. Deadlines were questioned and team commitment was under scanner. What was going wrong? To understand this, 2 retrospective meeting had been arranged after the increments. The retrospective meetings were held as per mandate with actions which were cursory in nature arriving at a list of items under 3 broad headings:
What should start doing
What should we stop doing
What should we continue doing
However, no concrete action could be arrived at. Why do you think that happened?
The agile manifesto proposes that a "team reflects on how to become more effective". Agile mandates 2 ceremonies under the "Inspect and Adapt" process. First, is the Sprint Review. The second, is the Sprint Retrospective. Sprint Retrospectives are a great way for scrum teams to evolve and improve.
As part of the 'Check' item in 'PDCA Cycle', scrum teams use retrospective activities to focus and improve overall way of working (WoW). In general teams verify the actions prescribed in previous retrospective. They 'Inspect' the status of their activities and define what 'Adapt'ation is required in their WoW.
Who participates and when is it held? The scrum team participates along with a facilitator, who is mostly the Scrum Master. Note that the scrum team owns the retrospective. Along with the team and Scrum Master, Product Owner and any other stakeholder who is needed can be asked to participate in the meeting. It is generally held after the Sprint Review when ideas for improvement are easily available. However, it can be held at multiple points during the Sprint as and when needed. Please note that retrospectives should be handled at multiple levels for an organization to be completely effective. Also, for Scaled Agile variants, the 'I&A' cycle at the end of a Program Increment (PI) can be used for an organizational retrospective.
Why do we need to do retrospective? Retrospectives are meant to hold a mirror to the teams WoW. Please carefully note the difference. It is not the activities but the WoW that is of essence. It gives the team power to introspect and in most cases implement changes. In practical sense, they suggest those changes which require organizational support. However, they do hold a lot of power to modify the WoW as they feel is needed. The team goes through the actions committed previously, checks the efficacy, suggests changes and commits to them. This gives control back to the team and makes the Agile journey simpler and a more enabling one for them. As per the Scrum Guide the retrospective should be an “opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” The theme therefore, for retrospective is to be a placeholder for 'continuous improvement'.
The Process And Its Outcome
" There is a way to do it better. Find it "
- Thomas A Edison
To understand the goals of retrospective, let us first understand the difference between Review and Retrospective. Sprint Review is an activity which is carried out at the end of the Sprint in order to highlight the work DONE by the team. It is a ceremony during which all stakeholders can be invited to view demonstration of the increment of product environment and receive instant feedback. Scrum team run the spotlight on their work and get kudos for their work on negative feedback from stakeholders. Completed work, including partial ones where Sprints have failed, can be demonstrated.Sprint Retrospection is held after review. It allows the analysis of the work completed by the team which was demonstrated during review. Feedback received during review is discussed. Issues related to the team’s performance can be discussed in a free and fair manner without malice. This meeting need to be attended by all stakeholders.The goals for Sprint Retrospective is then to have a discussion about two different aspects:
The increment - the result of the increment demonstrated. Whether it met the specifications of DoD set by Product Owner? Were all working agreements regarding the increment met? Did the Sprint fail and if so what stories could still be demonstrated. Was the increment deriving the business values it set forth to? If not, what could be done better?
The process - what improvements can be brought about in the process? What was being done correctly ? What was incorrect? What modifications were needed.
Case Study continued..
The typical retrospective that was mandated would be held at the end of Sprint Review on the last Friday evening of the Sprint. Team would try to wrap up the retrospective as soon as possible. Most of the team would not participate and would remain mute to the conversation. the general discourse would revolve around the 3 mandated questions mentioned earlier. For most of the questions, team would start a blame session.
Typical conversation would be :
J: We should start having regular sanity test reports on our builds
S: That would mean more work for me as I would be undersigning these reports. I cannot do it.
J: We should mention it anyway as part of “What should we start”.
M: What is the purpose of adding it if there will not be any results. Management has never helped us out. I remember last Sprint, we had asked…...
As shown in the diagram, for two Sprints the team had followed the same retrospective and had the similar failure rates. The forecast for 3rd Sprint was even worse. No actionable item was forthcoming from the retrospective and the environment around the discussion was often vitiated. Participation was also minimal. The time had come for some improvements to be made to the retrospective.
Improvements
"Continuous Improvement is Better Than Delayed Perfection”
-Mark Twain
Case Study continued..
The improvements discussed below have been derived from the book - Agile Retrospectives by Esther Derby & Diana Larsen. As a facilitator I started with ensuring the following -
I made the team aware of the Prime Directive as stated by Norman Kerth - "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." This gives the team a sense of a safe environment where anything could be discussed without fear.
Based on guidelines from the Scrum Guide I kept the meeting timeboxed to 2 hours for a 3 week Sprint. This gave a sense of focus to the team and reduced chances of long discussions which kept the team from wandering in their thought process.
I ensured that all activities were physical ones with electronic items kept at bay. This ensured that team was always 'available' in the space and not drifting away. Members working with Pen on Paper tend to have more concentration on the task at hand than when they are using electronic devices.
Members were also informed of follow up activity which was planned based on inputs from the retrospective. I had planned a meeting with product management on coming Monday based on issues reported during retrospective meeting and follow up sessions on a weekly basis.
The team was informed about the timeboxes and the games for each stage. General working agreements were chalked out:
No personal attacks
Actionable items should only be discussed
Conflicts are good and whatever conflict unearthed needs to be handled within the meeting. No extension of the conflict should be impacting the individual collaboration outside the meeting
The five stages
Setting the Stage - (Activity - ESVP)
The team was seated in a semicircle facing each other. Obstructions such as tables, movable desks etc, were removed. Product Owner was also requested to participate as insights from Product Management would also be valuable.The activity which was chosen was ESVP. The reason behind choosing this activity was to understand whether any participant was reluctant to participate and if so, why? The time box given for this activity was 15 min. During this activity, individuals could identify themselves belonging to a particular identity - Explorer, Shopper, Vacationer or Prisoner. Further details of this can be found in Section 4.3 of Agile Retrospectives by Esther Derby & Diana Larsen. None of the participants identified themselves as Prisoners, however, 2 identified as Vacationers. This showed clearly that there was interest in the team to participate in the retrospective even if not actively supporting. I decided to have a show of hands at the Close of the meeting to see if there were any changes in attitude among the participants.
Gather Data - (Activity - Mad,Sad,Glad)
The reason behind choosing this activity was that it gave ample opportunity for the team to celebrate their achievements. The time box for the meeting was set at 30 min. I asked the team to identify events which were associated with a specific emotion during the length of the Sprint. Mad were those events which they felt were had no place during the Sprint execution. Sad were those events which had a negative emotion attached to it. And Glad were those events which were marked with positive emotions. These events could be personal or professional. The events were written on postscripts and stuck onto flip charts. After the expiry of time box, all members went through each of the items and tried to understand a bit more about them. We bunched together those which were similar in nature. This gave us quite a few items for our next stage. Their were small hiccups as follows:
One member informed that he did not have any comments specific to this Sprint. I encouraged him to write about items in general about the project.
Some other members were worried that individuals would be identified as problem makers. I informed them that the environment was completely secure. Moreover, all postscripts were of same colour scheme and anonymous hence, no individual could be identified.
Whenever any item appeared which blamed any individual, as per working agreement, the item was rejected.
The non-believers were converted by the end of this activity. I could clearly see that those who were skeptical about the efficacy of the meeting, were also completely involved in the activities. I also ensured that every member had at least one representation on the board. This ensured that every member’s voice was at least represented once. It helped in opening people up for the next stages. The outcome of this stage was a set of issues which were taken as input for our next stage.
Gather Insights - (Activity - 5 Whys)
The reason behind choosing this activity was that it gives the ability to discuss an issue in-depth in a very short period of time. The time box for this meeting was 40 min as we were doing this activity for the first time and hence, needed time to collect our thoughts. Since there were 8 of us in total, we setup 2 teams of 4 each and divided the issues identified in previous stage in roughly half for use of each group. Following a Round Robin manner, each member of the group asked the next member 5 consecutive questions starting with 'Why’ regarding the topic at hand.
E.g, S: Why was dependability of members not guaranteed?
R: Because team members were not committed
S: Why were they not committed?
R: Because team motivation was low
S: Why was the motivation deemed low after previous Sprint review?
R: Because there was no commendation from MT members in the demo
S: Why was there no commendation?
R: Because MT members were only looking for failures and not for success
As can be seen from above discussion, in general after 4th or 5th 'Why' the core issue was found out. These were noted down. After 30 min I asked the activity to be concluded. For the next 10 min, we discussed and debriefed about what we had found and tried to collate the findings into similar themes. By this stage everyone was already committed to the activities. Since, the discussions were held in a Round Robin manner, everyone participated and I found their participation to be wholehearted. They believed that through this activity they could bring about change as they were at last finding out the core issues inhibiting the team from acting positively.
Decide What To Do (Activity - SMART Goals)
This activity was chosen as it allowed team to derive Specific, Measurable, Attainable, Relevant and Timely goals from the outputs of previous stage. The time box was set for 20 min for this activity. The team was asked to identify SMART goals around the themes we had found earlier. They were then asked for small, specific tasks to be created to meet the goal. They were also asked to create measurable criteria around the tasks and timeline along with specific action holders. The tasks were not only meant for team members, but for other stakeholders as well. I had already setup meetings over the coming week with other stakeholders in order to discuss these actions and help monitor them.The team was extremely enthused by the end of this stage and almost all members took initiatives for most tasks. Some tasks were immediately added to the Product Backlog as Product Owner was already available in the meeting and discussions were straightforward. It was decided that other tasks would be taken up based on the outcome of the activities of the team members during the intervening time frame. The output was taken as a live document which was to be revisited on every retrospective so that the progress could be visualized.
Closing the retrospective (Activity - Appreciation)
This activity was chosen as I wanted to end on a high. I asked every team member to take a min and then say an appreciative comment about any other team member or stakeholder who might not even be present. The time box for this activity was 10 min. It actually helped in members genuinely appreciating each others efforts and people believing in the positive energy of the team.
The best outcome though was after the retrospective got over. Over the next day or so, visible changes were seen within the team. People started helping each other more effectively and generously. They started bonding as a tribe. And they also started disseminating some of the knowledge to other Scrum teams who had not done similar retrospectives. This gradually started changing the culture of the teams.
Improvement in retrospective can be done using multiple set of activities. I have shown usage of one of them above. Any other mechanism can be used effectively as well. The efficacy of this activity is dependent on the facilitation and expectations. Remember to always ensure a setup which is fair to one and all and where everyone is encouraged to voice their opinion without fear. It is a continuous improvement activity which will gradually help introduce a new culture in the team and raise its level of productivity if done correctly. However, please ensure that while conducting these activities, the ethos of the organization is always kept in mind. Cultural change takes place gradually and cannot be enforced.
Conclusion
Sprint Retrospective is one of the most important ceremonies held under Agile processes. If run correctly, it allows a team not only room for improvement but to bring about a culture of collaboration and road to success. The above template shows how I was able to help one of the scrum teams I was working with. Any alternate set of activities can be used just as efficiently if correctly implemented. However, the takeaways are the crucial nuggets of information which I derived from my experience, which can help out others who might be in a similar position as I was in.
Update - The German version of this blog has been published in t2informatik: https://t2informatik.de/blog/softwareentwicklung/how-to-rock-your-sprint-retrospective/
About Me : A passionate Agile leader having 16+ years of experience in software industry, I have handled Agile projects of various complexities. Having successfully handled Agile transition for multiple organizations, I write about my experiences, challenges and some solutions.