The Pull of the Retro

The Retrospective is perhaps the most challenging part of the Scrum process for a ScrumMaster. Although there are several ways to run a retro, the basic idea is very simple. You want to find out what went well and what could be improved, to gather information that will help you to improve the team's performance. The Retro essentially gives the ScrumMaster ‘material’ to work with; as the change agent, you need to know what the team wants to have changed. Engaging in discussions with the team to understand what the problems are and how they can be addressed are key parts of the process.

Getting a ‘feel’ for the team

For me, the Retro is primarily a barometer for a team’s mood. You can focus your attention on the tone in which the team members speak, how they express their opinions and what the contents are. Their openness and engagement are what you want to see, but maybe you realize that they are holding back a bit. In that case, the team members might lack a clear understanding of the main point of the Retro; or they might not feel comfortable enough to speak out and raise difficult (and potentially controversial) issues. Consequently, you have to ask yourself: What is preventing the team from being open, and therefore fulfilling the purpose of the meeting? What is required to give them more confidence?One of my teams had already gone through several Retro cycles. Nevertheless, there was this feeling that we are going around in circles. The Product Owner was always present, and the team would not really speak about problems at the team level. Even after organizing categories to specify whether problems (and successes) are at team, sector or organization-wide levels, the problems at team-level remained underrepresented and would often boil-down to difficulties that actually lay in cooperation with other teams.

Individuals becoming a Team

Although the team had been performing very well, the Product Owner did not want to take the further steps recommended by the SM to improve the team’s performance further. Instead, the PO turned up for the Backlog Refinement and questioned the concept of the meeting; and what is more, he had no proper Backlog for the team to refine. Similar problems have been encountered in other meetings, including Dailys where the PO was openly dismissive of the pull principle by actively staring at a person whom he believed should take a particular User Story during the Sprint Planning 1.Of course, there are many ways to address this. However, in order to ‘empower’ the team it is important to keep a cool head and not to argue during joint meetings, but rather explain the roles, the aim of the particular meeting and the principles of Scrum – day in, day out, if required. The team got the ideas and had a pretty clear picture of how things should run in an agile environment. After one particularly poor showing at the Backlog Refinement, I decided to communicate more openly and strongly what the team needs, and what the role of the PO consists of. At first glance, it seemed that this didn’t work out very well. The meeting ended without anything resembling a half-decent Backlog, with the PO throwing User Stories on the table in the shape of tasks, and a team visibly annoyed.

The Grassroots Retro

It was not entirely surprising to receive an update several hours later. The team held a spontaneous ‘crisis meeting’ and wanted to make these issues a subject in the next Retro. I welcomed this news with arms wide open, particularly because the team had developed a pull principle to Scrum itself.Although the PO used to join those meetings, I offered to exclude him this time. The team agreed. We started the Retro with two boards. One symbolized the United Nations. All the topics on this wall would be directly discussed with the PO. The other one was Las Vegas. What happens in Vegas stays in Vegas. The logic behind it was to encourage the team members to show commitment and also become aware when they are not courageous.To my positive surprise, everything ended up at the UN, while the themes were almost entirely focused on the dynamics within the team. After 1 hour we realized that we need more time, so we organized a second part to go through the themes and find potential solutions. The vast majority of the themes challenged the PO, how he is fulfilling the obligations towards the team, and produced concrete steps forward. The next steps were to formulate the points, prioritize them and for me to present them to the PO who needs to commit to them.

Discovering Openness

Overall, and irrespective of the possible outcome of the meeting between the PO and the SM, the team has succeeded in formulating and openly speaking about problems. Initially, they were not able to challenge the PO directly. By now, the team members have committed themselves to use Retros to raise essential questions to improve their ability to work effectively. I’ve realized that feeling the pulse of the team and reading between the lines are important, and I’ve also learned that it is crucial to invest time in change and provide clarity on roles and responsibilities. The results speak for themselves. In the next sprint, the team nearly completed the entire committed Sprint Backlog, and the members have also begun sparring to learn new skills from one another. When culture change is in focus, openness does go a long way.