verything You Wanted to Know About Pairing On a Scrum Team
The Agile Weekly Crew discuss pair programming on a Scrum team.
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
Dealing with distractions
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 so