Is having specialists on Scrum Teams a good or bad thing? Find out as we discuss the pros and cons of specialized skills on a Scrum Team.
Robert Pieper: Just today I had this question come up about specialists on Scrum Teams. So this organization I’m working with, they’ve got an entire Scrum Team and everybody does something very specific. They’ve got a designer that does design work, and a QA person just doing all the QA stuff, and the QA person can’t code so the coder does the coding work. And I was asked, like, is this good? Is Scrum okay with this? Because in the Scrum Guide, it says they don’t respect sub roles or hierarchies. And they clearly have sub roles on this team. So is that bad? What do you guys think?
Jason Malmstadt: I think there’s a myth out there that once you join a Scrum Team, you need to be an absolute generalist. Like everybody has to do every other person’s type of work. And I don’t think that’s true. I think that’s taking to an extreme the idea that we want to be collaborative, we don’t want to stay rigid in our specialties, but it doesn’t mean we all have to have the exact same skills.
Gregory Crown: You want to have specialists, specialists are good. What would be great is if a specialist can maybe take on another task on occasion, or be able to slide into another role as needed. However, I’ve seen some environments, like maybe what you’re referring to Robb, where there’s plenty of work for that specialist, like there’s more than a full time job’s worth of work for that specialist so they’re over their head with it. I think the bigger concern is how do you deal with that potential bottleneck? What if you only get one specialist on your team? And they’re gone for a week or a Sprint, now what?
Robert Pieper: Yeah, they get sick, they quit.
Jason Malmstadt: Right.
Gregory Crown: Yes.
Robert Pieper: But yeah, you’ve got a single point of dependency failure.
Jason Malmstadt: I think we want to honor people’s specialties on a Scrum Team. We don’t just want to dismiss it. But I think a specialist that is willing to flex outside their specialty usually helps the team achieve their goals, right? I’m not the world’s biggest expert in any kind of sports ball, but I know that on an NFL team, if I’m on offense, and the other team catches the ball, I suddenly have to be on defense and stop them from running the ball. So I think when the team’s goals call for it, stepping outside the specialty can be a really important thing for people to do on the Scrum Team.
Robert Pieper: I agree. Good sports teams pitch in, they figure out a way. “That’s not my job!” never comes up. I don’t think?
Gregory Crown: (chuckles) Never, especially in professional environments. I can say maybe I’ve been guilty of that in the past though. There’s times where I’m like “do I really want to do that task?” It’s not my favorite. I like to do this. So I might find myself being very busy with the thing that I really like to do, with my specialty, to avoid doing the other work. So I don’t know for those specialists out there hearing this one, I think do a self check because it’s easy to get caught up in the one thing that you’re really, really good at and not really explore other things that can really help the team or maybe the goal that you’re working on together. Just a thought.
Robert Pieper: Yeah. So I mapped out some of the pros and cons with one of my students about that team she was asking about, and she only came up with two pros to have specialists, or not specialists, but assigned sub roles on a team. The pros were basically we know exactly who to hand out the work to, and we know who will be accountable for what types of work, but it pretty much ended there. And then we listed out 4 cons. And I was like, well what do you think? Is this something you actually want to have on your Scrum Team? A group full of specialists? You know, we listed what if they, what of somebody’s out? What if somebody quits? What if we lose knowledge transfer? We lose the ability to collaborate, when we don’t have people that can actually speak the same language. By the same language, I mean, doing the same specialties. So yeah, I mean, in that case, it was kind of eye opening for her. She could definitely see there were a lot more benefits to having people that were able to be flexible, somewhat, maybe not perfect generalists, but more generalizing specialists and be able to spread knowledge and be more of a contributor to the team rather than just doing their own thing.
Jason Malmstadt: Well, there’s something to be said here for flexibility and complexity too. If we’re doing repeatable simple work. You know, we’re gonna put together a bunch of tables from IKEA. I might want to be the specialist that knows how to screw the bolts in and that’s all I do, that can get us really efficient. But if we want to be adaptable to change, if we want to be agile, rigidly adhering to roles is probably not a great way to get flexible. That sounds pretty non adaptable to me.
Gregory Crown: One more thing I’ll toss in is I’ve seen specialists that are so focused on one specific way to do something, that they miss opportunities for an abstract or divergent way of thinking. And when you collaborate with those who aren’t experts in something or where they aren’t in their realm of specialty, they often will think of ways that are outside the box. So the out of box thinking or the innovation often happens as a result of not specialists, but those who are entertaining something they’ve never thought about before, and they will approach it differently because they don’t have all the background and the expertise. So in many ways, I’ve seen innovation teams without specialists benefit because they don’t know the right answers. They’re exploring and they’re discovering new answers.
Jason Malmstadt: So keep your specialists. Keep your specialties, but be willing to flex outside them when that’s what’s needed for the team to achieve their goal.
Robert Pieper: Absolutely.
