"Borrowing" People
So here is a new thing for this blog, and maybe I can turn it into a series, who knows. As I've said many times, I feel strongly that getting your Scrum Master certificate is less an achievement in itself than an announcement that you have begun your apprenticeship. Now that I've been doing the job for a year, while I obviously have a lifetime of learning ahead, I can no longer consider myself a raw newbie. This seems like a good time, then, to start being more conscious about what I've learned so far.
The topic of this post is something that I intuited early on was a terrible idea, and while I did object then, it wasn't very strongly. I should have pitched a much bigger fit than I did as a brand-new, part-time Scrum Master.
Team Alpha has five members. Three of them have what I shall describe as high borrow-value. This is to say that they have expertise that places them in high demand for projects outside their nominal department. Note that they are in high demand as individual contributors, not as a team. They are often made available to other teams and other departments to help with (supposedly) short term projects, address critical customer issues, etc.
You probably don't have to deal with this if your teams are fully self-organized, autonomous, and feel safe to say no. I hope to help my workplace move toward that environment, but we don't currently have it. People are pulled off the team's planned work and into side projects with some frequency, sometimes as monads, sometimes as a pair (dev/qa, because we have yet to break that pattern). Sometimes the work is technically part of the team's sprint, with the understanding that the team will not be working on it; it's a solo project assigned to the team for tracking purposes.
The results of this have been clear for long enough now that I feel I can describe them accurately.
1. High barrier to team formation
Whether or not you buy the storming/norming/etc. model, we can probably agree that one of the ways a team becomes a team vs five people who happen to sit near each other is by doing work together. If the team doesn't actually do that, but is perpetually divided from the start, no one should be surprised that the team members think of themselves as not-a-team.
If this effect is predicted and acknowledged as likely, and the Management Layer demands it anyway, that makes a powerful and unfortunate statement about that group's support for the team both as a specific entity and as a concept.
2. It never stops
When you ask a team member to split their time between two teams, or to move to a second team for the duration of a specific bit of work, it becomes difficult to disentangle that member from perpetually being asked to support that work in the future.
It wasn't quite finished, we just have a few more tasks to polish off, we just need one more sprint.
No one else knows Subject Zed as well as they do, and we should definitely set up a knowledge-sharing session maybe for a couple of weeks out, but in the meantime could they just look at this issue.
Customer Bravo is screaming at us, and we haven't been able to debug this, we're sure this will only take an hour or two of their time.
And so on.
3. People get pissed off
Everybody (probably?) likes feeling needed, and it's great to know that you are making a critical contribution, but eventually this approach turns that positive into a drag -- an apparently endlessly growing series of projects you can never fully unload, without any real support. What's more, the team members who haven't been asked to pitch in with these efforts feel devalued, which makes it even harder for the team to gel, which then makes it even harder for knowledge to spread to unload the work, and hey presto, you have a grand vicious circle of your own creation.
In the short term this can look like an okay trade-off for efficiency, but it's terrible for the team.
The topic of this post is something that I intuited early on was a terrible idea, and while I did object then, it wasn't very strongly. I should have pitched a much bigger fit than I did as a brand-new, part-time Scrum Master.
Team Alpha has five members. Three of them have what I shall describe as high borrow-value. This is to say that they have expertise that places them in high demand for projects outside their nominal department. Note that they are in high demand as individual contributors, not as a team. They are often made available to other teams and other departments to help with (supposedly) short term projects, address critical customer issues, etc.
You probably don't have to deal with this if your teams are fully self-organized, autonomous, and feel safe to say no. I hope to help my workplace move toward that environment, but we don't currently have it. People are pulled off the team's planned work and into side projects with some frequency, sometimes as monads, sometimes as a pair (dev/qa, because we have yet to break that pattern). Sometimes the work is technically part of the team's sprint, with the understanding that the team will not be working on it; it's a solo project assigned to the team for tracking purposes.
The results of this have been clear for long enough now that I feel I can describe them accurately.
1. High barrier to team formation
Whether or not you buy the storming/norming/etc. model, we can probably agree that one of the ways a team becomes a team vs five people who happen to sit near each other is by doing work together. If the team doesn't actually do that, but is perpetually divided from the start, no one should be surprised that the team members think of themselves as not-a-team.
If this effect is predicted and acknowledged as likely, and the Management Layer demands it anyway, that makes a powerful and unfortunate statement about that group's support for the team both as a specific entity and as a concept.
2. It never stops
When you ask a team member to split their time between two teams, or to move to a second team for the duration of a specific bit of work, it becomes difficult to disentangle that member from perpetually being asked to support that work in the future.
It wasn't quite finished, we just have a few more tasks to polish off, we just need one more sprint.
No one else knows Subject Zed as well as they do, and we should definitely set up a knowledge-sharing session maybe for a couple of weeks out, but in the meantime could they just look at this issue.
Customer Bravo is screaming at us, and we haven't been able to debug this, we're sure this will only take an hour or two of their time.
And so on.
3. People get pissed off
Everybody (probably?) likes feeling needed, and it's great to know that you are making a critical contribution, but eventually this approach turns that positive into a drag -- an apparently endlessly growing series of projects you can never fully unload, without any real support. What's more, the team members who haven't been asked to pitch in with these efforts feel devalued, which makes it even harder for the team to gel, which then makes it even harder for knowledge to spread to unload the work, and hey presto, you have a grand vicious circle of your own creation.
* * *
In the short term this can look like an okay trade-off for efficiency, but it's terrible for the team.
Comments
Post a Comment