My thoughts and experiences about software development

Primary Menu

Category Retrospectives

If you are struggling with quiet team members who never say a word during retrospectives, or on the contrary, loud team members who don’t understand to let the others speak once in a while, then brain writing could be brilliant for you!

Brain writing is a technique for brainstorming in a group. It can be used during the “generate insight” phase of the retrospective.

Everyone starts with a stack of blank papers and a pen. They get 3 minutes to write down ideas, one per paper. When the timer rings everyone passes their papers to the right and receive papers from the person to the left.

Now you have a new ideas which you can use for inspiration. You can either add things on the paper if the idea sparks new ones related to the one on the paper or start a new paper if you come up with something entirely different.

The exercise is over when the first papers come back to the original author. Now put the papers up on a wall or lay them out on the table and have everyone read through them and be awed by the amount of generated ideas!

We used this template for writing down ideas:
“To be better at __________
We need to ________________
Every _____________________”

For example we had:
“To be better at knowledge sharing
we need to do more mob programming
every now and then”

I love brain writing because:

it is a silent activity, everyone is on equal terms. The loud person doesn’t get too much space and the quiet person gets hir ideas heard as well

building upon other people’s ideas is inspiring and creates a lot of “yes, and …!” moments

the template made us focus on purpose of suggested actions.

Finish with a round of silent prioritization for “Decide what to do”, pick your top 1-3 and you’re ready to start working on some inspiring improvements!

This time, we were two teams working together to release a more modern and responsive booking site for a travel agent. We’re not using any bug tracking software instead we had were post-it notes for each issue. Other than that the approach was the same: gather the teams, sort bugs in categories which felt appropriate, discuss results and pick one issue to analyze.

Grouped post-its

We sorted the bugs first into categories such as IE, mobile, appearance, infrastructure, translations, etc… and then we used dots to mark the one which we found were the most severe and/or important bugs. After talking freely about what we saw when we looked at these

bugs and how it made us feel, we selected one which we did a root cause analysis on using 5 Whys.

We finished by identifying one concrete action which would help us improve. The action became a story card which will be prioritized among the others in the backlog. The action was that we needed to make sure that we could trust our test environments.

What I learned

This exercise requires 1½-2 hours when the volume of bugs is around 50.

I felt that it was important that we wrote down one action to take. Even though the action only became “hold a meeting to discuss what we can do to improve our test environments” it is a promise that we will have the discussion.

Selecting only one issue to analyze and only one action to take felt like a drop of water in the sea of possible improvements. But I do believe it is better to commit to one action at the time rather than doing a lot of things simultaneously. If it turns out to be a small thing to fix, it will be done quickly and we can select a new one sooner.

I do believe that you should hold retrospectives like these whenever you have done a major effort in your team. Retrospectives aren’t just for the end of a sprint, they can be used in many other situations where you need to reflect on something that has happened in order to improve continuously.