It’s not a secret I am a big fan of retrospectives. A big fan as I think it’s the regular standing still that helps a person/team/company improve.
I’m actually convinced it is better to start unprepared and stand still every 2 weeks, then to take weeks or even months to prepare. With retrospectives, we react to reality, not plan what we foresee.

Over the years I have helped a lot of teams & companies by facilitating retrospectives for them.  For  some companies it’s a yearly proces, for others, a one time event and luckily for most a recurring event.

From time to time, you see teams that are fed up with a weekly retrospectives.
– nothing ever changes !!
– why are we the only ones that have to change?
– we never get time to implement the idea’s we have!!
etc etc

My experience as a coach is that most of these remarks are wrong. yet I also know that from the teams perspective, they are correct.

As much I like to challenge teams, I also listen to them.
(Not really a contradiction as I have to listen to challenge them )

one of my favorite retrospectives to deal with this, is a work retrospective.

 

Set the stage:
Any activity to set the stage can work here. These days Check-in is my favorite

Gather Data:

Let everyone in the team write down one or two action that they think should be solved and only take about an hour.

These tasks should not be know bugs that we should solve, yet really improvements that can help the team.

>> 5 minutes for this

People present one post it in a round robin way.  When we did the whole table, we start again with the first. You stop after 2 round or when no one has any post it’s left.

>> Time depends on the size of the group

Select a partner + a task:
Every work is done in pairs. As this is an ultra short timebox, this is very hard. As I want the best quality, we do pairprogramming.

Some people prefer to select a partner and find a task together. Some people prefer selecting a task and then a partner. I’m very flexible on this, the timebox is already hard.

Just do it:

People get 1 hour to do what they want.
I encourage them to work in small steps.
Whatever they do, they need to check in after 1 hour or throw it away.

A mini demo:
We come back to the team and we show what we have done.
>> max 5 minutes per pair

Experience:
In most teams there are people who hate this. In lots of cases these are also the people that complain most that they never get the time to do anything.
I ignore them in this exercise. The rules are the same for everyone.
(That’s why I use lots of different retrospective formats.)

Usually there are about the half of the teams that have been able to do something useful. And when this happens, everyone in the team is teached it’s possible. (They might not be ready for it, yet people in their team have delivered something useful in one hour.)
And this is not me convincing them, their team has done it.

I once had a team complaining for 3 months that the homepage of their website was unstable because of unstable web-services  In 1 hour, 1 pair had identified +60 calls to web-services and they had fixed 40 of them. The updated was life in the hour. The next day, one of the developers, took the time to fix the other 20. We won that extra hour back in the same week, as our testers lost less time.

Every time there is a pair that is not ready by the demo. They keep working while their colleagues are demoing. I make it very clear that they won’t be able to demo. That usually stops them from working. I do this as they now pay attention to their team mates that were able to split in smaller tasks.
Almost every time I have a very good personal coaching chat with one of these developers about that.

Sometimes there is also a pair cheating and they show something they have been working on secretly. I don’t say anything about that. At least the secret project is now out. 😉

Remember, it’s not a competition. It’s about solving a problem.
In a normal retrospective, we also limit the number of things we aim for.
Here we use a set based design.
We go for multiple idea’s and we are happy when we achieve one or two.
(And yes sometimes every pair succeeds.)

Below you can find the video I talked about this on agile with Jimmy