Multi Team Retrospectives

Muli-Team Retrospectives

Derek Neighbors: Here, at Integrum Technologies, we are a consulting company. We, generally, work in pairs. As part of working in pairs, we generally don’t have more than two or four people per team. But we’ve, generally, 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 writing the 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 some of the Agile hurdles that we have here at Integrum, that we deal with. This is one that’s bit us over time, so we thought we’d talk a little bit about it.

Specifics vs Generalities

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. Those are broken down into smaller teams right now of two people each on each team.

We’re running into a problem because ‑‑ I won’t say it’s a problem yet ‑‑ I’ll just say when we do retrospectives we have to bring in everybody into that retrospective. The problem that I’m finding is that it’s difficult as a scrum master to address specific team problems when we’re trying to pull information out of the whole team.

I think probably, Derek, you can relate to that too. The idea is that you, actually, set up an environment in which problems that maybe you’re seeing throughout the week are bubbling to the surface on their own, certainly requires a lot of courage and openness on your teams.

We face this problem, like if I have one team that has a specific problem, for instance if a team is having trouble. 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, and this is a total hypothetical situation.

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 kind of generalities, best practices, high‑level types of things, and we’re not getting down to into the data and the directly working with what happened this week specifically. There’s a lot of different hindrances that keep us from being able to do that.

Lowest Common Denominator

Derek: I definitely think that in doing them you have to play to the lowest common denominator, so 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.

I think 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 that are part of a project. In doing a project, it’s very hard for them to be brutally honest with each other. Meaning that they either aren’t able to see the problems that they are facing because they can’t see the forest through the trees, or they don’t have the courage to speak up and maybe admit to things that they know are currently going on.

Putting them in with several other teams helps create that courage and maybe helps visibility, but the problem is it doesn’t allow you as 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 with other team. Of course, that’s hard now as a facilitator if you’ve got to run five different retrospectives. Additionally, it’s very difficult for people to have the courage to be honest when it’s basically just you and your pair and a facilitator. You’ve got a three‑man retrospective that is also makes it fairly difficult.

Establishing Best Practices Across Teams

Chris: It’s difficult also in terms of scheduling, if I were to try to do that. Also we do get a lot of benefit from the whole team retrospective. That’s where a lot of our engineering practices and things are established. In reading in the Agile Estimation Book Retrospectives ‑‑ I’m sorry, what is it? The Agile Retrospectives?

Derek: With Esther Derby/Diana Larsen, I believe?

Chris: Yeah. That, generally, I’d be coming in with data say, “Hey, our code coverage is dropping.” “Hey listen, our” whatever. I’d, actually, have some data and we could talk specifically to that. Is it sort of embarrassing to say, “Hey, this team. Let’s talk about this team’s problem. Let’s all focus on them.”?

I don’t think that’s going to meet with a lot of success either. We did make this move to bring on somebody as full time Scrum Master. I’m realizing more and more that my engaging people during the week is going to 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. From what I’ve been reading about, generally, the best type of situation is we actually have Scrum Master per team.

That’s silly when we’re running two person teams as well. I’m still not exactly sure exactly what the…

Derek: That’s one of the other difficult things. I really played with it one time, maybe two weeks where we do retrospectives as entire unit, and inter‑mix the teams, and mix the teams up and try to get some honest courage, hit those lowest common denominator problems and really pick up our engineering practices, and pick up our Scrum practices and eXtreme Programming (XP) practices.

Then, maybe every third week, try to do a retrospective that highlighted each team as an individual team as part of the exercise, even though it was facilitated all at one time. The problem is that that becomes fairly difficult to find exercises that work that only have two people providing the input to that data.

Maybe, the right answer is we 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. Then try to facilitate those one‑on‑one with each team for 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 halfway 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.

Agile In Consulting Environment

Chris: It seems like we’re having some difficulties mapping best practices in Agile 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 internal, if we were a product company or something like that, then we would have some time to work these things over time to let things play themselves out. It seems like here at Integrum, we’re really, really analyzing.

We, really, respect Agile. It’s a deep part of our core values, but finding, almost like a hybrid of certain aspects, so that it can work with consulting, less open‑ended type of release cycles and things like that.

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 capping it to no more than four people per project, actually, makes this extremely Agile and extremely nimble in bringing on new customers. Even existing customers, big projects, allows us to be really nimble in how we use people and use resources on the team to solve problems.

It almost allows us to go so fast that it’s hard to have some of the structure that is required in Scrum to 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 not going so fast that we’re dropping ability to have some of those sanity checks to come back and say, “How can we improve, and how can we continue and improve with what we’re doing?” I think those are things that are going to be a challenge for us for the coming months.

Getting Out Of Your Bubble

Chris: Absolutely! 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. In this case we would definitely like some good advice and help on how to manage lots of small teams in one retrospective.

Derek: Absolutely! I think a big part of this podcast for us is to talk about things that we struggle with as much as the things that we are doing well. Anytime you are doing something professionally or as a hobby, you get stuck in your own isolated world, and you don’t know the pain that other people are having, and the solutions they have had.

Sometimes you get great answers to problems that you have and other times you hear everybody else is having the same problem. It makes you feel a little bit better that you are not the idiot who cannot figure out how to crack the particular nut.

We are hoping we can do a little bit of both, we help you solve some of your problems, and you help us solve some of our problems. At the worst we realize that there is a lot of tough problems out there that have not been solved yet. More than anything we just want to talk about what we are doing and hope you guys do the same thing.

[music]

Chris: All right, thank you guys.

Derek: Thank you.