Clayton Lengel-Zigich and Derek Neighbors discuss numerous items around Pair Programming on a SCRUM team.

• Is agile just for teams?
• Pairing good traits
• Pitfalls found while pairing
• Good pairing habits
• Pairing in a chaotic environment
• Various pairing techniques
• Physical pairing station setup
• Remote pairing
• Dealing with distractions

Transcript

Derek Neighbors:  Welcome to another episode of the “ScrumCast”. I’m Derek Neighbors.

Clayton Lengel‑Zigich:  I’m Clayton Lengel‑Zigich.

Derek:  Today, we’re going to talk about a couple things. First, we’re going to field a question, and the question is, “Is Agile just for teams, or can it be used for solo workers also”?

Clayton:  My experience with this is, I’ve done a lot of stuff, just personal projects, goofing around basically on the weekends, and I try and use some scrum process. The thing I’ve noticed is that, I feel like at work I’m a very disciplined person. I have lots of discipline in that regard, and blah, blah, blah.

When I try and do it by myself, I feel like either I have no discipline or I don’t have enough. In my experience, I’d say that if you’re not a very disciplined person, it’s difficult to make it work. There are some benefits from it as far as…everyone has an experience with a personal project that just languishes and goes on forever, and you never finish it. There’s probably a lot to be said that Scrum could help you out with, in that regard. I don’t feel like I have the discipline to do it, myself.

Derek:  A lot of agile techniques work fairly decent. In a solo environment, a lot of the principles do unexpectedly iterate. Using iterative approach, time‑boxing, continuous improvement, all of that stuff translates perfectly. When it gets a little bit more to estimating and doing some of the heavier parts of the methodology, it’s much more difficult to be disciplined about that, in a solo environment. It’s feasible when it works, but you have to have a lot of discipline to do it.

Today, I wanted to talk a little bit about pairing. Clayton, as a team lead you do a lot of pairing on interviews, here at Integrum, and you get to see a lot of pairing. I wanted to talk a little bit about what you think are some traits that make somebody a good pair.

Clayton:  In pairing the most important one is being engaged. That’s a broad term that means the concept of being a good listener, paying attention, being interested in not only what’s going on, but also…when’s someone’s driving, or they’re solving a technical problem, it’s easy for them to get in that mindset. You have to be able to switch back and forth, and switch modes. If you’re the person, you’re not driving, you’re the passenger, you need to be able to keep focus on maybe some certain processings, or the non‑technical things.

Obviously if you are driving, being able to get into that mode and not worry about those things. Let someone else take care of that for you. I think that’s a big one for me. Outside of that, I would say that being a good pair is one of those things where I don’t think there’s a real good book answer for it.

If you were to try and do something by the book or write a list of things that you can do to be a good pair, that would be really hard to come up with that list. It’s more of a matter of good communication, good soft skills, those kinds of things. I think that’s most of it.

Derek:  What are some of the pitfalls? You get to pair with a lot of people who are new to pairing. What are some of the things…when you see two people that maybe have never paired before and don’t necessarily have good habits, what are some of the common things that you see where people fall down in pairing?

Clayton:  The driver‑passenger role is one that people don’t do a very good job of. Especially people that are new that say, “I’m a coder; I’m a programmer.” They have this idea of what that means to them. Then when they’re not driving, there are some people that fall in the subset of, “I’m going to micromanage every decision that you make while you’re driving, because that’s not how I would do it.”

There are some people that say, “Oh sweet, you’re doing all the work. I’m going to kick back and check my emails,” or whatever. Even in the pairing interviews, we notice that people, obviously they’re there for an interview, they’re trying very hard to be polite and engaged, and all those things. You can definitely tell when they get the keyboard, you mention something, “Oh hey. What about this?” and they can’t even hear you.

I think people don’t have that, not listening when they’re driving. Other than that, pitfall wise, people fall into categories of being a bad driver; just going down some rabbit hole ignoring what the other person is saying. The passenger plays an important role in guiding you, especially if they say, “Hey. This doesn’t look like a good path to go down.” Bad drivers just ignore that.

The one that we see the most is probably bad passengers. I think body language is a huge thing. If you ever want to evaluate people that are pairing, just look at the driver and the passenger. Usually the driver is leaning forward, because they are using the keyboard.

Most of the time, you will find the bad pair who are the bad passengers, are the ones that are leaning back. They don’t have their shoulders facing the workstation, that kind of thing. The people that are leaning forward, have the same body posture as the driver, those are the ones that are probably more engaged.

Derek:  In dealing with a lot of people that are new to pairing and getting them up to speed, what are some things that you found have been successful in getting people up to speed with the concept of pairing in a fairly short amount of time?

Clayton:  Brief overview of the role of the driver and passenger. A lot of people view pairing as, “Half the time, I’m working. Half the time, I’m watching someone else work.” They don’t understand what really they’re supposed to do when they’re not actually coding. Getting people to understand that is very important.

