Ep. 143: The perils of assigning work to individuals within teams

In this episode, Peter Maddison and David Sharrock explore the nuanced topic of assigning user stories to individual team members. They discuss the pros and cons of this practice, discussing when it might be appropriate and when it could potentially harm team dynamics and productivity. The conversation touches on the importance of collaboration, team autonomy, and the challenges of balancing urgent work with long-term team development.

This week´s takeaways:

• Avoid individual assignments; encourage team members to pull tasks collaboratively.
• Individual assignments may be necessary for specialized skills or simple tasks, but use sparingly.
• Frequent individual assignments can reduce team autonomy, engagement, and skill development.

We love to hear your feedback! If you have questions or would like to suggest a topic, please contact us at feedback@definitelymaybeagile.com.

Chapters

• 0:04 Assigning Stories in Agile Teams
• 12:53 Assigning Work in Agile Teams
• 19:29 Team Ownership and Structure in Agile

Transcript

Peter: 0:04

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello Dave, how are you doing today? I'm doing very well. How are you doing? I am doing wonderfully. There's quite a lot of background noise for me today which I am assured by all of the people in all of the meetings that they can't hear, so I'm going to take them at their word. But for me it's like somebody's like drilling constantly Feels like you're in the dentist chair or something like that, exactly exactly.

Dave: 0:40

We're going to get a different side of you today. Let's see where it goes.

Peter: 0:44

We'll see where that takes us. So what's the topic for today?

Dave: 0:47

Well, it's interesting. We've talked a lot about sort of big picture strategic stuff and I thought I'd pull in this question that we got, which is really just very specific to teams and specifically to assigning stories or not assigning stories to individuals on the team. So the question is something about can you talk about when to assign or not assigning stories to individuals on the team? So the question is something about can you talk about when to assign or not to assign user stories to members of the dev team? On your marks, get set go.

Peter: 1:14

So well in collaboration, I think, is sort of the thing. It's supposed to be a team sport, not a individualistic sport. And if you're assigning or telling people what it is that they're doing, then you've probably already broken the lines of communication a fair bit there. If you're doing it without any kind of consultative conversation, then that's kind of a lot of it out the window at that point and a lot of the sort of fundamentals around working with your team have gone out the window.

Dave: 1:42

So there's that perspective what you're describing. There is that difference in the Hackman matrix, the authority matrix, between the difference between a manager-led team, where the manager tells everybody what they're going to work on, and sort of a self-organizing or self-driven team, where they determine what work they're going to do within the team right.

Peter: 2:01

Yes, yeah, and ideally I mean. We often talk about the differences between pushing and pulling work and teams. Being able to understand, define and pull the work in and work on it as a team is the target state that we're aiming for, and one of the common pieces I often look for when I'm starting to work with organizations is how do they refer to people in the organization? Do they refer to them as people or do they refer to them as resources? And they want to know exactly what allocation. Is it 5% of Bob's time that you need or is it 10% of Bob's time that you need? And apologies to any Bobs out there, but apparently their time is being sliced and diced into these tiny little segments, and that puts you down this path of immediately seeing that there's a desire that it's the individual that's working on this, not the team that's working on this.

Dave: 2:54

I mean that's a hangover from Taylorism, right, and from that whole time and motion studies. I know how much time you're going to need to work on X before it moves on to the next station or the next station or the next step in the journey that we may go through to develop a product which is, I mean, I was going to say, worked well enough 100 years ago when it was introduced, to sort of streamline some of the manufacturing processes that are going through. But in the digital space, I mean I don't know that it works, it's really relevant anymore. But even if it was relevant in the digital space, I mean I don't know that it works, it's really relevant anymore. But even if it was relevant in the digital space, it absolutely is not, because it's a complex environment. You don't know if it's 5% or 25% or all of your time in order to go and solve certain problems.

Peter: 3:37

Yeah, and by putting it on one person to do this. Now there's a couple of now. It could be that somebody owns that work and they're going to take the lead on guiding that work through the system.

Dave: 3:47

But you're again. I mean the wording that you're using there is pretty critical Right. So if they own the work and they will take the lead in guiding somebody through, that doesn't mean they're doing the work. Yeah, you mean somebody else is probably doing the work. Hopefully they're learning as they go and they've got a subject matter expert there to help them learn and get through that. They're all for that right. But if that single individual is always the one that gets to do whatever this piece of work is, you're actually creating strategic weakness in that team. Because there's a single person who can do it, that person can no longer go on a vacation if that work needs to be done?

