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.)

 

 







8 Responses to “Work retrospective”

  1. Sandy Mamoli says:

    Great idea! I’ll try that at one of my next retrospectives.

    Thanks for sharing.

    Sandy :-)
    (@smamol)

  2. George Paci says:

    Excellent idea. Two questions:

    1) Do you do this in place of the usual process retrospective, or in addition?

    2) Is there anything magical about 1 hour, or do you think 90 minutes would work instead?

  3. yhanoulle says:

    Great Questions. Sorry I was not clear on this.

    1) yes this is done instead of a normal retro.
    The teams I did this had sprints of one or two weeks, so we do a lot of retrospectives.

    2)A] Be careful the full time, can take at least 90 minutes. (introduction, presenting of ideas,demos etc.)
    B] And yes you can do a 90 minute work.
    Actually the last team that did this, we had forgotten another company meeting, and we did it for 30 minutes. Which was very short, I would say too short. And still, we had a few pairs that delivered…

  4. [...] one of my clients after a we did a work retrospective, my PairCoach and I decided to launch another work retrospective, yet now concentrated on the demo. [...]

  5. [...] Improve anything you want (typically in code) in one hour [...]

  6. […] hat mein Freund Yves Hanoulle im März diesen Jahres einen Blog Artikel geschrieben, in der er eine besondere Form der Retrospektive vorstellt: Die Arbeitsretrospektive […]

  7. […] hat mein Freund Yves Hanoulle im März diesen Jahres einen Blog Artikel geschrieben, in der er eine besondere Form der Retrospektive vorstellt: Die Arbeitsretrospektive […]


Leave a Reply