Author: Kerry Buckley

Josh Evnin writes in Agile anti-pattern: Developer-focused retrospectives:

In a retrospective, however, it is important that no one group of team members is favored over others. This is harder than it may seem, especially when the developers make up more than half of the team.

The way most retrospectives I’ve been a part of have worked is some variation of the following:

1. Individuals think of a few things that have gone well, and a few things that have gone less well over the past set time period
2. These thoughts are put on post-it notes, then placed on a wall
3. Individuals read all the thoughts and vote for the ones that they agree with (each person has a limited set of votes)
4. The retrospective facilitator tallies the votes and discusses the highest vote-getters with the team, and discusses ways to fix problems and continue successes

Now, as you can tell this is a quite democratic process. The problem is, when the ratio of developers to business analysts is 4:1, you start to see the topics discussed err towards the technical.

I wonder whether concentrating on one role’s issues is also a symptom of not having retrospectives often enough.

Of course there’s a place for project or release retrospectives, but I tend to find more frequent iteration/sprint retrospectives more useful, as they give you a shorter feedback loop. As a side-effect, there are usually fewer things to add to the list after only one or two weeks, so we have time to discuss anything that gets raised, rather than having to pick the most important.

One of the persistent themes in my team’s retrospectives is that we don’t pair as much as we should. It’s not that we don’t want to pair, or that something’s stopping us: we just seem too often to lack the discipline to start pairing and then not drift back into working alone again. I’m not sure the best way of avoiding the delay in forming pairs at the beginning of the day and after lunch¹, but here’s at least one tip to keep the sessions going.

If you need to quickly nip back to your own machine to check some documentation, google something, check for some urgently-awaited e-mail reply or whatever…

Don’t take your chair with you.

¹I think this is a variant of the ‘one more pint effect’ that’s often observed when a group over a certain size meets in a pub prior to going for a meal. One person decides that everyone’s going to take ages drinking up, so they decide to have ‘one more pint’. Of course, someone else then sees them with a full glass, and makes the same decision, and you end up arriving in the restaurant an hour later than planned. The pairing equivalent is where you all think ‘everyone looks busy, so I’ll just [answer that e-mail | do that pointless mandatory on-line training course | go and make a coffee] while I’m waiting for someone to pair with’.

Of course the real answer is to be strict about all production code being pair-programmed, rather than letting yourself make exceptions for ‘trivial’ tasks, or UI code, or refactoring, or something that started as a spike but has somehow grown tests and made it into the trunk…