Peter: 4:23

Yes. Well, this is your single point of failure. It's that only one person can test. They're the tester in the team and they're the only person who can do that.

Peter: 4:32

A common one that I remember a few years ago is, like infrastructure, we've got all these DBAs. We should just take one of these DBAs and put them on each of the teams, because all DBAs are made equal, so they should all be able to do that same job, even though, from a team perspective, some teams have a much greater need for the management of data and data schemes and some have a much lesser need. And so some of your DBAs end up sitting there twiddling their thumbs while others are just completely overworked. And not to mention that you have the DBAs come in many different types. Database administrators work either on the development side or on the infrastructure side, supporting and managing it, so there's very different types of DBAs with different skill sets into different technologies, and so this idea that you're just going to take that centralized team without any context or construct and just scatter them across a number of development teams and expect you're going to get good outcomes is just asinine, frankly. But I've seen people try to do that and it had exactly the impact that expected.

Dave: 5:35

I mean, everything that you've said so far really points it neither of us are fans of this idea of assigning work to individuals on the team, right, but are there situations where you might expect to see that?

Peter: 5:47

Especially when it's a new team, especially if it's been pulled in experts from different areas and they're only in process of finding there. You may have certain subject matter expertise where you effectively it has to be that person because they're the only person who knows. Now, that should be a short lived thing and it should be managed as such. You've got to be very, very close eye on that type of work because it can be very disruptive to how the team forms if somebody is constantly being pulled off onto doing something that isn't related to the team.

Peter: 6:18

Maybe it's marginally less bad if it is related to what the team itself is supposed to be achieving, but it's still that one person. So you should be looking at how can we start to distribute that work and get it away from that being that one person's sole responsibility. But that's one area where just reality may be that they are the only person who has that knowledge at this point in time, so they have to be the person assigned to it. You don't have a choice. So there can be situations like that and there might be that you've got something that particularly has to get done within a particular timeframe and you really, really need to ensure that this happens and then maybe it's like do I trust the team to get it done? And then it becomes like, well, if you don't trust the team to get it done, then they're not prioritizing it, and what's the situation there? And then you've got.

Dave: 7:07

Probably. I think you're on thin ice here. I've got to say I'm not buying either of those two pieces. You're reinforcing the stratification or the silos on the team. Basically, you're saying, for the good of the company, we need to get something done quickly and make sure it's done right. Therefore, peter, you're going to do it because you're the expert within the company and I I'm not sure that that's the right mindset. No, that's that's me being english there. It's absolutely not the right mindset. The team has the problem, not the individual. The company has decided this team is going to be the one doing this work. The team can figure out how they're going to do the work, and it might be Peter, you know how to do this. So for the team, you're going to do it. Or, peter, you know how to do this, but we're not letting you touch it. We have Dave pick this up, because we need somebody else. You've got a vacation coming up or you are the only one who can do this.

Peter: 7:59

So we're choosing as a team to I think this partly depends on who's doing the assigning. I'm not so sure I don't know Well, because even in what you were saying there, it's that you said that if Peter you do it or David you're going to do it. So there's an organizational piece within the team where the team has decided how they're going to do it. On the team.

Dave: 8:32

If I have a scrum master or a product owner, that's stipulating who gets it done more and this is where it gets dodgy. There's a tech lead who takes that responsibility. My senior dev individual is doing that. I don't know that. That's the same as the team in their planning conversation deciding look, peter, we need this to get done. Can you take the lead on this? Or no, we're not going to get that done. This is something we need to get the skill set across the team.

Peter: 8:58

Yeah, and that's the a lot of that comes down to expediency the team deciding, like, when they're going to prioritize this and if they've got the leeway to do so, because that's really going to be the driver, right? It's like do we have the ability to distribute this across team? Do we have time? Is it something that has to get done right now and we have the time to take a step back, or do we have the sufficient leeway with the organization? We can say we know you want this done next week, but it's going to take us two months because we're going to train up the other people in the team to do this for you instead of this one person you've been in management for a long time, haven't you?

Peter: 9:35

I agree and.

Dave: 9:35

I disagree. I agree, but now I can imagine so many scenarios where the organization never frees up, like the conversations I'm seeing right now is I don't see any teams where they're not up against it, overloaded with work, always urgent.

Peter: 9:51

So in those scenarios.

Dave: 9:52

You're never going to get the healthy behaviors on the team unless the teams create the space for themselves, which only can happen by slowing down delivery.

