Recently, a Product Owner from a team I had no previous contact with approached me to facilitate a retrospective. The lessons I learned from this experience highlighted to me the importance of being receptive to changing requirements (even late in the day) and adapting to optimise value.

The Scrum Master for a team working near where I sit in the office went away on an extended vacation (very nice indeed!). Due to a few factors, the cover put in place did not come to fruition, and because of this, the Product Owner reached out to me to assist with the facilitation of some of their Scrum events, including their retrospective, which was booked for the following afternoon.

On the day of the retrospective, I was feeling a little concerned about what to expect. I was told that half the team would be absent in other meetings, that people would be calling in via Skype, and that the time slot – originally one hour – had been reduced to thirty minutes. Talk about changing requirements late in the day!

"How could this team possibly get value from a retrospective under such challenging circumstances?"

The easy thing would have been to cancel the retrospective.They are not my team, I did not know them, and clearly, by putting so many barriers in place, they could not be that interested in having a retrospective, could they?However, as they had kept some time in place, it was evident that they had some issues they wanted to share, so I resisted the temptation to pull the plug.

This is what I did:

I brought together a plan for a quick retrospective, using some tools shared with me by some of my fellow Scrum Masters.As I didn’t have much (if any) context of the work of the team, I encouraged each member of the squad to share what they cared most about in the previous sprint, either because it caused pain, or because it brought them joy (2 minutes each).

Next, the team worked on a simple ideaboardz (which is great for including the remote workers) where the team spoke about what worked well, what they could improve on, and what actions they wanted to take into the next sprint.During this time box (c.15 minutes) the team spoke openly and were particularly receptive of the tool as a way for all team members – on site and working remotely – to engage equally in the discussions.

What happened next was when the retrospective really started:

To close the retrospective I drew upon the Retro Dart. For this, I asked each member of the team to place a dot on the board to mark if they ‘spoke openly’, ‘spoke about what mattered’, and their confidence on improving in the next sprint.

To the first and second questions, everyone voted 100% in agreement with the statement.From a personal perspective, this was great feedback on my facilitation of the retrospective. It was pleasing to see that I had helped foster an environment that created a space where the squad could speak freely about the issues they cared about.

However, when it came to the third question – on their confidence that they would improve – the team really opened up. It transpired that they had a list of key blockers that were causing them pain. They needed to escalate these, somehow, as they were not making any headway.As this insight came late in the retrospective it was a challenge to have the team agree on any commitments. What did come from this was a recognition that they needed to improve their communications with people who could make a difference in moving their blockers.

The following week, I was delighted to hear from the team that a weekly call with key stakeholders that had lapsed had started up once more. It was great to see the team own an action on their commitment to enhance the level of contact time with people who could positively influence their challenges.

Despite only spending 30 minutes with this team, it was a rewarding experience, and my relationship with this team – and their vacationing Scrum Master – improved for the better.