Extreme Programing (XP) Practices with Arlo Belshee

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Derek Neighbors: I’m Derek Neighbors.

Drew LeSueur: I’m Drew LeSueur.

Clayton: Joining with us today, we have Arlo Belshee. Arlo, can you tell us a little bit about yourself, where you are, where you work, what you do, kind of thing?

Arlo Belshee: I’m in Seattle. I work for Microsoft, and I’m currently working on the OData Protocol, Wexford Web Services, and Protocol Definition, Open Web Protocol. My background, whole lot of background with all sorts of things extreme programming XP, been doing it for a decade or so, coaching teams. I bounce from company to company and project to project to find the ones who really want to do awesome, and help them do so.

Extreme Programming XP Practices The Engine Of Delivery

Clayton: We wanted to talk to you about some XP practices and I guess at a high level. What is it about XP that attracts you to that versus some other agile methodology?

Arlo: It does the part that matters [laughs] , certainly what it comes down to. The way I think of it is, assume that our objective is to get to Chicago, and we’ve got a bunch of different ways that we could do so. One of those options is traditional development style. I’m going to lay down some track, like a big plan, build it and build myself a little hand cart. I’m going to lay down all this track, build myself the hand cart, climb on it, start pumping, and, I will get to Chicago.

Other practices do parts of a different approach. All the agile practices, you’re basically going towards, we’re going to drive there. Instead of doing this pre planning, we’re going to respond to the information as we go, and navigate the roads. We’re going to build ourselves a vehicle that can respond. Great. Then, let’s look at what are the practices, and what parts of the car do they apply to. Scrum, that’s the steering column. That’s basically what’s in Scrum. No matter how good my steering column is, I’m not getting to Chicago with just a steering column.

XP I like because it talks to the technical practices. The technical practices are the engine. You can get really, really far with XPs technical practices and a waterfall planning practice, that’s called a locomotive. It will get you to Chicago. [laughs]

That’s what attracts me there. I also do really like the Lean thinking stuff. The learning practices from XP and the Lean thinking practices align very well. I think that’s also a very critical part of it, but fundamentally, XP is the one that gets that all the rest of Agile is enabled by doing good engineering and it tells you how to do so.

Which Extreme Programming XP Practice Is First To Implement

Clayton: I’m going to kind of set you up here. We’ve had some discussions internally about, you know, if you look at some XP things, what’s the most important? There is only one thing you could adopt, so we’re going to ask you that question. If there’s one thing that a team could adopt, some XP practice, whether that be pair programming, or continuous integration, or whatever it is, what’s the one thing that you would suggest?

Arlo: Part of the thing with XP is that there is a one thing that’s a good answer to this. But it’s well broken down in all the descriptions of XP. In a description of XP it shows up as like five different parts.

Clayton: What if I said the first thing? Does that change it, if you say the first thing you would suggest?

Arlo: It’s the one thing that I would do is continuous learning and reflection on your code. That shows up in XP books as a combination of TDD, sit together, pair programming and refactoring, because it talks about all the pieces. But, those aren’t individual pieces. The individual piece is really that continuous reflection, and understanding, and learning, and improving of the code.

The other things are they are windows on the tool [laughs] you can use to understand with. If I had to choose one thing and I can identify a thing, it’s that. If I have to choose one of the practices out of a book, then I would probably say it’s pair programming, assuming sitting together.

Clayton: OK.

Arlo: But, really that’s part.

Extreme Programming XP Practices Compared to Software Craftmanship

Clayton: You mentioned a lot of the technical stuff, and I guess, maybe this a side bar, but I have to ask, where do you stand on that software craftsmanship stuff? Is that good, bad?

Arlo: The movement or the thinking? I, personally, don’t much buy into the movement. I don’t see problems with it, but I do see some places where it misses its mark. A lot of that’s in how it talks about things, and how it thinks about learning, on the intent that what matters is doing good code. To do good code you learn to do good code. You work with other people, and no holds barred, we’re going to do good code. Totally agree with all that stuff.

Common Pairing Programming Problems

