Chris Young and Derek Neighbors reflect on the trouble of having many small teams working for the same company on different projects and handling retrospectives. We hope that you give us feed back or start sharing your stories with us.

Transcript:

Announcer:  You’re listening to Scrumcast with Derek Neighbors and Chris Young. Today we’re going to be talking about running a single retrospective with many small teams. Scrumcast is produced by Integrum Technologies, visit us soon at Integrumtech.com and without any further ado here’s Derek and Chris.

Derek:  Here at Integrum Technologies we are a consulting company. We generally work in pairs. As part of working in pairs, we don’t have more than two or four people per team, but we’ve got five or six different pairs working together.

We do weekly retrospectives. We do them as a team instead of as just the two people working on a project, or the pair working on a project. That brings about certain difficulties in running a retrospective. I’ve got Chris Young, our Scrum Master here.

We wanted to start doing a daily or weekly podcast where we just talk about the some of the Agile hurdles that we have here at Integrum and that we deal with. This is the one that kind of bit us over time, so we thought we’d talk a little bit about it.

Chris Young:  Hi, everybody. Today was the second retrospective that I’ve run. What I try to do is actually, like Derek said, we have a team. I think there’s 12, 13 people in our company right now.

But those are broken down into smaller teams right now of two people each, on each team. It’s difficult as a Scrum Master to address specific team problems when we’re trying to pull information out of the whole team.

Say we have one team that was not meeting the velocity that they had signed up for the week or not meeting the commitment that they had signed up for and none of the other teams were having that problem. Do we really want to concentrate the whole retrospective on the one team’s problem or do we have to hope that it just sort of comes up by speaking in generalities?

From what I’ve seen, most of our retrospectives are dealing a lot with generalities, best practices, high level types of things and we’re not getting down into the data and directly working with what happened this week specifically.

Derek:  I definitely think in doing them that you have to play to the lowest common denominators. You have to play to the weakness or the strength that all the teams as a whole exhibit instead of being able to target just what one single team is doing.

The thing that is difficult is trying to do a retrospective with a single pair and an off‑site customer is nearly impossible. It’s very difficult if you’ve got just one pair of programmers. It’s very hard for them to be brutally honest with each other, meaning they either aren’t able to see the problems that they’re facing because they can’t see the forest through the trees, or they don’t have the courage to speak up and maybe admit the things that they know are currently going on.

Putting them in with several other teams helps create that courage, and maybe helps visibility that doesn’t allow you is a facilitator to have that laser‑like focus specifically to a project. I think one of the things that becomes hard is, I don’t know the proper way to address that. We talked about trying to do individual retrospectives letter team. Of course that’s hard now, as a facilitator if you’ve got around five different retrospectives.

Additionally, it’s very difficult for people to have the courage to be honest, when it’s basically just you, your pair, and a facilitator. So, you’ve got a three men retrospective that also makes it fairly difficult.

Chris:  Right. Generally, I would be coming in with data, “Hey, listen, our code coverage is dropping. Hey, listen, our…whatever.” I’d actually have some data and we could talk specifically to that. Then, isn’t it sort of embarrassing to say, “Hey, this team, let’s talk about this team’s problems.” That’s awful. I don’t think that that’s going to meet with a lot of success either.

I’m realizing more and more that my engaging people during the week is going to be more important, when it comes to those types of things. I have to have some courage myself to be able to bring people together, and see what we can do about those types of problems.

Derek:  Yes. I think that that’s one of other difficult things. I really played with it one time, maybe doing two weeks, where we do retrospectives as an entire unit. Intermix the teams, mix the teams up, and try to get some honest courage. Hit those well as common denominator problems, and really pick up our engineering practices, to pick up our scrum practices, and XP practices.

Then, maybe every third week try to do a retrospective that kind of highlights each team as an individual team, as part of the exercise, even though it was facilitated all at one time.

The problem is that it becomes fairly difficult to find exercises that work that only have two people providing the input to those data. Maybe the right answer is we do do something like that, but instead of being a data gathering retrospective, maybe we take some of the data that has been gathered as part of retrospectives over the two previous weeks plus data that we’ve seen or harvested or discussed not during retrospectives and bring that in and then try to facilitate those one on one with each team for a part of the retrospective and have it be a little more pointed.

Of course, the difficulty is some of these start‑up projects that we deal with only run four to eight weeks. If you’re only doing that every third week or every fourth week, you’re half way through a project before you’re potentially dealing with issues that could dramatically improve either the quality of work or the pace or any number of things revolving around the project.

Chris:  Again, it seems like we’re having some difficulties mapping best practices in our job because we are a very traditional consulting shop in a way. We want to do short‑term projects. We want to try to get as close as we can to fix bids so that we can bring people in and that does make it difficult.

Having two people teams, if we had something in turnoff, we were a product company or something like that, then we would have some time to work these things overtime to kind of let things play themselves out.

Derek:  I think that one of the beauties of doing pairs and then doing either one pair of pairs or two pairs of pairs and kind of capping it to no more than four people per project actually makes this extremely agile and extremely nimble in bringing on new customers and even existing customers pick projects that allows us to be really nimble in how we use people and use resources on the team to solve problems, but it almost allows us to go so fast that it’s hard to have some of the structure that is required in scrum to do the continuous improvement.

Just like if you doubled your velocity, you might drop testing or might drop other good engineering practices, I think in some ways by having these very small nimble, agile teams, in some ways, we’re now going so fast that we’re dropping the ability to have some of those sanity checks to come back and say, “How can we improve with what we’re doing,” and I think those are things that are going to be a challenge for us in the coming months.

Chris:  Absolutely, and hopefully as we do this, we won’t just be talking about things that we have no idea how to solve so we can help you guys out, but in this case, we would definitely like some good advice and help about how to manage lots of small teams.

Derek:  Absolutely. I think that a big part of this podcast for us is to talk about the things that we struggle with as much as talk about the things that we think we’re doing well.

I think any time you’re doing something professionally or even if you’re doing it as a hobby, one of the things you get stuck in when you’re kind of in your own isolated world is you don’t know the pain that other people are having and the solutions they’ve had.

Sometimes, you get great answers to problems that you have and other times you just hear that everybody else is having the same problem and it makes you just feel a little bit better that you’re not the idiot that just can’t figure out how to crack a particular nut.

We’re hoping that we do a little bit of both. Maybe we help you solve some of your problems, maybe you help us solve some of our problems or at the worst, we realized it, there’s a lot of tough problems out there that maybe haven’t been solved yet.

More than anything, we just want to talk about what we’re doing and we’re hoping that you guys do the same thing.

Chris:  All right. Thank you guys.

Derek:  Thanks.