One Day Sprints, Promiscuous Pairing and the Checkout Protocol

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Roy vandeWater: I’m Roy vandeWater.

Derek Neighbors: I’m Derek Neighbors.

Clayton: Today, we’ve got a smattering of topics for you. Actually, I think we have three or four things.

Derek: It’s like a turkey buffet, the day before turkey day.

Clayton: Yeah, it’s like a podcast potluck sampler.

Derek: In two weeks, which will be when you’re listening to this now. Right now, remember what Thanksgiving dinner was like two weeks ago, which is tomorrow.

We Keep Failing One Week Sprints

Clayton: We’ll see if this puts you to sleep more than the turkey.

The first topic that we wanted to talk about was, oh, geez, I forgot. We have a team that we’ve been doing some work with that they were doing two week sprints, then they went down to doing one week sprints. They’re doing Monday to Friday. The topic came up of, it’s really hard for us to get all the work done in that one week, and we keep failing our sprints. Maybe we should shrink it down even more.

Derek: Wait a minute. The first answer was maybe we should make them three‑week sprints.

Clayton: Oh, that’s true. We shot that idea down. But we said, “Hey, maybe we should shrink it down and have an even smaller time box, and get feedback even faster, so let’s try and do one‑day sprints. Let’s meet in the morning, do a quick little planning thing to figure out what’s going on, organize the work, and then let’s do the work and let’s check…”

Roy: …But we’ll spend all day planning.

Clayton: What happened? Did we end up spending all day planning?

Roy: I was not there.

One Day Sprints

Derek: No, I don’t think so. I think a number of people on the team, their biggest concern was it seems that we spend all day planning, regardless of what iteration size that we seem to have. If we went to one‑day planning, we would have to make planning happen a little quicker.

Those of you that don’t know the Core Protocols, they use the Core Protocol Decider. The only way they could get the entire team to agree to a one‑day sprint was to time box planning to 30 minutes.

Organizing The Work

Clayton: When the team decided to do that, I think the very first planning meeting, they were still doing capacity planning where they would put their hours on the board, how much time they actually had during the day, and then they would commit to whatever work they could get done.

I think for the week or so that we did that, it turned out to be that it wasn’t really like a one‑day sprint, because we weren’t doing a sprint demo necessarily at the end. It felt to me more like the team was really thinking about who was going to do the work. They were really organizing how the work was going to be done in the morning, which I feel like is something that is beyond what we were calling one‑day sprints.

How did you think that went, Derek?

Swarming And Pairing

Derek: I think that the few fundamental differences that I saw were ‑ one, they were actually very concerned about how they were going to do the work, because they knew they only had a day to do it. When they were doing a longer sprint people would tend to kind of check out during planning and like, “Oh, Clayton’s got this, he knows what’s going on so I’m not paying any attention” to the tasking that’s kind of at hand, where I think they were much more focused.

The other thing is they knew they really couldn’t take in more than a story or two, and because of that, you got a team of six or seven people, you got one or two stories by default there’s some swarming behavior, and there’s pairing opportunities that really came in. Two things that that team was not doing well at all before was swarming and pairing, and so they’d have seven stories, seven people, seven stories all happening in isolation.

Everything looks great and they come to the last day of the one week sprint, and I’ll be darned that all seven stories are five percent of the way from being done. They’re a spectacular failure at the end of that. I think that it kind of reframed how they thought about breaking down work, and they realized I think for the first time that three or four people could all be in the same story, and it could still be effective, but it required them to talk multiple times throughout the day.

Roy: Were you guys, actually, able to break the stories up small enough so they all fit within one iteration?

Aggressively Negotiating Scope

Clayton: I think in that case they didn’t have any stories that took longer. They actually were a little more aggressive about negotiating scope, which I think they normally wouldn’t have done. They would have been able to say, “Well we got a week to do all this stuff, so it will all fit.” But when they really got down to like, “Hey, let’s talk about what we have to do to get this done,” then I think they uncovered some of those unknowns they would have found out about on Thursday, otherwise.

Roy: Did you find this made you really susceptible to people being late? If the first thing you’re doing every morning is planning, and do you want to figure out your capacity, and somebody shows up half an hour late, and they miss planning, how does that effect you?

Replacing The Stand Up

Derek: I think it actually had the opposite effect. I think people were, actually, more mindful of being on time because one of the problems before is they didn’t think the stand up was very valuable. There was no need to be on time to this stand up that you didn’t get any value of, where they knew if they missed a day of planning that they would be significantly out of touch with what was going on for the entire day. I think it actually made people value the start of the day much more than they did before.

Product Was The Limiting Factor

