Shared commitments with Howard Sublett
The Agile Weekly Crew and Howard Sublett discuss shared resources, multitasking and team members having multiple commitments.
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
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.
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?
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 guida