I had the chance to run a 90 minute session at this year’s Agile Conference in Chicago. The conference as a whole was an terrific experience but here I’d like to talk about my session, and what I learned from it.

The session focusses on the barriers that prevent people from adopting pair programming. I’ve encountered a whole variety of reasons for this in different teams I’ve worked on, and the first part of the session involved the participants working in groups to talk about specific characters I’d created who exhibit some of these problems.

We used these discussions as a catalyst to look over the general set of issues that can be a barrier to people’s adoption of pairing. We then went on to talk about tips and tricks for tackling these issues, but I’ll save those for another post.

Here’s what we came up with.

Issues

Lack of Feedback Within the Team

Trying out a radical new practice like pair programming can feel pretty disruptive to some people. It’s important when a team is going though such volatile changes that they get plenty of opportunities to feed back to one another about how it’s going. It’s also important that they recognise the benefits that pairing can bring for them. Offering pairing as a solution to a problem that the team has identified for itself will make for much more enthusiastic adoption than simply mandating it as a necessary agile practice.

Lack of Management / Team Approval of Pairing as a Valuable Practice

Again, if the team doesn’t recognise that pairing will help them, they’re unlikely to really give it an enthusiastic - and therefore successful - shot. More importantly, if management isn’t actively encouraging teams to try the practice out, it’s likely that at least some of the team will be reluctant to try it for fear of displeasing their boss.

Lack of Trust in Team from Management

The benefits of pairing are counter intuitive: two people working together are actually much more than twice as productive as if they were coding solo, yet this is not obvious to the causal or cynical observer. Management don’t necessarily need to understand this, but they certainly need to make the team feel trusted to make their own decisions about whether the practice can make them more effective. If the team don’t feel trusted by their management, they’re unlikely to try out a practice that can seem mysterious and even frightening to the uninitiated.

Lack of Trust Between Team Members

Pair programming brings people much closer together than they might normally have to be in a work situation. Thoughts and opinions are shared in rapid succession about quite subjective issues. It’s important that team members trust each other in order that they can settle in to this new level of intimacy.

Lack of Respect for Cultural / Gender Differences

Again, the level of intimacy between team members that paring demands can cause problems when people fail to consider one another’s backgrounds. Different people have different needs for personal space, for example. People with an intense need for personal space may be put off pairing simply by the idea of having someone sitting in such close proximity to them. Pairing that person with someone who is from a very tactile culture can be a disaster! It’s important to respect and work around these kind of issues as they are usually deep seated and cannot be simply rationalised away.

Need the Right Incentives

Often team members, especially from organisations used to a more traditional way of working, can be given incentives that don’t make paring the obvious choice. If people tend to be singled out for praise for delivering a particular feature, for example, it’s likely that they will be keen to own features by themselves so that they can take all the credit.

Lack of Experience at Pairing

There are some basic protocols that make pairing work effectively - talking about what you’re doing; swapping the keyboard when a new test is written or a test passes for the first time; taking regular breaks - but these are tricks that people tend to have learned though experience. On a team full of people who have never tried pairing before, you can expect some fairly basic mistakes to be made that may make pairing feel less enjoyable or effective than it could be.

Fear

This seems to be a significant barrier for people who’ve never tried pairing before. Some people are simply afraid of the unknown - they may have been programming solo since they were quite young and are really used to this way of working.

The other big fear is the one of intimacy - having to share your ideas and opinions freely and have them instantly judged by someone else is a much more direct way of working than many programmers are used to. This goes along with a fear of looking stupid - many programmers fear their ideas or designs are not that good, and would rather not have to demonstrate this to a pair.

A more sinister fear is the one some ivory-tower builders can have of losing their job security - by being forced to share their ‘unique’ domain knowledge with their team members will they lose their power and potentially their hold on their job?

Autism

Joseph Pelrine has talked about the higher-than-average incidence of Asbergers Syndrome or other ASD psychological conditions within the computer programming progression. People on the autistic spectrum demonstrate many skills that make them excellent programmers, yet they also suffer real barriers in communicating with other people. These barriers can make the close collaborative experience of pairing stressful for both them and their pair, and it’s important to be able to recognise the signs of this and work around them.

Need to Understand the Importance of Learning

A big part of the benefit of pairing is the spread of knowledge throughout the team, both about the problem domain and the technology being used. When an organisation simply doesn’t understand the value of learning, it may not yet be ready for the benefits that pairing can bring.

