Jade Meskill: Hello, welcome to the “Agile Weekly Podcast”. I’m Jade Meskill.

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Why Do We Fall for the Multitasking in Agile Trap

Jade: Today, we wanted to talk about the dangers of multitasking in agile and maybe a little bit about multiple commitments. Roy, we’ve been having some trouble with this lately.

Roy: Self-imposed trouble.

Jade: Yeah. We should know better but we still fall for the trap. Why do we keep trying to multitask?

Roy: I don’t know. I think it’s our arrogance and thinking we’re different, and that somehow it’s going to work for us when we know it doesn’t work for anyone else.

Jade: So, because we’re really good at this, we can multitask in agile when all other humans can’t.

Roy: Right, even though it’s miserable and no fun at all.

Jade: What do you think Derek? Have you struggled with multitasking in agile?

The Organizational Multiple Resource Trap of Splitting People’s Time

Derek: I’m too dumb to do one thing, much less two things at the same time. I see a lot of teams struggle with it or actually organizations. Well, I see teams and organizations. I see organizations do it with the multiple resource trap.

I think of somebody is this logical thing that has 100 percent. Because I think of them as this logical binary bit of 100 percent, I can take 10 percent of them and give them over here, 30 percent and give them over here an 60 percent and give them over there.

On paper that sounds really fantastic, but for whatever reason it just doesn’t ever seem to pencil out quite right. I see that trap a lot.

Tearing a Person in Half is a Powerful Metaphor

Jade: Interrupt you real quick. That reminds of a cool exercise I did once with a group of managers, who were really struggling with understanding why nothing was getting done. I had them write out an individual’s name on an index card. I had them do that for their entire team and then I had them go and layout all the projects that everybody was working on. We put the projects up on a board and then I had them say like, here’s John.

How much of John is working on Project X? They said, oh about 20 percent. So, I tore about 20 percent of that index card off and you should’ve seen the look of horror on people’s face that I’m like tearing this person into pieces.

I stuck that up by the project and said all right how much is on this and that? We went through and by the time we were done there were these tiny little scraps of people everywhere all over this board.

Because they had way more projects than they had people and that visualization of that problem really sunk in, that holy crap we are really doing something very very wrong.

The No Projects Movement Time Fallacy

Derek: I think that’s becoming a common trend very similar to the no estimates hoopla, I think you’re starting to see a no projects thing emerge, which is…

Jade: Is that from you? [laughs]

Derek: No, I said it a few years ago and kind of dropped it, but I think people are picking it back up. I think what people are realizing is that when you do things by project. Projects ramp up, and ramp down, and have overlap. You have to start tearing people. Pretty soon when you do that, you get 10 percent of people and the problem is that it’s never that clean.

When I say “Jade, 50 percent of your time will be on this, and 50 percent on this other thing, and Roy, 50 percent.” What happens is the two projects both need 100 percent of you at the exact same time. It’s not one week I need 50 and one week I need 50 and it works out great. I need all of you right now, and the next week I don’t need you at all. It never is during the same time, so you just get into this total chaos that starts to ensue.

It’s crazy to see how much it helps people to not have that burden, to not be a slave to multiple masters. When they can just say, “I’m doing my best work on this and I don’t have to be constantly thinking about this other thing at the same time I’m trying to be focused on this.” It’s amazing how much freedom that gives people.

Which Project is My Priority

Roy: There’s another interesting effect that happens there too. Which is when you’re working on one project and the second project normally doesn’t have a whole lot of pressure behind it, but now all of a sudden it does. Even though the project you’re currently working on has a high amount of pressure, I’ve noticed that now relatively speaking the other project feels like it’s way more important because it’s more important than it normally is.

It makes you way more willing to interrupt what you’re currently doing to work on the other project, which is weird. Even though both are more important right now, because it’s relative importance relative to its past is higher, you interrupt yourself and you get into this weird thing where you’re interrupting between the two projects, and you interrupt your interruptions, and it just keeps going deeper.

Coordinating Availability

Derek: I see patterns too…of one style of pattern is that everybody on the team is a percent, so the whole team that is working on this thing, this product or this project, or whatever it is. All of us are some percent of our time working on it. The product never gets momentum because I have to coordinate my 10 percent with your 20 percent, with your 30 percent, and we can never find the time to meet because we’ve got meetings on other stuff.

We just can’t even coordinate, it’s a total nightmare. Or the other thing that I see is that almost everybody on the project, or the product, is specifically dedicated to that thing and it’s one or two people are a percentile and then they’re like the outcasts because it’s like, “You’re the bastard we can never, ever depend on because you’re on this “other project,” or this other team. We’re having to compete with you, or for your time, and that’s a burden…”

Jade: Which is usually not that person’s fault.

Derek: No, it’s not…

Jade: But they bear all the guilt, and the brunt of all of that…

Roy: Right…

Roy: If you insist on it…If you tolerate it, you insist on it, so they bear at least some of the guilt.

Using Split Resources as the Scapegoat

Derek: Well, I think what happens is they become a scapegoat that they can’t avoid. If I get Jade 20 percent of the time on a product, and Jade is a potential bottleneck for me, I can very easily say “It’s not that my work didn’t get done. It didn’t matter that my work didn’t get done because we didn’t have enough of Jade’s time…We wouldn’t be able to deploy anyways because he’s the Deploy Master, and he wasn’t available anyways, so…”

It allows all this weird behavior to start to happen, total victim mentality of “Well, you know, XYZ are roadblocked, so that’s why we didn’t get it done.”

Roy: If you’re that guy, though, or the team that doesn’t allow that type of bullshit to get in your way, and don’t make excuses, it’s really easy to stand out above the rest.

Jade: How many teams have you worked with that are in that condition?

Roy: Only a few, but I remember every one of them, and they all stand out, because…

Jade: Right…It’s not very common.

Derek: The great thing about standing out is it makes it really easy to cut your head off.

[laughter]

Bucking the Norm Causes Issues

Derek: Which is the other thing. When you start as a “Don’t even bother giving me that 20-percent-guy, the 20-percent-release-engineer, because we’ll just do our own releasing.” Now you’ve pissed all over the release teams.

When you’ve got a department of 10 people that are the database team, and they’re used to controlling everything about the database, so they give you graciously 6.5 percent of a database engineer to deal with your database stuff.

If you’re the team that just says “We’re willing to stand above the rest. F- it, we don’t need the database engineer, we’ll handle our own database,” now you’ve just created a shit-storm because you’ve threatened their entirely livelihood. “If you won’t take 6.5 percent of us, what happens when the next team won’t, and the next team won’t, and the next team won’t…”

Roy: Their livelihood should be threatened.

Collecting Resources to Build Your Empire

Derek: “Then, we don’t have a team.” That causes all sorts of other angst. I think that’s one of the reasons you see this multitasking in agile, or this dividing up of resources. It’s basically empire building. If I can build an empire of this thing, then divvy it out as a scarce resource, I have a lot more power than if I just focus on a small team.<