What’s Most Valuable in Agile?

Episode 20

June 29, 2011

14:23

TBD

tbd

The Agile Weekly Crew discuss which practice in Agile has the most initial value.

Episode Notes

Clayton Lengel-Zigich, Drew LeSueur, Roy van de Water, Chris Coneybeer talk about which practice in agile has the most initial value.

Retrospectives

Pairing

Continuous Integration

Warning Signs

What is effective

What is quickest

Deployments are a pain

Can haz confidence

XP & TDD

It depends

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of The Scrum Cast. I’m Clayton Lengel‑Zigich.

Drew LeSueur:  I’m Drew LeSueur.

Roy van de Water:  I’m Roy van de Water.

Chris Coneybeer:  I’m Chris Coneybeer.

Clayton:  Today, we’re going to talk about a carryover discussion that we had together at a team lunch earlier this week about going into a team organization and implementing either peer programming or a continuous integration system. There was some discussion along those lines. Roy, you were a vocal person on one of those fronts.

Roy:  Never.

Clayton:  Never.

Roy:  We were having this discussion with Derek, who unfortunately isn’t able to join us today, so Coney has decided to take his place.

Chris:  Hello. [laughs]

Roy:  My opinion was that when you’re first starting to implement Scrum, you get the most value, first off, out of retrospectives. As soon as you start getting the team reflection on what they’re doing, that’s when you start to see improvement, because that’s when they get the opportunity to come up with their own creative ideas.

I think Derek pretty much agreed with me on that point, and I think you do, as well. Then what the second implement was, Drew and myself are a big proponent of adding pairing. Pairing is something that you can do that’s relatively cheap from an investment standpoint, immediate investment, and something that gets you immediate results.

Chris:  From my perspective, I’m more on the continuous integration side. The reason being is I do agree pairing has a great value, and should not be looked away from at all. My main concern is that you have repeatability with the continuous integration.

You’re starting to have where when code is being checked in, you can insure that the code is in good shape, and also that it’s buildable, and the code is not in a bad state for people. I think that out of that pairing is a big culture change for a lot of shops, and culture is really we want to get down to when we want to change.

I think that the continuous integration, and some of the benefits, and also the, what’s the word I’m looking for here?

Clayton:  Confidence?

Chris:  Confidence. Thank you. Confidence in the project, and what’s going on. I think that the confidence that CI can give you is a great place to start.

Clayton:  I agree that continuous integration is great from a pairing perspective. I think that it’s a simpler change that you can implement. Coney, I remember when you talked about cultural change. Culture’s huge, and it can be hard to change. If somebody wanted to implement pairing, they could try pairing for maybe one day a week or a couple hours a day just to try it out.

That’s super simple to integrate and to talk about how that went, talk about the pros and cons, what people learned. Continuous integration is a good thing.

If you’re talking about one change you could first implement, continuous integration can take a long time. It could take a lot of investment, especially if there’s an existing system that’s really not designed well. There’s no test. It’s hard to deploy, all those sorts of things.

Roy:  Right. I think a lot of times, and that’s where something like continuous integration itself comes from, too, is that those things are generally warning signs, right? It’s bad if you have a system that’s hard to deploy, and I can completely understand the desire to address those things. I think that you can address those things better while pairing, and that’s why I’d want to start off with that.

Drew:  One thing that came up at lunch was while you could probably implement pairing quicker, the argument was you could technically do that, but maybe it would be in name only. Because I think we can all speak from experience of coming to Integram and actually pairing. That’s pretty hard, and it’s hard to get two people. Even if one person is experienced with it and the other person’s not, it’s hard to do quality pairing.

So maybe you could implement pairing quickly, but would it be as valuable if the pairing was not very effective or if the two people that were doing it, didn’t really know what they were doing?

Chris:  Going to the culture side of it also is that, with the pairing, if people are having good conversations with their pairing. If they’re not having effective pairing like you said, you’re not really changing culture at that point. All you’re doing is setting two people beside one another.

You need somebody to help teach them and help get them there. Where with continuous integration, I’m not saying that either. I am more on the continuous integration side, but also, like I said, I see the benefit in the pairing. I think that it is easier to implement, but making sure that it continues to happen.

Like you said, Drew, you could say, “Start off with pairing one time a week or two times a week,” but how do you know the next week that people are going to sit down and do one, two times a week? Where if you do put continuous integration in, you make it part of your standard process in what’s happening there. You’ll be able to get immediate feedback on the builds.

The team can start to maybe build that culture where they start to have team accountability for the code because pairing gives you that, too, the team accountability for the code. When you have a continuous integration and everybody sees what’s going on, that also gives benefit.

The team may start having more discussions as to, “Why are you breaking the build every day, Roy?” And,” Drew, why are you always having to fix it?”

Drew:  I think we’ve seen, too, on the flip side, where we have seen projects where the projects are massive. The immediate demands to build features or to go back and fix defects is so great, that while we’ve tried to implement a continuous integration solution, it takes us six months or it takes six months and we’re still not done. It seems to me that even starting from no pairing experience at all, getting people up to speed on pairing is much quicker than that.

I do think that depends a lot on the existing project and the existing situation. Not in all situations is setting up continuous integration going to be so non‑trivial. If you’re doing a real simple app, start off with continuous integration. Why wouldn’t you? But with another app, it might be a lot more difficult.

Chris:  Definitely right there. That’s one of those things where you try to pick the easiest thing that’s currently a technical issue. You try to pick that, and you start to attack it. If it is a huge build issue, then that’s the point where I would lay off and say, “Well, do we pick where we can automatically deploy it to death?” Maybe we start there and we set up an auto deploy to that.

Maybe it doesn’t run all the tests and everything else automatically, but we start walking towards it. That would be one of those instances where I would definitely look at it and go, “Well, pairing does make sense here, but let’s work on this as a pair maybe,” and you can get that in there fast.

Or have people start having that discussion about, “What’s going on? What problems are we trying to work through?”

Clayton:  Right. Another thing about pairing, too, when we talk about culture is I bet there are a lot of places or companies that would be uncomfortable or teams who would be uncomfortable pairing where they’re used to working alone by themselves with their headphones on, whatever.

There’s a lot of other places, too, where they want pairing, where they feel like pairing is missing, or they feel like they would be pairing if they were able to pair, but they don’t because they’re supposed to be working alone. I come from an experience where I used to not do any pairing, and I really wanted to do pairing. On the few chances where I was able to do pairing, I felt like a total productivity increase.

It was awesome to be able to communicate with my teammate. We got things done quick. Also looking at that from that culture perspective, too, where people are needing and wanting pairing.

Roy:  I think something that’s also like what Drew brings up as far as the siloing is that we have gone into companies before where everybody does work in their own cubicle with their headphones on, and nobody actually communicates. When you start pairing, at the very least you start having those conversations of, “This is a pain in the ass.” The other guy goes, “Really? I’ve been thinking that, too. I just didn’t want to say anything,” right?

You start recognizing some of the problems and realizing that you’re not the only one who has them, that it’s not due to your ignorance or your incompetence. These are legitimate problems that everybody’s facing, and then you can start to work together as a team. I think for a lot of teams, too, it finally gives them an opportunity to almost meet their team members because they haven’t been working with them at all.

Clayton:  What do you say to the proponents of a continuous integration system that would say it’s like maybe a testing, where you could make the argument that if you don’t have automated builds that anyone on the team can run at any point in time, if you’re not doing that, then