Clayton: A more practical question. In terms of pair programming ‑‑ that’s an important one, I think. I, certainly, enjoy pair programming and all the benefit out of it, and everything. What are some common problems that you see that teams have, or maybe people have, when they pair?

Arlo: There are a couple of different sets of problems. There are the problems that are related to learning to pair, transitioning to pairing, all that sort of stuff, and there are the problems related to actually pairing. I find most teams have problems not with pairing, but with the transition. There are problems that show up with pairing as well, but I think the more interesting ones are the transition. Just like transition to Agile is very different than doing Agile, transitioning to pairing is very different.

The way I think of it is learning to pair is, fundamentally, your learning a different language. You think differently, you learn to think in pair, and it is a very different way of thinking. It’s critical to develop subconscious filters that are filtering your environment differently, so that you’re not being destructed by the noise but are subconsciously noting it. When something comes up, when a keyword gets mashed your subconscious mind fills in the last 15 seconds of conversation, just like when somebody says your name. The closest match we have is learning another language.

I really encourage teams to do that transition both as an experiment and like they’re trying to learn a language, which means that you define a period of time that we’re going to try this experiment. It’s got to be at least three/four weeks because we’re talking about training the subconscious. That doesn’t happen quickly, takes a month. [laughs] You got to be three/four weeks, you got to expect that it’s going to look really awesome the first day, it’s going to be sheer hell by the end of the first week. You’re not even going to be able to think straight.

Basically, your mind is now trying to think in two different languages at once, and everything is blocking itself. That’s what’s going to happen in the second week. I see a lot of teams don’t know what to expect, in that transition period. They get into that first couple of weeks, go, “Oh, God! Stop doing a hundred percent pairing,” and they say, “OK, we need to back off.” Then they do 50 percent pairing, which becomes 25 percent. We’re pairing certain types of tasks.

At that point, you’ve now switched from a more mature learning of a language to learning of a language in a high school classroom. You’re never going to get the accent, and it’s going to take forever. You’re never going to see the value that you do, if you can actually understand what immersion learning is going to be like, be willing to accept that, and then make it happen.

Introducing Pair Programming

Derek: I’ve got a question on getting to the transitions. Let me give you two scenarios, and tell me how you would approach them, and whether it’d be the same way or apparently different. One would be, I’m a development manager, and I’ve really started to read about this XP stuff, or maybe I’ve worked in another company, and we’ve done XP before. I really believe in it, except none of my developers currently want to pair program.” How do I start that process with that transition? Is it OK to just say, “I’m going to demand that you all pair program, and deal with it. Let’s talk about it in three weeks?”

The other scenario would be, “Hey, I just joined a new team. I came from an XP team, I really miss that, and I really want to do that.”Maybe there’s another person or two on the team that are interested in it, pair curious or XP curious about things. How would you go about coaching that person to moving to transitioning to pairing?

Arlo: The meta‑approach is the same, and then the details vary by the context. The meta‑approach is to understand that people decide emotionally, and then justify rationally.

Rationalization is called that for a reason, is the only way we use the rational mind. If you want to get people to make a decision to try pairing, it’s an emotional sell, because they’ve got an emotional commitment to the current one you’ve got to change to that, which means inspire for [inaudible 10:02] . Some of the things I have done here, I did a code retreat. There was a set of people. That was the right thing. We got together, and a code retrieve, you are doing everything paired. Also most of the people around here don’t have great tools.

I’m showing them Resharper, and I’m showing them End Crunch, and I’m showing them all sorts of stuff that they can’t work in their daily work, because they’re working in C on really old Legacy systems. Bring all of those things together in a room.

Now pairing is something fun that I got to do for a day, which allowed me to learn simultaneously this language, and solve the problem, and learn four or five tools, and, holy cow, it was a successful day. There I’ve inspired. That one works.

Another one is, I can do a demo and show some of the things that are going to result, and that can be another good way to inspire. We did an exchange program for a little while, which will be starting up again soon. Where team could go visit teams from other companies. Smilebox is just down the street. They have a really good XP shop.

They do a lot of pairing, and it’s full collaborative style with everyone in one room and the devs and the marketing people and whatever can overhear each other and all the goodness. When I could take people from the teams here over to visit that, suddenly, without having to learn pairing or commit to pairing, they could see the value that comes from the collaboration and the learning. Then we come back and we talk about how we will do that transition. [laughs]

