Introducing Pair Programming

[Robert Whittaker]

Good morning, everyone!

Here at On the Beach we have always encouraged pair programming, but I have very rarely seen it put into practice.

Now that I am a team lead, I thought it would be the ideal opportunity to make pair programming more of a natural habit for our programmers.

I know that forced pairing is not a good idea, but do you think it is okay in the short term to encourage the team to work together more?

I am one day in and I'm already getting some resistance.

The argument from the programmer was that they had had a bad experience with forced pairs in the past.

I reassured him that this was just in the short term and would become more natural with time.

Also, there are only three programmers on the team, including myself, what should the third programmer be doing while the other two are pairing?

The same programmer express a discomfort with having tickets on the board that were not being worked on.

I may have imposed a hard-line rule of "no production code without a pair".

Any comments would be appreciated.

[Sam Phillips]

Morning!

We implemented pairing at Shutl, starting just over a year ago, and have had good successes. It is okay to "encourage" a way of working - but encourage in the non-euphemistic sense. Here's some way to encourage:

* Create dedicated pairing stations. If the machine you're pairing on belongs to one of the members of the pair, it's not a neutral environment. It's their email that pops up, their tweets that show, their IRC. It's also their editor and their keyboard shortcuts. Create neutral pairing machines, owned by nobody, where each person has equal footing - one computer but two keyboards, two mice and two big monitors. This isn't too expensive - a mac mini can support multiple monitors.

* Once you have a neutral physical environment, you need a neutral programming environment. These were particular gripes here and I know members of the OTB team that have complex setups too - we had people with very peculiar setups, non-standard (mouse-less) keyboard layouts and aliases/bash configs that took years to hone and learn. I know this is a controversial opinion, but I am against all of this nonsense. It reinforces the idea that code is in people's heads waiting to mined - and the speed of the mining is what's important. Our pairing stations have all Shutl components and sublime, atom, rubymine and vim installed on them, and people agree at the start of the session what to use. It's a point of pride for many of our team that they can use any editor. We also have a few shared aliases that everybody can agree on, and boxen installs these and maintains them. Boxen is open to modification from everybody.

* Lead by example - this is easy. At the standup, see the feature that's coming up and just grab someone and suggest you pair on it. Not two other people... you and one other person. Do that for a morning and give and get feedback from your pair.

* If you're following github flow and pull requests, relax rules on code review. We don't require sign off from others for pull requests that have been paired upon. We always still open the PR and sometimes the pair asks for feedback, but mostly PRs are for information (and are opened and marked as "WIP" when the feature is started, not only opened at the end). Removing code review is an easy way to speed up development with pairing... but use with caution, obviously :)

* Make it clear that you want to try pairing as a tool to add to your team's arsenal. You're just increasing firepower. You don't have to pair on everything, and it's not a failing if people can't pair. Mostly, people don't pair *because they can't pair* - it's not taught well. Show why it's useful first, teach second, preach last. 

* Recruit for it - we explicitly test pairing in interviews. We've had people sit down in tests and immediately switch the machine/keyboard layout into their mother tongue, insist on using their personal vim config set, etc etc. That's a red flag.

* Bring in external evangelists. Pivotal Labs are new to London and a year ago they were looking for their first project - we bought them in to help with a green field project we wanted to run, but also integrated them with the existing teams with the explicit aim of teaching pairing. These guys are world-class developers and are taught/teach pairing as their full-time job. We had a couple of their team on site for a few months, and the "pairing is great, we can do it" attitude was very helpful. There are lots of good houses that can do this for you

* One particular way in which pairing is useful is onboarding new team members - people can get up and running really quickly when they're paired with somebody, and obviously a "buddy" for the first couple of weeks to show you the ropes and the lunch haunts is a good idea anyway. For existing team members, the burden of new people is reduced :)

Be honest with yourself on expectations regarding timescales. One year later, we pair most of the time. Three months after we started, we had some people who still didn't like it much. But, our staunchest critic (and the guy who's set up was completely unusable to another human being) is now our biggest pairer. But it takes time and it'll be frustrating along the way. If you didn't get resistance on day one, that would be bizarre to say the least!

Good luck and feel free to ping me off list if you need a hand. As you know, I have particular and extensive experience of OTB :)

Cheers,

Sam

--
You received this message because you are subscribed to the Google Groups "xp-manchester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xp-mancheste...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Drozdzewski]

Robert, 

Nice one for trying to promote pair programming. What other practices do you use? TDD or tests after? 

If you gather any rudimentary stats or full blown metrics, you should be able to show after few sprints/few months that the number of reported is down (or the grand sum of severity of raised bugs).

