Pair Programming: Four Eyes on the Code

Pair programming was seen as the primary way of distributing the know-how and tacit knowledge between the members of the organisation. Pairs were swapped after a few days and new pairs got to share their insights. The testers and the designers were partial to this knowledge sharing. When their work was suitable for pairing, they were paired up with the developers; at other times, they worked alone. The practice of pairing required that the physical Agile walls and the office space were organised in a way that enabled the teams to easily sit next to each other. One of the leads described his team’s behaviour:

There's a hum of activity. They’re talking all the time so if you sit beside a pod where there’s a lot of people who are pair programming, who are talking, they are talking all the time. Not all the time, but they are talking and discussing their approach, discussing their implementation. Sometimes they are working a little bit independently because ... for whatever reason, but it’s a very collaborative, communicative, noisy, experience, but it’s good. I like that.

At Extreme Inc., software developers worked in pairs for the majority of their time. The tasks, written on sticky notes, which were allocated to each pair, were attached to the Agile walls. Each team had its own wall. A delivery lead explained the development process:

We will start a piece of work. We’ll pick up a task off the board. You pair up and each pair has two monitors, two keyboard, two mice, but it’s one computer…. And from the wall you have picked up a task that you want to work on with your pair. As a pair, we talk through the task, how are we going to implement this. We talk through the test cases that we should consider. Some people like to do what they call ping pong: so one person will write the test, the other person will actually write the code that will make that test pass. Some people like to do everything together. They both write the code and they both write the test, and then they just share between each other who is controlling the keyboard at which particular time.

Developers enjoyed pair programming. Interviewees who were practicing or had practiced pair programming before described it as a highly collaborative activity, even exhausting for the first few months. But once the new developers had gotten used to the pairing, the pair programming was seen as the key to high-quality code and effective problem solving. A developer explained to me why he thought that pair programming was an effective way to develop and maintain the high quality of the code:

You pick up your silly mistakes, you’re less likely to get blocked on something trivial. It’s a good chance the other person will know what to do. It’s those times when you yourself know, would otherwise know what the problem is, but you get in that brain space where you just don’t see it, you’re just focusing on the wrong spots. So you start to build up productivity through there.

The testers and the designers had a modified way of pairing. Sometimes a tester or designer was paired with one person; sometimes they were added as a third person. One of the developers explained how testers and designers were incorporated into the paired work:

The way of working with the designers, it is a bit different – the same happens with testers, but it’s not like pairing with developers, where the pairing happens full time. But rather than them sending you an email, saying ‘I want this button moved ten pixels and this other button moved ten pixels, so that they align’ and ... stuff, and then you send back and it’s still not right. They just sit with us while we’re doing the UI changes. That way we are lot more efficient to come to the agreement upon result, rather than sending things back and over. So similar thing happens with testers. So we pair a tester and developer, we finish a story that we’re working on and we have embedded testers to all the teams.

One of the ways the developers and the designers interacted was nicknamed ‘rubber-ducking’. In this way of working, the developer would describe the way the code was constructed and explain the thinking out loud, as if they would be explaining their thinking to a rubber duck. The technique, as one developer told me, was sometimes used with actual rubber ducks too, in order to help clarifying the thought process that go into the coding. Modified versions of pair programming were extended to the DevOps internal and external collaboration as well. One of the members of the DevOps team explained the process:

So we don’t exactly pair program. We pair with changes… Any change in production requires it to be paired. So it is two people from the operations ... implement a change… So either they, sometimes they will sit together and discuss and think about the actual problem that they’re trying to solve ... and then implementation.

The tribes and the DevOps team formed the majority of the employees at Extreme Inc. In addition to these technical employees, there were other supporting teams. The business stakeholders comprise a variety of other members of the organisation, such as user experience designers, sales and marketing experts, risk managers, and team leads who participated less in hands on development and more in the planning of the products and processes. These stakeholders were not directly involved in the pair programming activities but worked close to the development teams. The organisational culture which valued physical presence, stemming from the pair programming activities, was seen as an enabler of collaboration with the others stakeholders as well.

For example, the head of internal auditing outlined that their physical presence in the premises, just downstairs from the development teams, helped them in being tightly involved in all development processes:

I don’t tell the technical teams how to implement control processes. I just go, ‘Basically, this is why we need to do it. This is the principle that we are trying to protect or safeguard against. Do whatever you need to do.’ Later, I'll come back and check that the feature is working, how you’ve intended it to work. And vice versa. They can always come see me downstairs, if they want to implement a new process, or they come up with a new concept. They will ask me

about the feature: ‘We are thinking about looking at this. Do you have any tips? Do you have any advice? Do you have any requirements?’

The pair programming method determined how the other Agile methods were applied in order to support it. The next sections will describe how Agile walls and meeting practices were conducted with regards to pair programming.