Lesson: Agile Development with Ian McFarland

Step #9 Pairing: Pair programming fundamentally changes the human dynamic through which software is produced

Another thing that's really interesting that happens with pairing which is sort of gets at the dirty secret that stuff that we do in businesses is really just about people. People are confused by the fact, the demonstrable fact that a pair working on code is faster than those two same people working on two different pieces of code. There's a whole other reason in terms of concurrency that we can talk about in a second. But the real core reason that I've seen over and over again is about focus. When you have two people pairing, the likelihood that you will lose focus and won't be working on the problem that you were trying to solve goes way, way down.

Having two people sitting at the same keyboard and I am just painting the picture of what pairing looks like. In a typical healthy pairing environment, you have usually one computer, two people side by side, two keyboards, two mice and they are working on the same computer. Keyboards just go in the same computer. One text editor doing a code, they are running the app. They are really using the same computer and they both have the ability to control it at any time. This sounds weird when you haven't done it but it's incredibly natural when you get into the flow of it.

People ask the question "How do you know when you are supposed to be the one typing?" Or "Do you formally transfer control back and forth?" And some people do that, and I think that's okay but it's not necessary. It turns out that people are incredibly good at noticing signals from other people about when it's their turn to type or talk. Not everybody and I am a programmer so I think I can say this, there are programmers who don't have the best social skills around some of these stuff and so that kind of rapid trade off does depend on having people who are capable of doing that. But when you get into that kind of flow, it's a very natural give and take.

Sometimes you will be talking about an idea and it's easier to express in code because you are saying, “I am thinking this and I am thinking like this,” kind of implementation and then somebody says, “Yeah, yeah it's a good way. What about this? This isn't right, what about this term?” And you go through. It's very dynamic. It's kind of like working across the table on a puzzle, something like that. It's very engaged, very dynamic way of working. What's interesting is every time I have implemented this in a new team, what you end up seeing is people end up one, again, super focused. There's a bunch of productivity that happens. Its things that are unexpected, I mean they are expected because I have seen it a thousand times but you wouldn't necessarily think nobody on your team responds to email during the day.

If you are a manager who has just implemented a pairing, you will be kind of surprised; you had this question you thought was really urgent. So you send it off to people and you didn't care until the end of the day it's like, "Why are they ignoring me?" No they are not ignoring you, they are focusing on their work and they're focusing on programming and by the way, if you wanted to have an answer to a question, walk over to the person and say, "Hey what about this thing?" The nice thing is because there is a pair, only one person puts their head up and says, "Oh it's over there." The other person stays contextualized and that person comes right back into the zone and is in state, really like focused on the problem right away. It really fundamentally changes the human dynamic through which software is produced.

The question of how often to pair comes up a lot. Pairing all the time is great. I'm in general, an advocate for pairing all the time. I think it produces really, really good results and on some level you should ask yourself is there a reason to not be pairing. There is some stuff that's like, "Well I can just sort of hack through this stuff on my own." Different teams have different structure around this, but I actually really advocate for fairly heavy, not 100% of the time, but mostly you should be pairing. Again I think part of it is the focus reason, I mean, even if in theory this is a totally simple thing to do and doesn't need two people's attention, it goes a lot faster if two people are working on it; they just pound through it.

Being able to solo when the other person's not around is useful. I've seen teams get really dependent on their pairs and I can't tell if that's healthy or unhealthy honestly. I think it depends, but the ability to still execute when there's not somebody else there is great. But in general I haven't seen a lot of drawbacks. People talk about drawbacks, people tend to not necessarily want to pair all the time, and I suspect that part of it is, it's just too much engagement for people. Maybe having a holiday from pairing, and honestly maybe it's more, "Why don't I go and work on my side project for an hour and not be sitting with somebody all the time." If it's just over exposure to people, maybe that should be solved with shorter work hours or something else.

The fluidity and dynamics of pairing are interesting; there are a lot of different layers to the dynamics of pairing. One part people bring up is that sometimes there is somebody you really enjoy pairing with, and you'll tend to gravitate towards pairing with them. That's healthy, but it shouldn't happen all the time. Some pairs mesh really well together. The same way you don't want one rock star developer, who is producing a bunch of value but it doesn't fit with what the rest of the team is doing, really you're trying to make the whole team productive.

So the idea of keeping a lot of rotation, you're rotating for a bunch of reasons. One, you want more different pair organisms. Every time you combine people in a different way, you're producing a different sort of combined skill set so you have this whole set of different pairs. In a four person team, you don't just have four pairs, you have six different pairs.