After that, I would say that there are bunch of games that we’ve had some good experience with. Ping Pong Pairing where one person writes the test, say a failing test, and then, the other person has to write the implementation for that to make the test pass. That’s a great way for both people to be engaged and both feel like they’re doing something.

Another one would be switching off at predetermined intervals. Say you set a timer for 15 minutes and it’s not this thing where the timer runs out and the person that’s driving says, “OK, cool, give me another two minutes, I’ll finish this up.” It’s literally, 15 minutes is over and slide the keyboard and mouse over and the other person has to just pick right up.

You can’t…it’s very obvious that you’re not being effective when the first 15 minute bell goes off and the other person is like, “Oh. What was on the menu?” They don’t have any idea. I think that’s a really good one to keep people engaged. I’m trying to think of some of the other games we played.

One that’s good, actually, for a lot of people have a criticism of pairing, is that they feel like, “Well, I’m really good at what I do. I’m a really good developer. I don’t want to pair with people that aren’t very good because it slows me down.” One thing that you can do to improve those people on your team that may be more junior or don’t have your level of expertise, which you probably don’t have any, but you think you do.

But, those people, to train them or to help them out, would be to do the distant passenger. A lot of times, I see that when people are in that situation, pairing the person that’s the more senior person will be micromanaging and driving and basically, telling them, dictating what to type.

“You should write this method. You should return it this way. You should use the turner in, blah, blah, blah. If you talk at a higher level and say, “Well, we want this model to be able to…we want this instance of this object to build or respond to this method. I want it to return a hash of these things.”

When you speak at a high level like that and then, you let the person go do the implementation. Whether or not you’re doing TDD even, but let the person do the implementation and then, maybe set aside some time at the end to do some kind of code review of like, “OK, see how you did that. You solved the problem. Here’s how I would have done it.” Have that discussion. I think that’s really helpful when you have a mix of skill levels.

Derek:  One of the things we see, obviously, operating on the Gangplank because it’s pretty noisy in here. We’ve got a lot of people pairing in close proximity. One of the things that a lot of people ask me is, “How can your guys be developing in such louder, chaotic environment”

Maybe if you could explain a little bit about what it’s like to Pair Program in an environment where you’ve got lots of people Pair Programming in fairly close proximity and whether that positively or negatively affects productivity.

Clayton:  I’ll give an example, recently one of the guys on the team got everyone little Nerf guns that shoot darts. For the past two weeks, it’s been like every day, it’s people shooting darts.

You could be sitting there, trying to solve some complex problem and darts whizzing over your head. That’s the nature of the environment. I found that a litmus test for me is if I feel like I’m distracted or I hear people talking about, “I can’t get anything done today,” I feel like that’s not good pairing.

Or there’s a problem with their pairing because I notice that when I feel like I’m doing a good job and have an engaged pair and we’re really hammering things out, it’s almost like all that stuff just doesn’t matter anymore. It’s really easy to block it out, probably more than people would think.

You’ll notice that when people aren’t pairing, a lot of times people will put on headphones and try and get into the more traditional coder mentality of, “I’m going to go into my own little world, so I can’t hear or see anything. Don’t bother me kind of thing.”

When you’re pairing, you, obviously, can’t do that. When you’re pairing, you don’t really need to do that as much, in my opinion.

Derek:  What you’re saying is you like to look deeply into the eyes of your pair and have some tantric pairing going on and nothing else in the world exists except for your pair?

Clayton:  No, it helps if you have a little mirror, so you can glance at each other’s eyes every now and again. You put that above the monitor and you’re good to go.

Derek:  I think that’s something interesting. One of the things that I’ve seen people talk about are some different pairing techniques in the way of physically setting up how you are pairing, whether that be some face‑to‑face pairing, some potentially pairing without even a laptop or a machine in front of you to solve the problem.

Then, to go to actually pair to implement the problem. Have you tried any of those things and if so, what are some of your thoughts on those?

Clayton:  I tried the face‑to‑face pairing at one point in time. That was quite a while ago, I would say, before I was…I was trying things out. I don’t know. I hadn’t made my mind up really on pairing yet.

I found that to be distracting. It seems like the face‑to‑face stuff would be good and maybe it just was the person I was pairing with, but I found like it was more convenient to be looking up and away from what we were doing and doing a lot more conversational talking. That was probably the down‑side to that.

Other than that, as far as different pairing configurations, one technique that I had to do working with someone, this is easy to do when you’re pairing. People have a certain different degrees of personal space and that kind of thing. I had noticed that every time we sat down at the desk, this person would always sit in the middle and so it’s like I found that towards the end of the day, I would be pushed over to the side.

We got to a point where we drew some lines on the desk with some tape and we said, “OK, here’s our zone where we need to be and if we drift out of this zone, then one of us is going to be uncomfortable because we can’t see the screen or whatever.” That brought us actually much closer physically together in that regard. Then, we also made a rule that the keyboard had to be in a certain spot on the desk.

That was a way of balancing that stuff out so we could say, “We’re slightly off center from the desk and from the keyboard and the mouse and everything, but we’re still comfortable.” That cut a lot of problems out because we didn’t realize how much time we were spending nudging each other left or right and repositioning yourself through the day.