Roy: What point does it start breaking down, one day sprints sounds like you got some value out of it, like what if you did one hour sprints or one minute sprints or one second sprints? Like at where does it become unreasonable?

Derek: I think the breakdown that I saw that was huge was ‑‑ it’s very difficult for the product owner who is in charge of multiple teams or not in charge of them, but has multiple teams on this particular product. It’s very hard for them to commit every single day with their workload at the same time.

Since the team is totally dependent on having new work to start every day, if she was late or not able to be there, that could seriously impact the entire day for the team, so that was a major hurdle to overcome.

Then, of course, the other one is if you start to get bigger stories that don’t decompose well to less than a day’s worth of time for the entire team, or if you got stories that rely on feedback from somebody else that might take a day or two for those to go, it becomes difficult for how do you deal with those.

The Checkout Protocol

Clayton: Just to shift gears a little bit, Roy, you recently have an experience using the Checkout Protocol during the retrospective. I was wondering if you could maybe share that story.

Roy: Sure. We were having a retrospective. I think it had been going on for about an hour and a half, and I think a little bit in we decided to come up with a smart goal. The smart goal is actually suggested by the scrum master, so it’s a little odd from that perspective.

In general, the retrospective was going around in circles, and we were lost to what was going on. It didn’t seem like it was moving forward at all, like it suddenly repeat back on itself, and it just go for some iterations.

The rest of the team that I was working with was all familiar with the Decider Protocol. I ask them if they’re familiar with Core Protocols, and I ask them if they knew what the Checkout Protocol was, and they said, “No.” I explained to them how it works.

If you feel that you are able to provide more value somewhere else or if you feel like you are ‑‑ I believe the word Jim uses is ‑‑ emitting random emotional signals, or something like that, the idea of you’re just firing off random emotional stuff and you can’t deal rationally with the situation. I explained to them that if that type of thing happens, you can say, “I check out,” and walk away.

You are able to get out of whatever the thing that you are participating in. I explained to them how that protocol work, and then checked out, which I think shocked quite a few of them because they were not quite used to that type of thing.

Clayton: The retrospective is like a meeting, and you can never really leave it. But in your case, maybe you felt like your time is better used elsewhere, or you couldn’t rationally participate at that point.

Roy: For me, I definitely felt like my time could better be used elsewhere. I was probably misusing the Checkout Protocol in that I was trying to use it to send a message that I didn’t feel I could send in any other way, which is, “This is a waste of my time, and I should do something else.”

It wasn’t so much that there was something more important for me to do as much as it was a, “This is something that’s not important at all.”

Clayton: I was wondering when using the Core Protocols, if you have a team that is familiar with them, and especially if they’re familiar with the Core Commitments, I think using them can be the super powerful tool. If you get a group of people or team that is only tangentially familiar with them, and doesn’t really know the Core Protocols, I wonder if it’s like playing with fire.

Roy: Yeah, I definitely stepped on a few toes, and I did that. I think some people were probably rightfully offended or at least hurt by it.

Clayton: Do you think you’ll see someone use the Checkout Protocol in the future?

Roy: I don’t know. I hope so. I think I talked to Derek about it afterwards, and he was present at the retrospective as well. He feels like if you were to ask anybody at the time if they want to leave, they probably would have said yes, because I don’t think it was a secret that the retrospective didn’t feel like it was adding value. I don’t think I was the only one who had that impression.

Promiscuous Pair Programming

Clayton: Speaking of adding value, you guys have been working with a team that has been trying to adopt pair programming or promiscuous pairing, and doing a lot of pairing with different people on the team.

I think that you guys are facing that common criticism of pair programming that, “If I’m an expert or I think of myself as an expert, I can’t pair with novices because they’re too slow. They slow me down. I’ll be so much faster on my own.” Is that an [inaudible 09:43] ? Have you guys been seeing something like that?

Roy: Mm‑hmm.

Creating a Cross-Functional Team

Derek: Yeah, I think it’s a little bit odd. It’s not probably different than you’d see in any other organization, but one of the things that this particular team has a little bit of a challenge with right now is they got a really significant skills gap between some of the people on the team.

They were not a cross‑functional team before. They are now a cross‑functional team, and that has created a significance skills gap in both knowledge and domain as well as technical skills. Early on, the senior developers, for a lack of a better term, really didn’t want to pair with some of the people that had a skills gap, because they felt that it was really slowing them down.

At some point, during retrospectives, the folks that feel like they’re slowing people down admit that they are slowing people down, but they came to the conclusion, “If you don’t pair with us, how are we ever going to close the skills gap?” They came up with one of the retrospectives goals that the senior people were not allowed to touch the keyboard at all.

