In Learning

Working on the new Value, Flow, Quality education product requires a lot of thinking, creativity, loads of research and some technical writing. We’re only a small team and still we aim to spend most of our time pairing on the work we do. Although we are not writing code we have learnt from our experience with pair programming that by getting two brains together on a creative and mentally challenging tasks we can achieve better results. We have already discovered some tasks that don’t lend themselves to pairing but actually most do benefit from this approach. Far from gospel though, we treat this as a working hypothesis always aiming to validate it.

Last Thursday was an out-of-the-office day and most of us were working from home. Dan and I (both at the convenience of our home offices) still decided to pair throughout the day, even though we were working remotely. This was somewhat counter to what we would normally assume about pairing – that it works best co-located. Yet we were slightly surprised with the overwhelming sense of achievement by the time evening came. After all, we didn’t expect remote pairing to yield better results than working side-by-side.

I have no doubt there were many aspects which made our day so productive, many probably completely tangential to pairing. For example, our office is small and can get very busy and noisy. This doesn’t necessarily help whether you’re pairing or not. On the other hand the buzz of activity and constant exchange of thoughts, ideas and inspirations is essential to move our product forward.

Whatever the reasons (and I have no way of knowing without setting some proper experiments) the experience has made me re-evaluate my stance on remote pairing. I’m no longer of the opinion it’s necessarily always better when you’re collocated.

Right now in my mind two aspects made our work so effective:

  • the high bandwidth communication
  • an on-line editing tool supporting collaboration

Throughout the day we were constantly connected on Skype with good quality video. The ability to see each other meant that we didn’t loose all the cues we usually pick-up via the non-verbal communication. Remember, we were creating technical English prose, not code, so we were in the fortunate position of being able to take advantage of Google Documents. We ended up constantly writing over each other, correcting each other’s mistakes and throwing new ideas in while typing within the same document at the same time. Admittedly, this is different from pair-programming where usually only one person should have the command of the keyboard. In this case however it worked really, really well.

Now back to the first point, I also wonder if being able to face each other, albeit virtually, actually improved our ability to read each other’s facial expressions compared to the co-located, side-by-side scenario. Thus we could react more quickly to the other person’s hesitation and connect better over the task we were doing.

Whatever the actual reasons, and we’ll no doubt have many other opportunities to explore this, it remains clear that experimenting with new ways of working together, enabled through emerging technology, can sometimes bring impressive results.

Sign up to receive our newsletter and new posts

Recommended Posts
Showing 8 comments
  • Dan Rough

    It’s interesting to see this written up Marcin – I agree, it’s one of the most productive remote-pairing sessions I’ve experienced.

    I agree with your list (shouldn’t we have paired on this blog ;-)), and will add this commentary:

    The video helped a lot; worthy of note from my perspective though is that I was using applications in full screen mode and consequently only had video visible when I specifically felt I needed to talk with you (as opposed to just making a general comment about what we were doing), in those instances I actually switched to the space that I had the Skype video running in meaning that I was focused on the conversation rather than the feature we were working on. In my mind, this actually meant for structured flow states while working on the document, broken by meaningful conversation; in short, low interruption/high concentration work.

    Google docs was fantastic. Thursday was the first time that I’ve used it in such a highly-collaborative manner, it really did just work. There were a couple of incidents of us tripping over each other when editing something, but I think we worked this out through the day and then actually called out which paragraph we were going to work on, or allowed one person to write a sentence with the other making minor alterations to it as the other went. This really drove a sense of collective ownership in my opinion, both of us wanted the best piece of writing to come out and weren’t therefore precious about what we’d written.

    We started the day not only with a list but with a fair amount of structure in place in terms of what we were going to produce (at least bare bones of the feature we were writing in most cases) meaning that I think even though there was a high degree of creativity in what we were doing, it was very focused – the scope was narrow if you will. I think this led to less requirement for immediate collaboration in order to work out where we were going.

    Like you say – there’ll be more opportunities to perfect this – something that I think is very worthwhile to have as an option.

  • J. B. Rainsberger

    I’m glad to read more stories of people enjoying remote pairing. I haven’t done much, but it’s gone well much more often than it’s gone poorly.

    • Dan Rough

      I’ll be honest and say that I’ve previously dismissed pairing remotely as either something that completely missed the point, or as something that would continue to struggle until the tools were there to support it effectively.

      On reflection, I think that on this occasion it was something that I voluntarily signed up for (Marcin may correct me, but I think I suggested it in fact) and was keen to see be effective for the day – we’re focused on some significant steps forward for our product at the moment so that pressure, and the feeling that the week leading up to the pairing session had been fragmented and therefore not altogether productive, meant that I was keen to salvage some sense of progress and therefore, that I was fully committed to it.

      Now, you might say that the same attitude would have helped with colocation, and I’d agree, but I would say that in the case of colocation the discipline/rigour can be turned down a little and that what seemed to help us in this session was that it was turned up to 11.

  • Mirko Blüming

    Hello Marcin, Dan,

    I’ve also had a similar Wow-effect when I worked exceptionally at home and had to complete a PPT presentation 1-to-1 with a colleague. We’ve used Skype and WebEx and were excited of how good the communication was and how productive the sessions was.

    However, I miss this Wow-effect when I am listening to video conferences with the offshore teams (a couple of persons sitting on both sides of the screens). In a wider audience, sometimes the sound is bad. And, also persons start discussing things independently on both sides of the screens and the whole sessions falls apart.

    So my conclusion is still: Co-locating is the best option. But, you can try to minimize the communication loss in distributed teams (which seams to reach a zero-loss level in a 1-to-1 session).


    • Dan Rough

      Hi Mirko,

      I think that you’re right, colocation is to be preferred. I’m reminded of what Chip and Dan Heath in their book Switch refer to as Finding The Brightspots by Marcin’s blog post and your subsequent comment: I wonder what mileage we’d get by questioning our assumptions of why colocation is the best way to communicate in order to get a set that a given group (who might be involved in remote pairing sessions such as the one Marcin and I went through) agree upon. With that set of assumptions I could then foresee a number of small experiments being run that helped the group establish practices that worked for them (on the understanding that this would differ from group to group).

      It may be something for Marcin and I to discuss in the office this week – it might even be something for us to discuss over Skype 😉


  • diaryofscrum

    As a team we have been pairing remotely for a number of years. We are all based in the UK and meet up in London when we need but find we work best pairing remotely without the distractions of the office. It also allows us to spend more time with our families as well as our organisation. Initially we missed out on those spontaneous conversations that are so important but these days we are pretty good at just adding someone else (PO/Users etc) into the Skype call as needed, I sometimes have a few different group conversations on hold and switch between them. With practice I think you can work just as effectively as you can co-located.
    Issues: the main one for us is the time it takes to swap driver/navigator as you need to switch the working code to a different machine, this is made worse by Visual Studio/TFS/large solution I imagine if you has a lighter set of tools (vim/git) it could be much faster. Another alternative would be to find a way for 2 people to effectively work remotely on one machine.
    I wrote a bit more on it here

  • Paul Dolman-Darrall

    Never understood why remote pairing is controversial.

    In gaming, like World of Warcraft, it is common. What we also know, is that high communication channels improve pairing in that scenario.

  • Joshua J. Arnold

    It no doubt helped immensely that the pair of you already knew each other quite well, and have worked together in the same place many times before. If you had been complete strangers before attempting to pair up remotely I’m guessing the result wouldn’t have been quite so successful. It can work (Torvalds and co prove that), but it takes longer I think.

    I’d suggest there’s no substitute for getting to know someone face to face…

Leave a Comment

Not All Variation is Evil