Mark Needham

Thoughts on Software Development

Archive for the ‘retrospective’ tag

Book Review: The Retrospective Handbook – Pat Kua

without comments

My colleague Pat Kua recently published a book he’s been working on for the first half of the year titled ‘The Retrospective Handbook‘ – a book in which Pat shares his experiences with retrospectives and gives advice to budding facilitators.

I was intrigued what the book would be like because the skill gap between Pat and me with respect to facilitating retrospectives is huge and I’ve often found that experts in a subject can have a tendency to be a bit preachy when writing about their subject!

In actual fact Pat has done a great job making the topic accessible to all skill levels and several times covers typical problems with retrospectives before describing possible solutions.

These were some of the things that I took away:

  • One of the most interesting parts of the book was a section titled ‘Be Aware of Cultural Dimensions’ where Pat covers some of the different challenges we have when people from different cultures work together.

    I found the power distance index (PDI) especially interesting:

    The extent to which the less powerful members of organisations and institutions accept and expect that power is distributed unequally

    If you come from a culture with a low PDI you’re more likely to challenge something someone else said regardless of their role but if you’re from a culture with a high PDI you probably won’t say anything.

    The US/UK tend to have low PDI whereas India has a high PDI – something I found fascinating when participating in retrospectives in India in 2010/2011. I think the facilitator needs to be aware of this otherwise they might make someone very uncomfortable by pushing them too hard to share their opinion.

  • A theme across the book is that retrospectives aren’t about the facilitator – the facilitator’s role is to help guide the team through the process and keep things moving, they shouldn’t be the focal point. In my opinion if a facilitator is doing that well then they’d be almost invisible much like a football referee when they’re having a good game!
  • The ‘First-Time Facilitation Tips’ chapter is particularly worth reading and reminded me that part of the facilitator’s role is to encourage equal participation from the group:

    A common, shared picture is only possible if all participants give their input freely and share their view of the story. This is difficult if one or two people are allowed to dominate discussions. Part of your role as a facilitator is to use whatever techniques you can to ensure a balanced conversation occurs.

    I think this is much easier for an external facilitator to do as they won’t have the burden of inter team politics/hierarchy to deal with.

    Pat goes on to suggests splitting the group up into smaller groups as one technique to get people involved, an approach I’ve found works and from my experience this works really well and gets around the problem that many people aren’t comfortable discussing things in big groups.

  • There’s nothing more boring than doing the same retrospective week after week, nor is there a quicker way to completely put people off them, so I was pleased to see that Pat dedicated a chapter to keeping retrospectives fresh.

    He suggests a variety of different techniques including bringing food or running the retrospective in a different location to normal to keep it interesting. I’ve heard of colleagues in Brazil doing their retrospectives outside which is another angle on this theme!

  • Another good tip is that when creating actions we don’t need to spend time getting someone to sign up for them right there and then – an alternative is to encourage people to walk the wall and pick ones they feel they can take care of.

I think this book compliments Esther Derby/Diana Larsen’s ‘Agile Retrospectives‘ really well.

I find their book really useful for finding exercises to use in retrospectives to keep it interesting whereas Pat’s book is more about the challenges you’re likely to face during the retrospective itself.

There’s lots of other useful tips and tricks in the book – these are just a few of the ones that stood out for me – it’s well worth a read if you’re a participant/facilitator in retrospectives on your team.

Written by Mark Needham

August 31st, 2012 at 9:18 pm

Posted in Books

Tagged with

Focused Retrospectives: things to watch for

without comments

A few weeks ago a slide deck from an Esther Derby presentation on retrospectives was doing the rounds on twitter and one thing that I found interesting in the deck was the suggestion that a retrospective needs to be focused in some way.

I’ve participated in a few focused retrospectives over the past 7/8 months and I think there are some things to be careful about when we decide to focus on something specific rather than just looking back at a time period in general.

Victimisation