Peter: 10:02

Yeah, and so this is, and I completely agree that what has to happen is you've got these external forces that are forcing this into the team, which is why I started from. You need to be aware of where this stuff is happening so you can stop it happening over time. But there's the economics of the organization that often end up interfering with this. I'm not saying it's okay, I'm saying this is where it typically happens. So there's a problem there that needs to be understood, where we're sort of saying okay, if we're really truly going to do this, we need to be able to give the team the autonomy to be able to make these decisions amongst themselves as to who's going to do this and how they're going to handle this problem. And so there's that piece of it that often we run into. This is where we get into why it's always we end up talking about. The leadership problems. Above is like making sure leadership understands that that's what a part of what they're agreeing to.

Dave: 10:57

Yeah, right, that they're maybe let's let's get back onto the team. What would you say? What are, what are scenarios, other scenarios where it may be okay to do this?

Peter: 11:08

um, well, one of the uh the piece here I noticed, like if they're not, if you're not doing collaborative work, then you could argue that you're not really a team at that point. If you're not collaborating towards a goal, if you don't have a common goal, then you're not really a team, you're just a group of individuals.

Dave: 11:24

Well, I mean, I think yes and no. I think you can still be a team, but it may be. I've seen this in a couple of areas. You can still be a team, but it may be. I've seen this in a couple of areas. One is in creative work, where you have quite very unique specializations around creative work, whether it's, say, animation or audio work and things like that. So are they, should they be using Scrum as a question? We talked about that a few topics ago, a few podcasts ago, and so is there. I don't know if there's benefit or not. We see this as well. We're an increment one. We have a team in our back office where there's accounting work and there's sales, business development work and marketing and things like this, and we'd get very little collaboration. We still kind of run a loose sort of scrum around that, mainly not because we want everybody supporting one another with a work, but we want to understand what's going on and give transparency to it. So it's valuable there.

Peter: 12:18

Yeah, Then it's really the value. Of it's not really scrum.

Dave: 12:24

No, absolutely.

Peter: 12:27

I'm not building a cross-functional team collaborating towards a set of common outcomes. They're not. That's just the fundamental root of that falls apart.

Dave: 12:38

So I don't think that one necessarily holds up under scrutiny particularly either we're layering in so much context on there to try and make it budget around, and I completely agree. It's a different context, right, I think. One other thing that I have seen is there are certain stories that come through which are which are sort of one dimensional. There there's a very clear expectation of what it needs to get that done. It's really only needs one skill set or and I'm I'm hesitating calling it a task, but basically it's a story that ends up being a task, for whatever reason and that you know it doesn't need multiple people collaborating on it.

Dave: 13:16

It needs somebody to do the heavy lifting and get it out of the door, whatever that might. So that can happen quite a bit.

Peter: 13:21

Yeah, so I mean it's the individual thing that needs to happen, so it would be more specific. So if somebody is going to, the servers need upgrading or we're going to upgrade.

Dave: 13:33

Exactly what I was thinking, yeah.

Peter: 13:36

And it's really just a it's work that needs to be done and it has to be, and you might want to ensure that there isn't just one person on the team that can do that. So many people should bear the pain.

Dave: 13:49

It's true, but it's also one of those things that too many hands are just painful. Sometimes you just need one person to take care of it.

Peter: 13:58

So yeah, and and that'd be a I mean, a fairly small thing. It's good for for certain use cases, but if, uh, if, you can switch to technologies where you are managing it, there's always going to be some underlying piece that you're going to need to make sure maintains currency. I this this question question came up the other day from some people in a young startup because they were talking about dependency freshness. Essentially, I introduced them to dependency freshness in an answer to that question, which was how much attention should they be paying to making sure that all the dependencies in their code are kept up to date? It's like, well, in their code were kept up to date. It's like, well, yes, you should.

Dave: 14:38

Now maybe if we I feel like we've covered a lot of bits and pieces there, are there any things? If I repeat the question, how would we answer it succinctly? So can you talk about when to assign or when not to assign stories to members of the dev team?

Peter: 14:52

And to clarify the question, we mean when you're external to the team assigning it to a member the dev team. And to clarify the question, we mean when you're external to the team assigning it to a member of the team, right?

Dave: 14:58

I don't think it's. I mean that shouldn't happen, right? So I'd say, within the team, when you're planning the work. If somebody on you know, is it whether external, within the team is assigning the work.

Peter: 15:08

