Keeping things simple?! - EffectiveCoaching4u

This third post is about keeping things simple. Or actually, keeping things simple in the context of a retrospective.

When I started to work with a scrum team, I did not have a very broad backpack filled with techniques to equip my events. So in my very first years, I kept the retrospective quite simple, by focussing on the good, and the things we could improve as a team. That retrospective was quite effective and this particular group of people did not feel that we should move on to another format.

Nowadays I know a lot more of techniques, including different formats for different goals, and a lot of -mostly playful formats- have become available for everyone to use. These formats are certainly very helpful and inspire us as scrummers quite often in how to create a playful and happy retrospective event.

I notice however that these more vivid arts of retrospective are not always leading to teams becoming more happy about the retrospective and its outcomes. Furthermore, I notice that at least “starting” scrum masters typically use that format for showing their skills to create a retrospective everyone likes. I can at least say that I actually learn new formats on regular basis from colleagues, even if they are quite new.

And it happens quite often that something is bothering me. At least when I observe teams of team members to drift of with their minds during a retrospective, or trying not to come because a super important other meeting suddenly popped up, or telling me that they actually don’t like it.

For addressing this concern, I refer back to my previous posting, where I stated that it is always important to think about the why before moving forward with the what and the how. What goals are we trying to achieve with the retrospective? As stated in the Scrum Guide, the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. So its primary purpose should be right that. And of course, it may be helpful to add techniques that encourage people to speak up, of get themselves ready to collectively address pain points. Any addition may however have a counterproductive effect as well. Like people who don’t like to come to the retrospective anymore since are confronted with (unexpected) playful elements and maybe walk out of the retrospective with the feeling that they have not collected an action (plan) to change anything at all.

Therefore, I believe that it would be a good idea to keep one of principles of the agile manifesto in mind here: Simplicity–the art of maximizing the amount of work not done–is essential. Of course that principle is valid for executing the work done on a product. And I believe it is helpful as well for executing the way we work together as well. So keeping things simple may be a good starting point.

I tend to make things simpler during initial retrospectives, so the participants can fully focus on getting some results out of it first. If at a certain point the participants are indicating (hopefully though the retrospective itself) that something needs to be changed and the format becomes boring, that is the right moment to spice things up and change things.

In one of my previous engagements I had a team that was doing the retrospective always the same way and even after many times valuable things came out of that retrospective. An attempt to change the format, led to some negative responses. That was the moment where I realized that the retrospective is not a scrum master thingy, though something that needs to be owned by the team in order to improve…