One of the main reasons I was drawn to adopt Ruby as my primary development language last year was the RSpec story runner, a fledgeling project to bring developers and users closer together with executable specifications that are easy for both humans and machines to read. I was really attracted to the community around these tools and the energy and focus they were putting into bridging that communication gap, and wanted to be a part of it.

18 months on and the RSpec story runner has matured into Cucumber, a hugely popular open-source tool for executing these tests. Ruby has made an excellent platform for Cucumber, the flexibility of the language and the collaborative open-source culture around it meaning the tool has matured rapidly, with over 177 different people contributing code to the project to date.

Over the summer, Cucumber began to speak to applications written in other programming languages than Ruby, by adding an adapter mechanism for the language in which the step definitions (the glue code which actually pokes around with your app) are written. Firstly this was done with JVM languages so that when Cucumber was run under JRuby, it could test an application via step definitions written in Java, Groovy, Clojure or Scala.

This still left .NET teams out in the cold though. One approach would be to run Cucumber under IronRuby but having tried some experiments with it, it feels like the slow boot-up time of IronRuby will make for frustrating TDD cycles right now. In response to this, I hatched a plot with Aslak Hellesoy, the creator of Cucumber, and Richard Lawrence to create a generic wire protocol for Cucumber which would allow it to invoke step definitions against a remote service written in any language. Over the last few months Richard and I have worked on the protocol, and at the same time Richard has built the .NET tool (Cuke4Nuke) that allows you to implement and serve up your step definitions in C#. Richard has just published an excellent short screencast which shows how to use it. If you’re writing .NET and would like to enjoy the warm glow of Cucumber, you owe it to yourself to take a look.

As a coach, I like to introduce new practices only when I can offer them as a solution to a problem that the team has identified for themselves. On my current team we’ve been tracking our Work in Progress (WIP) for some time, but we’ve never taken the step of systematically limiting it.

At a recent retrospective it became clear that everyone was feeling the strain of having too many things going on at once:

• Our velocity was really bumpy, with no releases for days at a time, then suddenly several stories going out at once in a big batch.
• Our QAs, who run final checks on stories before they go live, would be periodically hit by a tidal wave of work when one of these batches came through
• Stories would languish in the ‘nearly done’ stage, with developers too distracted with new work to finish off final copy changes and tweaks.
• There was a general feeling of being constantly distracted.
• We were doing less pairing than we wanted: the person you wanted to pair with always seemed to be doing something more important.
• We weren’t getting as much done!

We all agreed it was time to set a WIP limit.

So we studied our Cumulative Flow Diagram (CFD) chart, and looked back for a time when we’d been more productive. We used the measured WIP from that time as our new limit, and stopped taking on any more work until we’d drained down our number of stories in progress to that limit.

Here are the benefits we’re now enjoying:

• Our delivery velocity is smoother
• We’re pairing more again
• Our stand-up takes a sane amount of time, and people aren’t fidgeting and bored because what’s being discussed is more relevant to more people
• The cycle time to get a change through the build and into production is now way shorter

It’s too early to say, but I think we’re also starting to get more done again. Little’s law would certainly indicate that this is a likely outcome.

XtC are pleased to announce the 9th consecutive London XpDay:

The Agile community has grown and matured over the years we’ve been running XpDay, so now we want an event that helps practitioners collectively advance the State of the Art.

The first day will consist of programmed sessions, the second day will be an Open Space where attendees will discover more about the topics that interest them most. We have three remarkable keynotes lined up for this year: Mark Striebeck, Doron Swade and Terry Saunders. Of course, we’ll still have our famous evening social events.

– from Rachel Davies

The cost for the conference is £350. Highly recommended.

Scheduled Programme: http://www.xpday.org/programme

Booking Form: http://booking.xpday.org/registration.php

London XpDay: http://www.xpday.org

We all like usable software, but what about usable code? How do we test the usability of the code we write?

One way is to get another programmer to work with it. If a bug is discovered in some code you’ve recently written, instead of just quickly fixing it yourself, see how easy it is for someone else to fix. Write a failing test that isolates the bug, find a pair - ideally someone who has been working on something completely different - and let them loose on your code.

Try to resist telling them where to look - watch how easy they find it to navigate the code, find their way around it. Listen to their comments, and encourage them to start making little changes - rename things that don’t make sense to them, for example. Hopefully you were pairing when you wrote the code in the first place so the design will already reflect two people’s perspectives on the problem, but you often need at least three people’s input on a design before it really starts to become usable.

