The retrospective is an important Agile ceremony. It helps teams inspect the processes and work flows that are working for or against the team and identify any improvements that can be made. After coaching teams on these ceremonies and monitoring quite a few of them, I let the teams go on their own. Recently I checked back to see how the teams were doing and whether they were getting benefits out of the retrospectives or the Plan-Do-Check-Act cycle.

The teams were definitely working on delivering the user stories and making releases, so processes should have helped them. I pulled the last five to six sprint retrospectives to examine the data and to understand, sprint by sprint, what had been identified as areas for improvement. I saw a typical pattern of comments emerge. This surely was not a good sign. A ceremony is introduced to help the team close action items during that time. But the data was telling me a different story, in that the same issues were resurfacing after every other sprint. That is when I realized that the teams should have a Retrospective of Retrospectives.

After a quick data analysis, and having gathered the ScrumMasters (SMs) and teams in a room, we went over the patterns. We focused on what didn’t work well during the retrospectives. Were the SMs effective enough at efficiently removing repetitive impediments?

Below are some of the discussion points:

  • Teams are not looking at previous retrospectives.

  • SM is not tracking well on action points outside of the Application Life Cycle Management (ALM) systems.

    • A more effective way would have been to add user stories in the ALM tool for tracking purposes.

  • The retrospective simply became a mundane activity rather than a process enabler; the team was losing its motivation to discuss and work on action points.

  • Soft issues between team members were left to managers to handle rather than the team and SM to solve them.

  • Unclear user stories are still hanging around after eight to ten sprints. Possible reasons are inefficient backlog refinement meetings and not following the Definition of Ready (DoR) for pulling user stories in a sprint.

  • Points that were not yet addressed in the project were never escalated in the Scrum of Scrums by the team representative.

  • The team was not looking at planned versus actual variances during the sprint retrospective, which could have helped them improve further.

  • The team was not proactive enough to question the SM and other stakeholders on the status of action items.

  • Though they were following all Agile processes, the Agile mindset at the leadership level was not working in the team’s favor.

  • During sprints, team members were being shuffled to other teams based on workloads.

  • Technical debt was not addressed in a timely manner, leading to instability of the project.

After hearing these points, we identified and worked on the following action items:

  • Added user stories for each action point stemming from the retrospective meetings.

    • Prioritized them as part of the planning meeting, along with other functional user stories.

  • Team members and SM volunteered for these action points.

  • We involved managers and product owners (POs) in another meeting and explained the pain points the team was not able to handle (i.e., not in the team’s purview).

  • We sought their commitment to work on them.

  • With the PO’s support, we openly spoke on technical debt and reducing or removing it sprint by sprint.

  • Planned a Retrospective of Retrospectives (RoR) meeting after team’s regular retrospective meeting to discuss how remaining actions can be handled.

  • Created a big visible information radiator on the floor specifically for depicting the RoR status.

  • Tackled soft skill issues with the help of the manager and mentoring from HR teams.

  • Mandated that teams discuss effort deviations and collect input to improve on predictability of the teams.

  • Restricted team member movement and froze the team structures.

  • Instructed SM and team to diligently select user stories that satisfy the DoR.

    • Sprint teams did not have a sufficient number of user stories to develop based on the criteria, which sent a strong signal to the PO to improve the quality of user stories.

    After a few sprints, we could address major improvement areas, and we could see that the retrospective points were not being repeated over and over, as they had been previously.

    Sometimes just looking back at the data from a different angle helps teams see how they have been performing. And getting an Agile coach’s view always helps!


About Author

Alhad Akole
Zensar Technologies Ltd

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)


Posted by Alhad Akole

Leave a reply

Your email address will not be published. Required fields are marked *