Their mindset there is if they are not allowed to drive, they are forced to teach us. Of course, this frustrates the developers to go a whole sprint without being able to touch a keyboard.

Roy: That would frustrate me.

Different Skill Level Pairs

Derek: The retaliation back was that, “We need to have those with the lowest level of skill, pair a fair amount of time together, so that we don’t have to pair with them, and slow it down.” Some of that comes with, I do believe there is a matrix out there, where if you say, two people of a high skill level pair together they will probably go really fast, but they will not probably learn a ton from each other.

They’ll learn something, but not a lot. If you have two low level people, or low skill people, pair together, they will go really, really slow, but they will learn a ton, because they’re both so out of water. They have no choice but to totally lean on each other to get anything done.

Any combination outside of that, whether that is two medium skilled people or high skill and a low skilled, you’re going to get some variation of somewhat fast and some learning. What happens if you’ve got a high skill and a low skill? You’re probably going to have a fair amount of knowledge transfer, but you’re going to slow down significantly.

Teams really struggle with what’s the balance, and they seem to shift from one polar to the other polar, to where it’s like, “No senior developers can drive. We have to go really slow so that we think we’re learning.” Then, it switches the other way, “No senior people develop with low skill people so that they have to learn more, and we can go fast.”

What we’re seeing them start to understand a little bit more is that when they’re actually more promiscuous and switch up, at least once a day that they get both met. They feel like they’re able to go faster when they are with one person, and they feel like they’re learning more when they’re with another person.

We’re finding that balance is striking pretty well for them.

Roy: One important thing about that though is that you’re talking about this matrix as being applied to the same body of work ‑‑ two low knowledge people working on the same thing that two high knowledge people would.

What we’ve started to see is it’s really uncomfortable for two low knowledge people to work on something that’s difficult or something that, maybe, requires a little bit more knowledge, because of the fact that they don’t have anything.

That is exactly what is required in order for them to gain that knowledge. What we’ve started to see happen is that when two people with low knowledge start pairing, they would shy away from the difficult stuff, and grab the low hanging fruit that they already knew how to do.

We ended up with these two, it was one pair which was essentially, idealistically high performing, but not really gaining much knowledge, and they were doing all the difficult stuff. Then you have one pair that would catch one of the lower hanging fruit and cleaning up after everybody else, but not really learning.

Now you had, essentially, two silos, where it was a silo with two people that keep to themselves who, maybe, were moving fast, but the two low knowledge people weren’t actually learning anything.

Clayton: I feel like from what I see more and more is when I’ve paired with people that are very novice or entry‑level, I try to make it very clear about asking questions. I think most people are open to that.

They ask me all kinds of questions that I feel like when they’re pairing with the people that are “senior developers”, they ask some question about, “Why do we do it this way?” A lot of times, the senior developer person doesn’t really know, but that’s just the way it’s done.

If they were pairing with another senior developer person, they have both already determined that this is the way we do things and there is no reason to ask that question. A lot of people, “experts”, get frustrated because it’s like, “I want to try and get this work done, but now you’re making me think about every little nuance, or whatever, every detail in this code base that I really don’t know myself.”

It’s just aggravating. I keep seeing that more and more.

Derek: For those listening at home or at work or in the car, the moral of this story…

Roy: Or on a plane.

Derek: …or the plane, or boat…

Clayton: Hot air balloon.

Pairing Is About Learning

Derek: …the moral of this story, in my opinion, is that one of the key drivers and benefits of pairing is learning. If you are not learning when you’re pairing, you’re probably pairing wrong.

The rate of learning is going to be dependent, but, I would say, even if you’re an expert with a novice, when that novice asks those questions that you don’t know, that’s an opportunity for you to know that you need to learn the material better. When they say, “Why do we use this plug‑in, or why do we accentuate the class this way?”

When your gut reaction is, “Well, that’s just how we do it around here,” and you don’t really know, that’s a learning moment for you, that maybe you’re not as expert as you think you are.

Roy: It’s really difficult for a lot of senior people to say that, or to even admit not knowing something.

Derek: It’s hard to admit you suck for sure.

Clayton: [laughs] Someone gave me this title and I’m not giving it away. You have to pry it from my cold dead hands.

That wraps it up for our Thanksgiving edition of the Agile Weekly Podcast. Make sure to check us out on Facebook at facebook.com/agileweekly. You can talk about this episode and others. You can “Like” the page and get us some reach so other people can find out about us.

Derek: Gobble. Gobble. Gobble.

Clayton: Thanks. Bye‑bye.

Roy: Bye.