An Effective Sprint Retrospective? Do it the Fish!y way!

Choosing how you will walk through your day, having fun with your colleagues and clients, actively listen and participating in collaborations, and ensuring others also have a great day. I have written a short story a while ago about the basics of the Fish! Philosophy for being an outstanding team member.

Now let’s have a look at how this could fit within a Scrum Team. Even more specific: during the different Scrum Events. Today I chose to pick the Sprint Retrospective.

A small reminder from the Scrum Guide: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” In other words transparency, inspection, adaptation to make the next Sprint more effective and enjoyable. The participants of this session are the full Scrum Team: Product Owner, Development Team and the Scrum Master.

Scenario A:

After the Sprint Review, the team members stay in the same room. There is still a smell of ... , well, a smell.
Once all stakeholders left the room, which was about after ten minutes, the Scrum Master stated it was time to do the retro: “Now, let’s discuss what went OK and what didn’t go so well, and find ways to do it better next time. We’ll do a round-table and one-by-one please indicate what you liked and what you didn’t.”
The team members dropped back in their chairs and someone started: “I am pretty happy. Nothing is really bothering me. Fine for me.”
The person at her right took over “Yeah, me too. Maybe we could benefit from some management support though. Especially that procurement process takes too long.”
Someone at the other side jumped in “Fully agree, but there is nothing we dan do about it”.
Everybody nodged in agreement. Except for “We could put a red indicator on a post-it to indicate some action is blocked. That would allow us to skip it at the Daily Scrum.” nothing else seemed to need any improvement.
And so it goes on, every Sprint Retrospective again. What went well, what didn’t, what could they do. What went well, what didn’t, what could they do. But nothing really changes. The same topics come back at regular intervals. 

Scenario B:

After the Sprint Review, the team members leave the room to take a fifteen minute break outside. Some hang around the corridor having a laugh with one of the stakeholders who apparently was telling a joke - the combination of laughter and tears rolling from their cheeks are tell-tale. A few minutes before the Sprint Retrospective is planned to start, team members walk back in the room and there is this smell of..., well, not sure… a smell of… pancakes…?!

What an idea! The Product Owner bought a kilo or two fresh pancakes and during the break had warmed them up in the kitchenette. Cool! Well, warm... Delicious.

Ten minutes later, each team member had picked a LEGO® Zombie and a LEGO® Hero and was explaining to the colleagues how that Zombie tried to screw up quite a few things during the Sprint and was planning to do a better job of it in the next Sprint, while the Hero was able to prevent a few things, not all though, yet was training and finding better ways to prevent these things from happening again, sharpening its skills (and weapons) to support the team during the next battles.
The team already knew the Scrum Master was still half a kid playing with LEGO® in his spare time - a few Sprint Retrospectives ago it were Star Wars rebels against the Empire or something like that…
Nonetheless, some small, yet very practical opportunities to improve the testing were agreed for the upcoming Sprint.
Nobody was distracted by emails or mobile phones. Everybody was really actively listening into the story-telling of the others, asking questions to clarify the challenge or improvement opportunity as needed.
The team was really into it. It was a great session with two clear action points the team committed to experiment with and evaluate after six weeks.

Allow me to assume that you would prefer scenario B. Why is that? It feels straightforward doesn’t it. In fact, in contrast to scenario A, scenario B does implement the four simple practices of the Fish! Philosophy.

The Product Owner “Makes Their Day” by unexpectedly bringing pancakes for them. Just like that. No specific reason. It was a Sprint just like the other Sprints.

The Scrum Master allowed the team to “Play”. This time with LEGO®. But it could be in thousands of other ways. Throwing with props of paper to the next person who should complete a sentence with an idea in it. Completing a drawing of someone else. Creating a Product Box - jep, there are literally thousands of facilitation techniques that make this type of workshops fun and engaging, which brings creativity - needed for innovation so it seems...

The team is “Be There”. They were actively listening to each other. Asking questions. Clarifying. They were engaged to find better ways for the next Sprint; to achieve the goal of the Sprint Retrospective.

And all in all, they did “Choose Your Attitude”. They were not complaining about things that didn’t work. They were searching to improve. The context is 100% the same as in scenario A. Yet they were having fun while working effectively towards their objective. Because they chose to.

 

Anything you want to change about how your team acts during Sprint Retrospectives? Let us know, we might help you out, or you can join our next Fish! Philosophy workshop.

Fish! on…