Enter the Danger Zone and celebrate!
The team file out of the meeting room after another one of those retros. They have spent the last 2 hours bitching about the slow build, the slow PO feedback, not understanding the design and the constantly changing requirements. It’s all a bit like deja vu, they discussed all of those last week as well, and the week before.
They are exhausted and sapped of energy, and feel completely disempowered to change anything. And the cycle continues, retro after retro, knocking the team down.
It’s not a pretty picture, but all too common.
Let’s look at two simple things we can use to drag this team out of the doldrums!
Step 1: Squash problems immediately with the DANGER ZONE!
Always remember that you don’t have to (and shouldn’t) wait for the retrospective to discuss problems.
Tackle your problems right away, using a focused problem solving retro. Box off a small area on your board, or if you are not using a physical board, dedicate some wall space for this. Make sure wherever it is, it’s somewhere visible. Label it the ‘DANGER ZONE!’ (or something equally entertaining).
If anyone on the team has any concerns at all, they should write it on a suitably bright and scary looking post it and stick it in the danger zone.
Immediately after the next stand up (or sooner) hold a retro to tackle the issue. Make sure you produce clear actions for at least two people to work on the problem together. If this is an issue that’s blocking progress, then your team needs to focus on it.
Why wait to solve a problem that is blocking your ability to deliver?
Step 2: Celebrate!
Now you’re handling all of the problems in your focused problem solving retros, as the problems come up, you might notice that your normal retro is feeling a little empty, without all those things to moan about. So, let’s fill it up with something better.
Make this regular retro, what I call the cadence retrospective (regardless of whether you are running Sprints or Continuous Flow, this should run at a regular interval, or cadence). This retro should be entirely positive and focused on two key ideas:
- What went well, and how can we do more of it next time?
- Celebrating our successes!
The first part should be like many retros, brainstorm on the question and discuss the points raised. The difference, no problems can be discussed at all. If you have problems, then hold a specific problem solving retro (see above) to discuss the matter.
The second part, is to make sure you all celebrate your successes. I like to use an exercise I love from Norm Kerth’s book Project Retrospectives, “Offer Appreciations”.
To do this, have the group sit in a circle, then an individual can offer an appreciation to someone else or the entire group. The one(s) receiving the appreciation can either be silent or say “Thank you” they can’t say “Ahhh! Just doing my job!” etc. There are far more details in the book which I thoroughly recommend!
Lastly, bring food, and make the occasion fun!
But wait! What if we have actually screwed up!?
What if we have failed? How could there be anything to celebrate?
What did you learn? Did you not learn anything? Did nothing work at all? Rarely is it so bad, that you didn’t deliver anything and didn't learn anything. If you are having regular focused problem solving retros then you will have a lot of learning to celebrate, which is after all, something that always moves you closer to your goal.
So, let’s go back to the team we visited at the start and see how they might apply these practices, even when times are tough.
They have just come to the end of a tough two week sprint, they haven’t delivered what they planned. The regular problem solving retros throughout the sprint helped them identify and resolve a number of issues as they came up, but they weren’t able to ship what they had wanted.
Though, they had learnt a number of things:
- They needed to focus on tackling defects and technical debt as it was making it too hard for them to make changes.
- They needed to improve the speed of their build.
- They needed to get quicker feedback from their product owner to help them move forwards quicker.
They discussed these issues as they came up, and agreed actions and changes that have already been implemented.
The team ate lunch together and then went straight into their afternoon positive retrospective. They kicked off with a brainstorm on what went well. Deciding they would pair more next sprint as they really reduced their defect count this time around.
They had a small break (with donuts and other tasty morsels) and then the Offer Appreciations exercise. They worked their way round the group until everyone had received an appreciation from someone, the energy in the room was palpable.
At the end of the day, they cracked open the company fridge and had some pizza and beer in the office before heading home feeling awesome and ready to tackle the challenges of the next sprint.
What do you think? Have you tried positive retrospectives in your organisation? Let me know!