With 3 people you have to rotate but since it's a triangle make sure that you rotate in a fair manner, so that one vertex is not paired significantly more than the other. 

Unless of course it's you since you insist on pairing and still have to get their buying.

To get buying from the resistant developer about his issues/tasks not being worked on, just start working on his stuff first. It's very good that people ownership of their work. 

This also means that you need to rotate the tasks worked on in fair manner too. 

At the end of each stint of pairing (few hours) try discussing for 5 min what was good and what wasn't about the given piece of work in order to tweak things to suit the team. 

The unpaired dev simply has to work on their things, which could help with buying as they hopefully should see churning more work while paired.

Your attitude is the key here.

On 18 March 2014 09:38, Robert Whittaker <cyclists...@gmail.com> wrote:

--

You received this message because you are subscribed to the Google Groups "xp-manchester" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xp-mancheste...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Daniel Drozdzewski

[Carl Phillips]

Hi, 

Maybe would have been beneficial to market it to the team as a fixed term experiment, to reduce their unwillingness to try it?

As one of the programmers on the inside, I'd have also tried to do it stealthily by just asking someone to come and help me with a problem or bit of code, and then when done, asked the other. Rinse and repeat until it's the norm. 

Another thought is to have instigated paired kata's to get people used to the idea and comfy, away from prod code in the first instance. 

Don't worry about the 3rd person yet. If they don't want to pair, it's an escape whilst they make the leap. 

Carl

Sent from my iPhone

--

[Ian Moss]

Rob, you are amazing for even trying!

 

Perhaps, try it for a couple of hours and switch til everyone has paired with each other. Might keep it fresh.

Everyone has different strengths, so having the everyone in your team aware of all the problems is going to be amazing at getting them all solved. Perhaps after a complete rotation it'll help them see that too?

For me, I just see it as a close knit team. I had a request for a seperate keyboard when trying recently. So, that's something to bear in mind. Also make sure everyone is comfortably seated i.e. wide enough desks, and can see the screen without stretching their necks - perhaps you may need a larger font size than when it's just yourself.

I quite like it when one person is coding, and the navigator is looking ahead and looking up APIs etc on their own machine, and then IM'ing accross the details of the methods needed. I've no idea if that's part of official pair programming how-to's though.

 

Is it that the tickets on the board are causing discomfort because they're overwhelming the developer who feels the need to think about them? Perhaps they can be pushed back into a backlog that's clear demarked to be in-the-future...

Anyways, never had any formal edu in this, so I'll bow out and let you find some pro advice.

I'm sure you'll find people in other teams within the organisation who'd like to try pairing to swap-out with any that have long-term resistance to the idea.

 

Take care & good luck,

Ian.

[Neil Kidd]

Hi Robert,

My tuppence worth:

Encouragement is a good way to approach it - forced is not.

Pairing can be damned uncomfortable, with various aspects coming in to play, such as personal space, ownership, personal configurations, feeling stupid when you get stuck etc etc.

At my last place I recall one member of the team was particularly uncomfortable with pairing. A few years on, when he left and went to his next job he told me he missed it! He quite honestly said to me "You'll be surprised but ..."

I'm with you on a common desktop configuration - consistency is key. We had a common image that every dev machine was installed and updated with. The team agreed, easily actually, on the setup. It also made life so much easier from both re-installation and disaster recovery perspectives.

I also have to agree with Ian - on the "close knit team". Part of this is for the common good, what's good for the team is good for company and for me so to speak. Also I have never worked with anyone that can't teach me something new!

You ask "... what should the third programmer be doing while the other two are pairing?" Fairly recently I was in the very same situation. What I did was the "Scrum master" type of stuff looking for bottlenecks EG:
* Prepping the next piece of work in the pipeline. Things like making sure all the required docs and accounts were in place.
* Occasionally spiking a solution.
* Knocking off some tasks on my own then switching into the pair. Doing this ensures everyone gets a chance to both pair and work alone.
To be honest I'd try and do the "dirty jobs" to make the teams life simple.

Best of luck,

Neil.

[Gemma Cameron]

I'd also like to add that pairing is exhausting. 

All of a sudden you're concentrating 100% of the time, with no twitter/fb breaks when a notification pops up.

Turn off the notifications on the pairing station.

Use Pomodoros to give regular breaks.

Watch out for bad pairing smells - is someone hogging the keyboard? Is the more experienced person driving and losing their navigator? Is the navigator on their phone?