Once we set that ground rule, it was easy to be able to get going, keep going.

Derek:  That’s a good segue into the physical set‑up. Tell me a little bit about what your optimal pairing station is. Is it a one keyboard, one mouse, two keyboards, two mice? If you’ve tried some different variations, why you prefer one over the other?

Is it single screen, double screen, preference of one over other?

Clayton:  As far as the screens and work station set‑up, personally, when I was maybe younger, there was this dream of like I want to have 10 screens in front of me and that seemed so cool. Then, as I’ve gained more experience, if I just had one…we use iMac. The 27‑inch iMac, that’s got a big screen on it. Sometimes people load up that screen. Traditional set‑up is that screen and a secondary monitor. People load that stuff up with just tons of things.

I feel like it’s distracting for one thing. When I’m sitting on the left side of the station, I like big fonts and everything, but I have a hard time reading specific code or terminal or whatever that’s on the complete opposite side of the desk.

In that regard, I would prefer to probably have one monitor. As far as the keyboard stuff, I personally like two keyboards.

The reason I like that is because two keyboards, two mice. I’ve noticed that when you’ve got someone who’s pretty strong willed and they want to go down their own path, and they’re pairing with someone that maybe isn’t, maybe someone that’s more willing to go along with them, it’s harder for that weaker willed person to grab the keyboard if they want to take control.

If they have their own keyboard, it’s really easy to just press a key. It’s amazing how much you can screw somebody up by pressing a key or two keys. It’s kind of, “I don’t think we’re doing the right thing.” “No, trust me this is right. Let me keep doing”

You press command‑TAB and switch to whatever the other application is and bring it in focus and then, it’s like…it’s a total…it’s an easy way to have this stopping point of, “OK, put the brakes on. Let’s talk about this.”

Without having to physically, grab the keyboard from somebody.

Derek:  What you’re saying is dual keyboards prevent pair assaults?

Clayton:  There you go, yeah.

Derek:  One that a lot of people are probably asking at this point, remote pairing. Thoughts on having to pair remotely.

Clayton:  Every programmer that I’ve ever known has this ideal that, “My job is totally over the Internet, so I can work super effectively at home.” We tried that when people were sick or people are away or whatever.

It’s really difficult unless you’ve got…even with like the screen sharing and remote control that like, say iChat gives you or remote desk software or whatever, that stuff is really difficult because you get a little bit of lag and you don’t realize how much that effects the way that things look.

If someone is scrolling a web page and you can’t see things anymore or whatever, that’s really distracting. Then, I would say the good thing about it is that when you’ve got two people who potentially can control the mouse or the keyboard, having like a code order where you actually have to physically stop everything and say, “Mouse,” or whatever, so you can get control because, obviously, two people are remotely doing that, isn’t going to work.

I would say that’s nice, but overall, the negatives outweigh the positives as far as remote pairing is concerned.

Derek:  The last question really is distractions. How do you deal with distractions in two ways? One distraction would be somebody else on the team needs you for something. Instead of just interrupting one person, now they’re interrupting an entire pair. If it takes a certain amount of time to get back on task when you’re interrupted and now, you’re affecting two people.

What are some ways or techniques to be able to minimize that? Then, the second one is physical distractions, in the terms of, I’m going to say, near‑term problems, laptops, smart phones, things that, I think, as a passive pair are really tempting to get into.

What are some thoughts on mitigating those two things?

Clayton:  I would say that as far as…that one first, as far as the passive stuff where you…sorry. When people are distracted or tempted to look at their phone or their laptop or whatever, that’s something that is up to the pair.

Definitely, you’ll have situations where, especially if you have someone that’s driving that doesn’t really want to be pairing, when the other person looks at their phone, it’s like, “Thank God, I don’t have to worry about this person anymore.”

If you’re the kind of person that is…personally, I think that’s disrespectful when you’re pairing, you don’t want the other person just goofing off because then, you get into the mindset of, “Wow, pairing is really useless because I’m just doing all the work and this person’s surfing the Internet.”

People try and make a lot of excuses about it where they say, “Well, I need my laptop so that I can do research,” or, “I need my phone so that I can check my email because I don’t want to miss anything,” or whatever.

That’s a real concern, but it segues into the idea of solving the first problem where I feel like having some kind of consistent timer, that totally solves that problem. If you say, “We’re going to to set a timer every 15 minutes, we’re gonna switch pairs.” If someone walks over to you and says, “Hey, I’ve a question.” You can reference the timer and say, “Well, I’ve got 10 minutes left.” Usually 15 minutes or less, there’s nothing that’s so important that it can’t wait that much time.

If you’re worried about missing an email from a client or something, it’s pretty easy to say, “OK, we’re going to work for every 15 minutes, and then every 15 minutes I’m gonna check.” At most you’re going to go 15 minutes without seeing it. Which for most people is probably acceptable. I’d say that having the timer is really good and that helps solve both problems.

[music]

Derek:  We’ll see you next time.

Clayton:  Thanks.