Pair Programming Workshop at Agile Spain 2010

I had the pleasure of facilitating a workshop at Agile Spain last week. Apparently this was the first Agile Spain ever. I must say the people at the conference were very enthusiastic and eager to learn more about Agile. I met lots of interesting people, and really appreciated how welcoming everyone was. A special thanks to those who translated eager Spanish discussions for me.

My workshop consisted of two parts. First my initial presentation called Pair Programming Strategies. My proposal to the conference was intended as a workshop around what we tend to do when our ideal pairing situation comes under pressure from various disturbing forces. My understanding is that conference organizers will post the slides on Slideshare, meanwhile you can take a look at the PDF here: Pair Programming Strategies – Agile Spain 2010.

The second part was an Open Space discussion. It turned out that less than half of the participants had tried pair programming, and only a few were doing it on a daily basis. However, the Open Space format was very adaptive to the participants’ needs, and it seemed we ended up with a set of interesting topics. Here is a quick summary of the discussions, based on the notes I gathered from each group (thanks for writing this down!). (If you participated in the workshop and are reading this blog, please feel free to add some comments. I wish I had taped the summaries everyone gave at the end.)

How do you start (pair programming)

This group was curious about how you actually get started with pair programming. Here are some keywords from the discussion:

  • Physical setup: Big screen / 2 screens. Movable keyboard / 2 keyboards.
  • Write down what you are working on.
  • Driver / copilot / supervisor. Switch roles.
  • Responsibility – Collective code ownership
  • It could be exhausting
  • Good merge with TDD. One writes the test, the other writes the code to pass it (Ping, pong)

Performance impact

This group discussed whether pair programming is an effective way to work or not. Here are some keywords:

  • Just for core functionality or also easy tasks?
  • What about deadlocks?
  • More focus
  • Knowledge transfer
  • Share responsibilities
  • Less or more stressful?
  • Tight schedules

The study referred to in this Wikipedia article which observed “a 15% increase in time, but a 15% decrease in bugs”, was mentioned as an example of a quantitative measure on the effectiveness of pair programming.

Distributed Pairing

This group discussed how or whether it is possible to do distributed pair programming.

  • Network latency is a problem
  • Very high bandwidth required
  • Communication services, such as video/audio must be working all the time
  • Desktop sharing tools
  • Different timezones
  • Is it possible to reproduce benefits of pairing remotely?
  • Try it first with people you have paired with co-located earlier
  • Multiple monitors

If I remember correctly, the group concluded that you needed to create an environment that was as close to a co-located one as possible. Then you would hopefully achieve a flow that was approximately the same as in a co-located setting.


Eventually someone formed this last group, discussing disagreement. They discussed what to do with a deadlock. And suggested one should involve a third person.

I asked everyone to give me a quick feedback on their way out, the result was 17 “+”, 7 “+/-” and 0 “-“. Among suggestions for improvements was to find a room without tables, as well as make it more dynamic. I am quite pleased with the feedback, but will do my best to improve. If you have more feedback, please leave a comment or send me an email (erlingwl (at) gmail (dot) com).

A big thanks to everyone who participated. I had a great time in Madrid 🙂


2 Responses to “Pair Programming Workshop at Agile Spain 2010”

  1. » Blog Archive » Retrospectiva de Agile Spain 2010, la primera conferencia sobre metodos ágiles en España Says:

    […] I ended up with the convinction that Pair Programming can be really useful and its regular practice can reduce the number of bugs in the code. I’ll have to practice it from now on . Erling posted a summary of the discussions in his blog. […]

  2. Luca Minudel Says:

    On the topic “Performance impact” there was some discussion about this point “Just for core functionality or also easy tasks?”.

    It end up that when the tasks are easy, you can still benefit from pairing:
    – you can use the pair to go faster (one go flat with the gas, the other push the brake whe necessary)
    – you can raise the bar of the quality of code

    This require some previous experience in pair programming, so when you whant to start with pair, maybe it is more productive to start with difficult tasks.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: