Clayton Lengel-Zigich, Derek Neighbors, Chris Coneybeer and Roy van de Water talk to special guest Howard Sublett from Big Visible to talk about shared resources, multitasking and team members having multiple commitments.

• Treating people as resources can cause long term problems
• Specialization can discourage team members from taking ownership of a project
• Team members complaining of too many meetings is a red flag indicating that developer is probably on too many projects
• Product Owners are not exempt from suffering in capability and quality from working on two many projects
• Human beings do not context switch as easily as we pretend to be able to

Transcript

Clayton Lengel‑Zigich:  Welcome to another episode of the ScrumCast. I’m Clayton Lengel‑Zigich.

Roy van de Water:  I’m Roy van de Water.

Chris Coneybeer:  I’m Chris Coneybeer.

Derek Neighbors:  I’m Derek Neighbors.

Clayton:  And joining us today, we have Howard Sublett. Howard, if you could just say hello to everyone and tell us a little bit about yourself.

Howard Sublett:  Hi, everyone. My name is Howard Sublett. I work at BigVisible Solutions out of Boston. Long time employee of the Scrum Alliance. Enjoy the space, worked with a guys over the years at Integrum and at Gangplank, glad to join today.

Clayton:  It’s good to have you. Today, we wanted to talk about a couple different topics. One is shared resources. How do we manage pulling people off of teams and moving people around? Also multitasking, or being responsible for multiple commitments and people being spread too thin. Right after that, guys, what do you think?

If I’m the manager and I have a couple of teams, and I’ve got one person that I’m expecting to be on both teams, is that a good idea, bad idea?

Derek:  That’s a sign of dominance with your ability to be highly efficient with resources.

Clayton:  Can you break that down into layman terms, Mr. Derek?

Derek:  Yes. You’ve just fucked your teams.

[laughter]

Clayton:  Can you smarten it up a little bit for the podcast audience?

Derek:  Yes. One of the MBA fallacies is that you have to be a really good steward of resources, which means you have to slice them infinitely thin. It’s not uncommon that…especially in silent organizations or organizations where you’ve got very specialized employees.

Maybe I’ve got a database architect or a UI person. There’s a UI person for every single team. I now want to slice them across four or five different projects. What you’ll find is that they can’t identify with any of the projects that they’re on. They have no ownership of any of the work that they are doing. They’re generally overcommitted, yet there is no real visibility of that even in the highest performing of teams.

Roy:  How do you deal with something like that, where you have an architect and he is your primary architect guy and, really, all of your projects need to have architecting expertise, whatever that means, how are you going to deal with that type of situation?

Derek:  For me, some of it is to start to learn with the damage you’re doing. One of the things is why do you rely on a sole person? You’re setting yourself up for the hit‑by‑the‑bus syndrome and what happens that person when they decide to leave your organisation or something happens to them, how cripple do you become?

You probably want more than one person to be responsible for it. The other thing is how are you really getting a team to coalesce, if the team is looking to a single person to do a certain part of it? How do you get that ownership? The cross‑functionality to me is a core principal in a lot of ways in Agile work. We don’t sit around and say, “Well that’s so and so’s fault, they’re the ones that were supposed to do that.”

As a team we say, “If so and so is not available we will figure out how to do it at whatever level we can do it at to the best of our ability.” Some of that is getting to the point of how do you start to challenge that mentality?

This is not going to happen overnight. I’d say the other way that I would combat it is I would make all of the teams to have shared resources on them absolutely positively use a committed‑driven approach in planning so that they know what resources are being committed and at what level. So that somebody who is a shared resource doesn’t over commit themselves.

They go like, “Oh, yeah I could do that, oh yeah I could do that,” and then at the end of the session they have over committed themselves to five different teams.

Clayton:  Yes it may go beyond just the commitment point of view. One thing I have always liked is, “If everything is important then nothing is important.” If am on every team then am I really on any team? What are the team or the people effects of having a senior developer or DBA or an architect or something bounce around? Does that person ever feel like they are on a team or do they ever get to be part of a team?

Howard:  I was just having a conversation about this with one of our clients today regarding designers. One of the things we talked about was the ownership. We were having issues with the ownership and also that individual once we started talking to them about the issues. They felt like they were being siloed.

They saw how these other teams were trying to open up and they were trying to have more involvement and have better transparency on the team but they felt like they were being put into a silo because they were being treated as this one‑off resource for everything. They weren’t involved. A lot of it came down also in amount of ceremonies. How do we get that person involved with ceremonies when there’s multiple teams being run?

Derek:  That’s something I definitely see. I see people that are part of multiple teams when you transition to Agile when you start getting into the thick of it.

They get pissed off because they are being asked to go to five different planning meetings, five different stand ups, five different sprint reviews and [inaudible 05:22] says, “I can’t get any work done, I am in meetings all day,” which is the exact opposite of what you try to do in Agile which is you basically have constant interaction and you minimize the amount of ceremonies or meetings that you do by compressing them.

But to me that’s a complete red flag when somebody in an Agile organization screams that they are in too many meetings. Is that it’s probably because they are on too many projects.

Roy:  It sounds like it would be really hard to commit to a project as well, because if I’m hopped onto a project just for the design phase. I’d be on that project thinking like, “Oh I just got to stick it out for two or three weeks until this part of the design phase is done. And then I’m onto the next project so I don’t have to give it my all, I just have to get through it.”

Derek:  Plus if you have a design phase, aren’t you Waterfall?

[laughter]

Clayton:  That’s a good point. The idea of being involved in a lot of meetings or that kind of red flag ‑‑ that speaks to having multiple commitments. But is there ever a time when it’s appropriate for a person that maybe on a team or maybe an architect or something to have multiple commitments? Is there a low limit or is it a not at all? Or do you think that’s a bad idea in general?

Roy:  I guess my question would be why are the individual’s making commitments? Because it sounds like the whole team should be making a commitment and if you have two separate things that need to be committed to, then perhaps the team can decide how best to handle that. And the team should commit to getting both things done and then whoever’s available will do the work.

Derek:  I’ve seen this done a couple of…I guess I would start with saying it depends. Just like with distributed teams if you don’t follow the prescriptions of Agile, you are going to pay a penalty. The question always becomes is the penalty worth whatever benefit you get in exchange for that.

If I say, “Well, I need this security expert, that just knows the in and out of security, up and down.” But I can’t afford a security expert for every single team I have. Therefore they’re going to have to be a shared resource. I’m making a conscious choice to say, the benefit I get from having a specialized security person outweighs the penalty I pay for making them a shared resource.

Another way I would think about using those type of resources, whether they be more of the operation IT team, whether it be security team, whether it be architects, whether it be database, whatever. Or maybe you have one or two of them or three of them but they need to be split across five or six teams. I would actually create them to be their own team, and have the other teams treat them like a third party.

Which is, I can’t commit to work that relies on them unless they’ve already done the work. If I need a bunch of database changes, those need to be to be done before I go into my sprint, in order to commit to them. Because just like a third party, they’re not committing, so I can’t commit to something that they’re not committing to. Which is another way you can deal with it.

Howard:  Derek, don’t you see that some of the problems come in when the architect is being shared amongst multiple teams. I mean I’ve seen that before in organizations and they have to, they have to share them that way. They can’t afford somebody for every team.

But the problems come in is when the teams feel like that they are actually committing as part of the team instead of sitting outside the team helping with guidance documents and stuff, over how they are going to write code over this section of architectures.

Derek:  Do I see that? Or do I see a problem in that?

Howard:  The problem for me is when the architect feels like they’re a team member in every team. Because they can’t really commit to every team because they’re doing nothing but going from meeting to meeting to meeting.

Derek:  Yeah, I don’t see very often that they actually feel like they’re part of the team. I usually see that they feel like they’re not part of the team or they identify more with one team than other teams.

Generally it’s very hard to be committed to five teams at once. Not only is it a time constraint thing, it’s an emotional constraint thing. It’s very hard to make bonds and have trust with five independent teams that have five different visions, that have five different commitments.

That’s very difficult to honor.

Clayton:  We’ve been talking a lot about architects and DBAs and the development side of things. Howard, I had worked with you in the capacity of a Product Owner.

Do you think that had you been the Product Owner of multiple projects or multiple teams you could have been as effective? Is the Product Owner role immune to this splitting problem or do you think you would see the same issues?

Howard:  You definitely would have the same problem. I would assume that unless the teams that you’re working with and the product that your working is so closely aligned that it feels like one to you. I don’t know if we as human beings context switch as well as people make us out to. I think it’s more difficult than what we pretend it is.

Clayton:  One thing I see is that some organizations seem to struggle with the idea of a Scrum Master, where if you have, say, five different teams, do you have five different Scrum Masters? It seems like some people have a hard time making that decision, maybe from a budget perspective. Can you be an effective Scrum Master for five different teams, or is that the same kind of thing we’re saying here, where you probably can’t?

Howard:  For me, I would say it depends. It would depend upon the maturity level of the teams.

In the beginning, it would be very difficult to be a Scrum Master for multiple teams. As the teams matured, I think that would become easier. You would have a primary team you’re focusing on and a secondary team you’re working as a coach or shepherd on.

Depending upon your skill set and the maturity of the teams, I think that role could work that way. Derek, you may disagree with that.

Derek:  Again, it goes back to, everything’s a trade‑off. The more ways you slice a Scrum Master, the less effective they’re going to be. It’s a matter of, how much are you willing to pay that penalty? In the case of, you already have high‑performing teams, maybe the penalty’s not all that high, so it’s very palatable to do so.

In the case of new teams, the penalty might be extreme enough that you’re not willing to do it. Some of it goes back to the capability of the Scrum Master. A more experienced Scrum Master might be able to balance a team or two, where a new one might not be able to.

I think it’s rough. These are trade‑offs that people make, from Product Owner to Scrum Master to database person to security to programmer to testing to you‑name‑it.

The real thing that people are talking about is budget. They don’t want to allocate enough budget to do things properly. It’s all a trade‑off. Where are you going to cut costs?

The problem is that people aren’t real or aren’t honest about the real penalty about some of the ways they cut costs. They say, “So‑and‑so’s ‑‑ Howard’s a really great Product Owner, so he’ll have no problem being a Product Owner for three different products.” That’s the lie we tell ourselves.

Agile’s role is to expose the truth. It does that fairly well in that when you share resources, you get poor results. I think that usually surfaces up.

Howard:  Do you think it’s, in some ways, the way Agile has been sold? I’ve bumped across quite a few people that really feel that the number one benefit of going Agile is that, number one, it’s faster, but it’s cheaper, too, as well. We can deliver quicker, and it’s less cost than the way we were doing it. They’re going with a mindset of a cost savings, in a way.

Derek:  I think there is some of that that happens. I definitely think that we are marketing the wrong things. I don’t think we should be marketing “faster” and “cheaper.” Those are by‑products that happen as part of the process, but they shouldn’t be the necessary endgame of the process.

What happens is, yeah, you can move faster, but it’s not immediately. You do have to make significant change to get that speed and quality improvement.

Roy:  The “you” is the entire organization, not just the developmental team.

Derek:  Yes, that’s correct. That’s where I see a lot of, “We made this big change over here in developers, so we can skimp on Product Owners.” No, not really. Or, “I made this really big investment in Product Owners, so we can skimp on developers.” It’s not that simple.

People still try to have a “nine babies in nine months” problem. You can go faster, but you can’t beat physics, so to speak, in some of these cases. That’s what we’re really up against.

Clayton:  To wrap up…

Howard:  The Duggars did…

[crosstalk]

Clayton:  Go ahead, Howard.

Howard:  I was going to say, the Duggars beat that statistic, I think.

[laughter]

Clayton:  To wrap up, is it possible for a team or, maybe, two teams or three teams or whatever to become mature enough where you could move resources around, or is that always going to be a detriment, and that’s something that nobody should really strive for?

Roy:  I think I agree with Derek that it’s probably always going to be a detriment. You might be able to minimize that detriment a lot by having more efficient teams, but you’re always going to lose something.

Derek:  I want to make a small clarification. It’s absolutely, positively possible to move people around within teams, just not within a sprint or within an iteration.

If I’m bouncing between three teams within a sprint, there’s going to be a significant penalty. If I’m on one team one sprint and another team another sprint, there is a penalty but not a significant penalty in that.

Roy:  We had Adam Sroka on a few weeks ago. One of the things he was talking about was software craftsman tourism or something like that, where companies would, essentially, do foreign exchange programs between each other with their developers to gain a new perspective.

I think that while you probably get a penalty in velocity and probably a penalty in the team’s cohesiveness, you might get a potential gain in innovation just from adding that new perspective to the team that they didn’t have before.

Clayton:  That’s a good point. Howard, as our special guest, you get the last word. Is there anything ‑‑ a tool or anything, really ‑‑ that’s been interesting to you lately, that you’re real hot on and you’d like to share with the audience?

Howard:  Absolutely not. I can’t think of anything that’s just really, really zinging me right now.

Clayton:  The audience gets a view into your boring life, then?

Howard:  Absolutely.

Clayton:  That’s too bad.

Howard:  Absolutely. Totally boring right now.

[laughter]

Clayton:  All right. Thanks, Howard.

[background music]

Clayton:  We appreciate you joining us today. Join us again for another episode of The ScrumCast.

Howard:  Thanks, guys.

Derek:  Thanks.

Chris:  Thanks.

Mark Graban:  Hi, this is Mark Graban from leanblog.org. I’m looking forward to being a future guest on ScrumCast, but you can also listen to my podcast if you go to leanpodcast.org. I cover Lean from a pretty broad perspective, including manufacturing, health care, and start‑ups and software.

You can listen to podcasts that I’ve done with Eric Ries, with Brant Cooper and Patrick Vlaskovits on customer development. You can find all of these on iTunes if you search for “Lean Blog,” or go to leanpodcast.org.