It is common sense that retrospectives are important to improve our software development processes. But how can we improve our practices?

Developers who perform pair programming (PP) usually have no possibility to reflect their own behaviour to advance their PP style as they have to work highly concentrated on solving a complex task.

I have applied a retrospective technique for pair programmers at four German companies.
As a result, the developers were able to identify individual positive and problematic behaviours and were shown options to improve their future PP sessions.
Additionally, some of the programmers (especially in newbie-expert constellations) changed their perception of the current session.

This approach could help to improve pair programming behaviour and lead to a better motivation for pair programming.

Discussion

• Hi Laura. I this sounds interesting. I hope you'll come along to the session I've proposed on encouraging teams to pair more - it sounds like you'll be able to make a fantastic contribution! It occurs to me that we might even be able to combine the sessions... What do you think? -- MattWynne
• Hi Matt. I have read your proposed open space topic. Very interesting! My research goes into the same direction. I applied retrospective techniques in order to help teams learn to pair successfully. It would be great if we could discuss our topics together. So we could indeed combine the sessions. --LauraPlonka
• Hi Laura [and Matt]. In my experience most developers are reluctant to pair. As a coach I get to do this a lot and one of the first things I hear when sitting down to pair is that 'I'm doing boring stuff' or 'It's not worth it for what I'm working on'. Invariably the pairing session proves to be very valuable. I'm happy to contribute my experiences to this. --PeterCamfield