In a retrospective about 6 months ago or so we focused on the analysis part of our process as we’d been struggling to know when a story was complete and what exactly its scope was.

The intention wasn’t the victimise the people working in that role but since there were very few of them compared to people in other roles they were forced onto the defensive as people criticised their work.

It was a very awkward retrospective and it felt like a retrospective was probably the wrong place to address the problem.

It might have been better for the analysts to have been given the feedback privately and then perhaps worked on a solution with a smaller group of people.

Looking for a problem when there isn’t one

I had an interesting conversation with a colleague about whether with very focused retrospectives we end up looking for something to change rather than having any specific pain point which necessitates change.

The problem with this is that there’s a thin line between following the status quo because it works and getting complacent and not looking for ways to improve.

It is interesting to keep in mind though that if it doesn’t seem like there is something to change in an area then perhaps that’s the wrong thing to be focusing on at the moment, which nicely leads into…

Let the team choose the area of focus

There can be a tendency in the teams I’ve worked on for people in managementy roles to dictate what the focus of the retrospective will be which makes sense in a way since they may be able to see something which the team can’t.

On the other hand it can mean that we end up focusing on the wrong thing and team members probably won’t be that engaged in the retrospective since they don’t really get to dictate what’s talked about.

Esther points this out out on slide 23 of the presentation – “Choose a focus that reflects what’s going on for the team“. This perhaps can be determined by having a vote before hand based on some topics that seem prominent.

In summary

There’s lots of other useful tips in Esther’s slide deck which are worth having a look at and I’m sure most of the potential problems I’ve listed probably don’t happen when we have a highly skilled/experienced facilitator.

Written by Mark Needham

January 16th, 2012 at 1:01 am

Posted in Agile

Tagged with ,

Retrospective: The 5 whys

without comments

Last week my colleague Pat Fornasier ran our team’s fortnightly retrospective and one of the exercises we did was ‘the 5 whys’.

I’ve always wanted to see how the 5 why’s would pan out but could never see how you could fit it into a normal retrospective.

Pat was able to do this by using the data gathered by an earlier timeline exercise where the team had to plot the main events that had happened over the last 6 months.

We ended up with 5 key areas and split into groups to explore those topics further.

Wikipedia describes the 5 whys like so:

The 5 Whys is a questions-asking method used to explore the cause/effect relationships underlying a particular problem. Ultimately, the goal of applying the 5 Whys method is to determine a root cause of a defect or problem.

My group had to investigate the topic ‘Why are we so obsessed with points?’.

These were some of my observations from the exercise:

  • It’s very easy to lose focus on the exercise and start talking about solutions or ideas when only a couple of whys have been followed.

    Pat suggested that this problem could be solved by having a facilitator who helps keep the discussion on track.

  • We went down a dead-end a few times where our 5th why ended up being something quite broad which we couldn’t do anything about.

    We ended up going back up the chain of whys to see whether we could branch off a different way on any of the and it was actually reasonably easy to think of other whys the further up you went.

  • By going beyond surface reasons for things you actually end up with much more interesting conversations although I think it does also become a little bit more uncomfortable for people.

    For example we ended up discussing what ‘minimum viable product’ actually means for us and a couple of the group had a much different opinion to the product owner. It would have been interesting if we’d been able to continue the discussion for longer.

  • For our particular topic we ended up discussing why the deadline we have was set when it was and couldn’t really come up with any reason for why it couldn’t be changed other than we’d been told it couldn’t.

    It would have been more interesting to have the people external to the team who set the deadline so that we could understand if there was more to it.

I tried looking for a video to see a real life example of a 5 whys discussion being facilitated but I wasn’t able to find one.

Perryn pointed me to a chat log on the cucumber wiki where Aslak asks the 5 whys to someone trying to articulate why they want to have a login feature in their application but I’d be interested in seeing more examples if anyone knows any.

Written by Mark Needham

October 24th, 2011 at 10:53 pm

Posted in Agile

Tagged with