You have a lot of different pairing opportunities inside of a team. My favorite team size is six; six developers, three pairs is the maximum number where there is no additional management overhead that comes into a team. If everybody is pairing all the time, and you're rotating all the time, it's interesting to observe but there's this higher level of communication where everybody just seems to know everything about what's going on in the code base by rotating.

I don't think this should be terribly structured, but rotating, splitting pairs at lunch, rotating everyday at the beginning and the middle of the day is a really healthy dynamic. It's okay for one person in the pair does not stay on the task until it's done because the other person has context. Sometimes people really want to finish a thing and that's okay, you don't want to be super rigorous and structured about it. What you do want to do is make sure that the team is rotating regularly and that people feel they are getting enough rotation and that the knowledge transfer is happening.

So again, I usually start more prescriptive and once people get a feel for how it’s working relaxing the prescriptive nature of it is a really healthy way to go. I find this is in general true when implementing Agile; usually you start with a lot of structure, just so people get a feeling for the flow. So you start with a weekly iteration planning meeting, and then it goes at this time and we know all the things that are going to happen and we start with a lot of story planning. What ends up happening is people internalize it really rapidly and then you don't have to create ceremony around it anymore once people really get it. And then people will internalize it and will know how to estimate stories, they'll will throw them into a backlog and the product owner can prioritize them whenever out of band and it all just sort of happens fluidly.

When teams are in flow, you get the best output. There's lots of research on that. People make a lot of assumptions about what the right pairs are. How does it work when two really talented people work together, how does it work when one senior and one junior person work together. People usually assume that the junior person is going to do all the learning and not provide very much to the pair and that the senior person is doing all this transfer to the junior. In general, there is some truth to that. The junior person will tend to learn more from the senior person but the fact is the junior person is a full part of that pair and they're asking often the dumb questions that is the right dumb question to ask, like "Why don't we just write that to a file?" The crazy awesome developer designer guy is going to go and think of this really much more complex solution and sometimes it’s the junior person that says "Can we just write that to a file?" And they're like "Oh yeah, we can just write that to a file, that's the right solution for right now" and maybe the other stuff gets implemented later, maybe it doesn't.

That kind of pairing is valuable. Pairing across similar skill sets is valuable because you get into a zone and play off each other's depth in an area. Cross skill pairing is really great because people from both skill sets learn about the other skill set and by having a lot of dynamism you get a lot of these different factors and you're producing this better and better team. And again, it’s the team throughput that matters; it's not the individual developer throughput or the individual designer throughput.

The other thing is you're building a lot of trust and the people who are really good everyone knows they're contributing. In well functioning Agile teams it's not a blame culture, it's very much a trust culture and people are very honest about the things that didn't go well last time so they can continuously improve. That whole notion of continuous improvement is a huge substrate of the Agile space.

When you look at really why pairing is as effective as it is, there's lots and lots of reasons that pairing has an impact on throughput. One of the least expected or one of the least obvious I think going in for me at least, really has to do with the amount of workable surface area that the problem has. In any software project, there are really a limited number of things that people could be doing concurrently that moves the ball forward. It's a confined space. I'm working on the video production pipeline. I'm working on the commenting system but a typical piece of web software where people put difficult startup, doesn't have 20,000 things to be working on. It has like three. Sometimes there's only one. Everybody's waiting for the log-in system to do something or something like that.

By taking two developers or a designer and a developer and combining them into this one entity that's doing one thing and doing it twice as fast or more than twice as fast, you haven't changed the aggregate throughput much. But instead of being able to only field three people on a team on the three pieces of workable surface area, you're actually able to field six people on a team in three pairs; they're each working on one piece of separable, executable workflow. That's a subtle other advantage. Pairing has all sorts of interesting advantages but that's one that I think took me the longest to notice as an incredibly powerful tool.

The fact is, the throughput that you get from a team larger than six, tends to fall off incredibly rapidly, and it really is a question of how do you factor what you're doing into small teams. Again, six people pairing, there's not really a communication overhead layer that you need because there's enough pair rotation, everybody's seeing everything especially if you're rotating every half day. There's enough pair rotation that everybody knows what's going on in the code and natural conversations happen. It's also just a social team size where people, one, feel responsibility and ownership. One person not performing, it's going to be really obvious to everybody, not in a negative way but there's a positive peer pressure to contribute to a team that in a team of 60 goes out of the window.