There's loads of remedies for all these problems, such as letting the novice drive and using swapping the driving regularly (ping-pong with your red-green-refactor steps). It would also be good to swap pairing at least every day… Some people practice promiscuous pairing and swap every 40 mins or so.

As we're all finding with the arguments over "agile" on social media at the moment, putting labels on stuff can be a bad thing. Maybe not calling it pairing and dressing it up as collaboration or something. A lot of the benefits are knowledge sharing and discussing ideas and finding a better way to solve a problem with the two heads are better than one…?

Well done Rob! ( :

I also liked all of the suggestions coming through.

I'd be *really* interested in us looking into doing a professional pair swap within our community. i.e. I would love to swap with someone at OTB one day, so I go in and work there, and one of your debs comes over here to spend a day pairing. Thoughts?

On 18 Mar 2014, at 09:38, Robert Whittaker <cyclists...@gmail.com> wrote:

[Ash Moran]

On 19 Mar 2014, at 09:59, Daniel Drozdzewski <daniel.dr...@gmail.com> wrote:

> With 3 people you have to rotate but since it's a triangle make sure that you rotate in a fair manner, so that one vertex is not paired significantly more than the other.

A policy I’ve found very effective is the Least Knowledgeable Developer Rule. The person who knows least about a problem stays on, and the other developer rotates out. Combined with Promiscuous Pairing (rotating every 90 minutes or so) you can increase your truck number to number of developers in your team in a remarkably short period of time.

> To get buying from the resistant developer about his issues/tasks not being worked on, just start working on his stuff first. It's very good that people ownership of their work.
> This also means that you need to rotate the tasks worked on in fair manner too.

Daniel - I believe the comment you’re replying to here is this:

On 18 Mar 2014, at 09:38, Robert Whittaker <cyclists...@gmail.com> wrote:
> The same programmer express a discomfort with having tickets on the board that were not being worked on.

… which I interpreted slightly differently. I thought it meant that with 6 developers and 6 tickets, you keep 6 tickets on the board, even though some developers are pairing. (Which you just shouldn’t, unless you like having work sat around rusting.)

Either way, I don’t think ticket ownership and pairing are compatible, if ownership means delivery responsibility. (The only exception might be if “ownership” meant having the final veto over marking the ticket ready to progress.) But then, I don’t believe delivery responsibly makes sense in the context of a software team. Tickets can be held up for many reasons unrelated to the developer responsible for them, so it subjects people to the whims of fate.

Pairing subordinates individual developers’ egos to the goal of delivering software. If anyone is still wondering “How will this reflect on me?”, then the culture and the actions are contradicting each other, and it will fall apart, with the stronger of the two winning.

> At the end of each stint of pairing (few hours) try discussing for 5 min what was good and what wasn't about the given piece of work in order to tweak things to suit the team.

Agreed, I’ve found this is a helpful practice with anything that has long term gains. It’s easy to see problems that come up, but time *not* wasted is largely invisible. It can be useful to note down anything that pairing caught or improved that wouldn’t have happened otherwise, along with an order of magnitude estimate of how long it would have taken to fix if it had slipped through. Consciously appreciating situations like “Wow, I would have wasted all afternoon on this wild goose chase if you hadn’t been sat with me!”, or “Having to explain this to each other means we removed that really ambiguous method name at last” counterbalances the obvious costs of pairing.


Ash


--
http://www.patchspace.co.uk/
http://www.linkedin.com/in/ashmoran

[Ash Moran]

On 19 Mar 2014, at 14:33, Gemma Cameron <gemma....@gmail.com> wrote:

> I'd also like to add that pairing is exhausting.

That’s a good point I’d forgotten. Fortunately practice increases your stamina like anything else, but with someone not used to pairing it’s worth limiting it to 3 hours a day or so. (Otherwise it’s like “going out for a quick jog” with a marathon runner.) I can pair for up to 6 hours a day now, before that I was completely drained half way into the day. It’s good though, I prefer feeling mentally exhausted after a solid block of pairing than being physical restless and lethargic after an unproductive day coding on my own. (Unexpected benefit of pairing: you can reduce the length of your working day and still get more done.)

[Ian M]

Any update Rob? Thought this was one of the most interesting threads I've seen around for awhile :)

[Robert Whittaker]

First off, I would like to apologise for not responding to you guys earlier.

With the day-to-day getting in the way, I had completely forgotten that I had posted until I came back today.

Unfortunately, I ran out of energy, gave up, and the experiment failed.

Reading through your comments, though, has renewed my resolve and I am going to try again today.

This time, I will keep you guys updated.

I also emailed a link to the conversation around our larger development team and have received some encouraging comments.