CITON (Continuous Integration and Testing Conference) Europe was one of my favourite conferences last year: A chance to hang out with some very thoughtful and experienced people in a close-knit setting. CITCON US has just announced the venue and dates. The conference is amazing value - free! - but the 150 places go fast, so keep an eye on the mailing list for when registration opens.

Organised and facilitated by Elizabeth Hendrickson this was a great group of people to meet with. Elizabeth ran the day as an open-space, a format which I really enjoy, and which worked very well for such an interesting, intelligent and enthused bunch of people.

I came away from the day having had the chance to discuss, in depth, some ideas that had just been floating around in my head as vague notions. This is the really great thing about getting groups like this together - you find that there are actually other people who you can talk to about these crazy ideas.

We also came up with a fantastic new feature for Cucumber. More on that later.

Long-running acceptance tests suites are a problem we’ve spoken about before. Following these discussions, I’m now more convinced than ever that the feature missing in most of our automated acceptance testing tools right now is memory. By remembering test results from previous runs, and ideally the source code changes that were associated with that run, we can build a model of the tests and their relationship to the code. We can use this to help prioritise the tests to optimise for failing fast - pick the tests most likely to fail and run them first. This is the strategy JUnit max has adopted, and it really makes sense to me. I look forward to getting some time to develop these ideas further.

I ended up in a session about using Cucumber with .NET which I think Aslak and I had both expected to be about explaining the new abstraction of ‘programming language’ in Cucumber, which allows step definitions (the glue that allows the cukes to drive your app) to be written in a variety of languages. In fact, the feedback we got from the assembled was that it would be even better to offer a generic ‘wire level’ language. This would then allow people on any platform at all to work with Cucumber - currently only platforms that run Ruby will work - and to write their step definitions without having to touch Ruby at all.

This is an idea that could only have emerged by getting that group of people together. Richard Lawrence and I paired up there and then and got to work on the new feature, which I fleshed out during more pairing sessions during the week with Aslak and Richard. Watch this space for more details as we get this working.

Did I mention that I like pair programming? Here are some reasons why it’s good for you and your boss.

More Trucks

The higher the truck number of your team, the more resilient it is to losing people. Pair programming spreads knowledge of the code around the whole team meaning each team member has a much more broad knowledge of the system than on a traditional team.

Free Training

Every time I pair with someone, I learn at least one new trick, be it a keyboard shortcut for my editor, a new command-prompt command, or a language idiom. This training costs nothing and builds the confidence of even the most junior team members who always have something to contribute, to say nothing of how much they will learn from sessions with their more senior colleagues.

Team Bonding

Working together in pairs breaks down barriers between people much more quickly than when they are working alone, and provides a natural environment for teams to learn to trust one another, and enjoy one another’s company. These are vital attributes that will get your team though the tough times, ensuring they can pull together when necessary.

Better Designs

Experienced programmers know that coding is much more a process of design than of mere implementation. When subjective design decisions are taken by at least two people on the team, those decisions have much more authority and are more likely to be understood and accepted by the rest of the team than if they had been taken alone. When one member of the pair has a good idea for a solution to a problem, this may stimulate an even better one from their pair. Science says so.

Less Bugs

The perpetual code review that’s done during a pairing session not only produces better designs, but it also catches a lot more defects as they are written. Pairs will tend to write more thorough automated tests, and are more likely to spot holes in logic that would otherwise have to be picked up by subsequent manual testing.

More Fun

Generally, programming in pairs makes for more a more relaxed and enjoyable atmosphere in a team. People become comfortable with their own strengths and weaknesses and are able to talk and joke about their work much more readily, since they are already used to that dialogue. This is obviously terrific for morale and staff retention.

More Focus

Pair programmers do not check their emails when they’re waiting for a script to run, disappear into their inbox for 20 minutes, then come back and have to remind themselves what on earth they were doing. When they hit a little break-point, they review what they’ve done so far and make a plan for their next steps. They stay focussed. Twitter can wait.

As I may have mentioned I’m running a session at Agile 2009 called ‘Debugging Pair Programming’. There’s a preview of the session tomorrow night at Skills Matter and I’ve just finished preparing for it.

Mind if I run a couple of things past you?

Continue Reading »

I’ll be running a preview of my Agile 2009 workshop ‘Debugging Pair Programming’ at Skills Matter on Monday 10th August.

If you’re on a team that’s using or trying to adopt pair programming, this is a great chance to explore and understand some of the complex reasons why this is such a difficult skill to master.

The session is free, so sign up soon to avoid disappointment: http://skillsmatter.com/event/agile-scrum/debugging-pair-programming