Yeah. So anybody telling somebody else on the team at all that they should do work for any reason, because you're looking at, there's this agreement like who is going to take this on? Do you want people to be pulling the work to say, okay, I'll take that on, I'll go do that work and who's with me on this? Let's go off and work out how we're going to go about solving that and agree between the team who's going to take that work on. So it should never be that you're you have somebody in the team saying you do this bit, you do this bit, you do this, but you do this bit, ideally, um, and so that's the sort of the short answer to that. Is there anything you would add to that?

Dave: 15:52

I think only that there are certain cases where it's almost more likely to happen than others, and one of them is you're not really doing collaborative work on the team. There are skills you know there are, there are pieces of work coming through which is really very clearly going to one individual or one skill set. And then the other one is those stories which are really tasks which you know are one dimensional and they're clearly going to go to an individual.

Peter: 16:15

Yeah, and I think the two pieces where it's going to one piece to the point we were talking about is that if you've got a group of people who are all totally different skill sets, where there is no overlap or any need for them to learn each other's skill set, then yes, it's going to go to one of those individuals. But if there is need to potentially overlap those, then there may be a reason to step back and say can we make sure that more than one person can do this? So there's those two sort of differences. There's a bit of a difference between those two different nuances.

Dave: 16:45

And what are the?

Peter: 16:46

dangers. So the dangers? The dangers are that you risk destroying a lot of trust in the team. A lot of it comes down to that. If you're looking to create autonomy like autonomy purpose, mastery, mastery, autonomy purpose and you're looking to look at the team from that perspective, then the, the team's going to struggle to gain autonomy. If the if, everything's always being assigned within the team, that's, you're not going to be able to think about what is it that? What do I contribute? What do I do if you're always just being told what to do?

Peter: 17:22

The other side of that is you also lose agency If you're unable to actually feel like you're able to make decisions for yourself, and people who lose agency start to disengage with the stuff that they're doing and that, in turn, then this is where it gets into my side of the field, of course into risk, because that creates risk in the system. Risk because that creates risk in the system. So there's a lot of really important reasons that you want to create that agency and you want the autonomy because it allows people will then start to speak up and they'll have the conversations and you'll get better outcomes. Yeah, that's true.

Dave: 17:57

Anything you would add to that I think you could like. The only bit that I was thinking is around commitment or ownership on the team, but I think you covered that with your first point. I feel like we sort of touched on it. We're in an environment right now where there's always urgent work to be done. There's always something else, so speed and efficiency become a real priority and we have to recognize that's a little bit like stopping going to the gym.

Dave: 18:23

We're degrading our ability to do things and we need the team to keep practicing and sharing knowledge and bringing people leveling up in terms of knowledge and so on. And the way they do that is by determining who does the work within the team, with some sort of overarching strategy of where that team is going, what they're contributing to and supporting and so on. And every time we take the responsibility away from the team, I think we sacrifice that. It's hard enough to build as it is without, without um taking away that choice right, yeah, no, I'd agree with that.

Peter: 18:55

Okay, so do you want to sum this up, uh, in three points?

Dave: 19:01

so. So, number one generally don't do it. You want to see teams collaborating and we want to see two or three people swarming around a piece of work. Number two there are times when you might need to do it. Either, you mentioned it's a task, it's not really a story, or there are definitely skill sets that aren't shared across the team and that just, and there is no need necessarily to build those skills up across the team. Um, so so that, uh, there can be reasons to do that, and the thing to watch out for I think the cost of it is longer term. Part of it is it's it's almost a preventative thing. So the cost is that the team loses, agency disengages, doesn't own what they're delivering because they don't really feel in control of how they're solving problems, and that's insidious. It very quickly happens and takes a long time to cure.

Peter: 19:55

Yes, I think the one thing I'll add, just to wrap up, is the other place that I see this happening is where you have a hierarchy that doesn't reflect the formation of the team, and so you end up with work getting assigned by whoever the manager of the person is, versus the team structure, which goes orthogonal to the hierarchy, and that often ends up with the wrong things happening and the team never really comes together as a team because they're constantly being pulled off in a million different directions and it's like well, why am I working on this? This has nothing to do with the other thing that you said I was going to be working on, so something else to keep an eye on. Okay, thank you as always, dave, and we'll wrap it up there for today, so you can send us feedback a t feedback@ definitelymaybeagile. com, and don't forget to hit subscribe. And thanks again, dave. Thanks. You've been listening to Definitely Maybe Agile, the podcast where your hosts, P peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.