Extreme Programing (XP) Practices with Arlo Belshee

Episode 70

July 18, 2012

17:02

Interviews

interviews

The Agile Weekly Crew and Arlo Belshee discuss engineering, important XP practices, software craftmanship, pair programming and test driven development.

Episode Notes

Clayton Lengel-Zigich, Derek Neighbors and Drew LeSueur chat with Arlo Belshee about:

Scrum vs. eXtreme Programming

Learning practices

All About Engineering

Most important XP practices

Software Craftsmanship

Introducing pair programming

TDD and Mocking

Transcript

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 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.

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.

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 per‑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, per‑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 per‑programming, assuming sitting together.

Clayton:  OK.

Arlo:  But, really that’s part.

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.

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.

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 s

Related episodes