Debugging Pair Programming
Add to calendarI think Pair Programming is vital to the success of a programming team, but every time I join a new team I seem to find I’m in a minority of people who feel that way, let alone have any experience of actually doing it.
This is not a session about convincing a manager that it’s a good idea: let’s assume he or she trusts you to do whatever is right for the project. This is about exploring, understanding and ultimately tackling the hidden influences which inhibit your peers from coming out of their caves and sharing their thoughts and ideas in regular, constructive, creative, pairing sessions.
I ran an open-space session at XP Day London 2008 (http://www.xpday.org/) where we used brainstorming techniques to identify and map the issues that can get in the way of effective adoption of pairing. We did some analysis of these, but barely scratched the surface in the time we had. I propose to dig deeper into these issues with this session, by seeding it with some data we collected in that session.
Intro.
0 - 10 mins
Quick scene-setting lecture from me on why I think pairing is important and valuable, and that I have observed that it’s also a neglected practice, and one which seems to be extremely hard to learn. Overview of what we hope to achieve with the session.
Part 1 : Exposing and understanding the problems
10 - 45 mins
Attendees are sat in groups of ~6 around tables. Each table has a topic, these will be seeded examples of the key issues we identified at XP Day. e.g. “Goran, Chief Architect: I tried pairing a few times but it’s just a waste of time - I don’t learn anything and it slows me down”, or “Michelle, Project Manager: We don’t have time to pair program - there are too many bugs to fix!”. They will be given 10 minutes to discuss the person concerned, and think about why they might feel like that - what the underlying issues might be. They’ll be encouraged to mind-map onto the flip-chart sheet in front of them on the table.
We’ll rotate people around the tables (some moving one way, some moving another, 1-2 staying put) to mix it up, then run the discussion again.
After a couple of changes, we’ll stop and each table will be asked to briefly present what they’ve learned back to the room.
Break - Pair Up!
45 - 55 mins
By this point we’ve used probably 45 minutes and after some discussion, we’ll mix things up a little. Using a couple of decks of cards, or somesuch, we’ll get people into pairs and have them interview one another about great teams they’ve worked on, or great experiences of pairing that they’ve had. By now people are really steeped in the subject and they should be chatting away. We’ll leverage this energy to really mine them for some patterns and answers.
Part 2: identifying Solutions
55 mins - 80 mins
For part 2 our goal is to identify concrete solutions to the underlying problems we identified in part 1. During the break I’ll summarise each of the main root problem areas we identified onto flip-chart sheets, and I’ll pin these up around the walls. I’ll explain that we can discuss and solve each of these in open-space format, but that ultimately we need to produce a document (or manifesto) that distills our thinking on all the topics.
I’ll ask for one small group to manage the collation of ideas from around the room. We will use this to build a manifesto of the form: “In order to be able to pair program effectively, we need:”
Part 3: Close
85 - 90 mins
We’ll review the manifesto we built, maybe dot-vote on the most popular manifesto entries, pat each other on the back, and head off for a well earned beer.
- Enumerate the reasons why pairing is useful and effective
- Enumerate the different issues that can inhibit effective pairing
- Tools for identifying and resolving these issues when they come up