Clayton: I thought it was very interesting you hit on that transition part. I think that’s a very good point. There’s a team I’d been working with where one of the guys was like, “I’m so mad at Derek, because he writes all this terrible code. I’m so mad at Drew because all he does is goof off all day.” He and I had done some pairing, and I said, “Oh, well this would be a great opportunity for you to promote some pairing. You guys have your desks set up for it. This would be fantastic. You can solve all these problems of you just do something…”

“Well, I don’t know,” and it turn into it was very much that, I don’t want to get into the transition thing. I can’t even imagine how that would work, and it was too much of an emotional blocker for him, I think. I thought that was very interesting.

Let’s Try Some Cool Stuff

Arlo: I found that the emotional block is huge, and it’s especially huge if it in any way sounds like you are trying to sell a change to pairing. But if I tell people here’s some of the advantages, and especially get them to experience one of those little experiments of, “Hey let’s try some cool stuff,” I’ll often sell the pairing by getting them to try GDD and refactoring.

“Let’s go play with these cool tools. Oh, to help people learn the cool tools we’re going to do pairing with rapid pair swaps,” and then they see the advantage of the collaboration. I’ll do that, and then the second is pitch the transition purely as an experiment. The ground rules I start with are ‑‑ we are going to do it for three weeks, we agree and understand that it’s going to be painful, and we are going to do that. We also agree that at the end of three weeks we’re going to stop.

We’re not going to pair in perpetuity. We’re going to gather data of whatever data we think is relevant to this, measure the result of that experiment, and then discuss the results of that experiment. We aren’t going to do anything more than that. If as a result of doing that experiment, now people want to do a transition, we can talk about doing a transition to pairing permanently. That no commitment thing really helps.

Extreme Programming Practices XP That People Struggle With The Most

Clayton: Just kind of a last question here to wrap up. Is there a particular technical practice or maybe a particular part of XP that you find that teams are pretty much always bad at, and they really need to spend some time improving? It’s kind of universal across all teams.

Arlo: Yeah. Unit TDD. There are a fair number of teams that do TDD. There are very few teams that actually do Unit TDD. They write short span integration tests, or long span integration tests, they don’t understand a unit. They won’t re‑factor the code, be unit testable. Instead they’ll use mocks. I hate mocks. [laughter] Mocks and dependency injection, which I also hate, to allow them to test otherwise un‑testable code.

Those tools are great for Legacy systems, because you got stuff that’s intertwined, and you want to test it anyway. Wonderful. But if it’s not Legacy re‑factor it, so it’s not intertwined. Now you don’t need the tool anymore. They’re crutches that can really get in the way. A lot of teams just don’t understand what a unit is therefore they can’t do Unit TDD.

The closest they can get is unit like TDD with mocks, where things are sort of units during testing, but they’re not actually units in the product. They aren’t getting any of the design advantages. Most of the bug elimination and that sort of thing from TDD actually comes from the design, not from doing little verifications and validations. [laughs] That’s the technical practice that I think everyone needs to learn, and it’s also an interesting one, because it’s the one that everyone who’s practicing assumes they already know.

Clayton: That’s an interesting point. I think we are out of time here. If I wanted to go find you on the Internet, or learn more about you or the stuff that you are doing, where would I go?

Arlo: Twitter handle is []@arlobelshee](http://www.twitter.com/arlobelshee), and I also do a blog, @arlobelshee.com.

Clayton: Is there any books or anything like that, anything that you’re involved in, any project that you would like to suggest for the audience?

Arlo: Yes and no books. The project I’m working on, if you’re interested in restful web services, and all of that sort of stuff, by all means, go look at ODATA. My agile stuff is mostly talking at conferences, the blog, and occasional tweets.

Clayton: As always, we’d like to invite the audience to check us out on Facebook at facebook.com/agileweekly, where you can talk about this episode, and all the other episodes, a little bit more in detail if you want to continue the conversation. Arlo, we really appreciate you joining us tonight. Thanks a lot.

Arlo: Thank you.