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 there’s no confidence in the system.

Maybe you’ve developed all these fantastic features. You did pair programming. Everything’s great, and the team all loves the features.

But when it comes time to deploy them, it’s a total guessing game. Everyone in the organization gets very concerned, and it turns into a two‑day process of making sure everything went right.

Drew:  I can completely empathize with that. I have definitely experienced that a ton in exactly that type of situation. I’ve also experienced where doing the deploy has been extremely strenuous even when you’re using continuous integration, although it’s much less likely to be so.

I definitely agree that that’s a really a bad situation to be in, and it is something that should be addressed. I just think it’s the next thing on the list.

Clayton:  You think it’s more important to have paired features than it is to have confidence in the build?

Drew:  I’d say you gain a lot of confidence in what you’re building when you know that you built it with somebody else. Like if I build a particular feature, I think, “Well, I may have messed up, or I may have been approaching this all wrong.” While that’s still possible with a pair, at least you’re discussing it and thinking about it differently. I find that it’s much less likely that you’ve done that.

Chris:  Also from the development side of this, so we’re talking a lot about the pairing and developers working, talking, and getting through this. But in Scrum the idea is that we want to build a better team all the way around not just with the developers themselves, but also with the product owners, with the people that we’re building software for.

That’s one of the things I like about the CI side of it, is that I’m also able to start to build up. Like you were saying, Clayton, I can start building up this confidence with the people above me, the people that I’m building my product for because we have some testing. We have some confidence in our ability of being able to deploy it because of the CI on there.

That starts building a better relationship for the team as a whole. Not just the developer’s side, but also the entire team that may be working on this project such as product owners, management, and other things going on.

If you’re able to take where it’s usually two days of crossing your fingers praying and hoping that it works and dealing with bugs and because you’ve been able to do a CI on this, now you know that you can push it out a lot better. Then you start to build that confidence up above.

You could start building a better team, a better environment, and a better foundation there. The pairing does give you a better foundation at the developer level.

Roy:  Another concern that I have is I’ve seen multiple times with people where they hop onto the testing scene, and they start doing uni‑testing or integration testing. They start developing features in a test‑driven manner, and it’s great and they love it. Then their first build happens, and there’s a bug in their code.

It’s like their dreams are shattered, and all of their expectations have been ruined because they thought that they were going to have perfect code because of those tests. Everybody who starts out testing always has that realization.

All of a sudden they go, “Oh, crap. It’s not enough to have tests. I have to have good tests and then good code. Even if I have those, shit can still go wrong.”

I think that’s something that might be really discouraging to a team that’s just starting out adapting Agile. They’re like, “Well, retrospectives are great, but this testing stuff feels like a waste of time because I spent all this time writing these tests. Then we’ve spent all this time setting up this continuous integration server, and we still have bugs. Like what the hell?”

Right? I think that’s something that I’m really worried that people would back off of Agile because of that.

Clayton:  Yeah, so I think that’s one thing that we’ve been missing. We’ve been talking a lot about pairing and CI. Another aspect of that maybe XP or engineering kind of stuff is testing and test‑driven development. I would say, there’s probably a lot of people maybe more on the software craftsman side who would argue that testing and test first even trumps CI or pairing, although…

Roy:  Why do you say that, Clayton?

Clayton:  Well, I think we should be clear that these aren’t mutually exclusive. We’re talking about which one is the best value. I don’t know that, I would say, that testing is more important than all of them because testing is difficult to do, and it’s difficult to do correctly the same way that pairing is difficult to do and difficult to do correctly.

I think that’s probably why I lean on CI as the one, I think, is the best value because it’s something that’s pretty straightforward and clear‑cut, and there’s a lot of institutional issues that get brought up.

One of the examples that Chris gave at lunch was the idea of saying, “We want to release this build, but I have to go talk to Joe over here. He’s got special password keys or whatever. He has to go do this thing. Oh, crap. He’s at lunch, and then he has to go to his kid’s soccer game.”

All that kind of stuff. That goes out the window. I feel like you get a lot of bang for your buck without having to actually be really good at testing or pairing.

Chris:  Something just popped in my mind when we were sitting here thinking about it. There is a lot to be said in the fact that pairing and testing and other things have a bad way that they could be done. You can really waste a lot of time, or you can really go down a bad route and cause some issues that then have to be cleaned up or a lot of learning that goes along with it, where CI is more technical.

CI, you’re not getting into where you have to start looking for the smells. You’re still going to be doing retrospectives, but with pairing you’re going to have to talk about, “Hey, we didn’t pair that well. Let’s see how we can get better in the future.” Where when it comes to CI, especially if you’re working in Brownfield and you already have something that’s being deployed regularly, you know how to deploy.

You know that “blah‑blah‑blah” runs on these different scripts. I can automate this. It’s technical. It’s not getting into changing an environment, changing a culture, changing a lot of things. You’re getting into building confidence as a team.

Clayton:  Well, I think that might leave the discussion as the “it depends” answer.

[laughter]

Clayton:  Maybe we can pick it up again later after we’ve got some more experience. Thank you.