8 ms·

Focus: Assign multiple engineers to the same task

46 points by signa11 5y ago

rmchugh 5y ago
This is the essence of Mob Programming as popularised by Woody Zuill. Can recommend.
redhale 5y ago
I mostly agree in principle, but I think this quote illustrates the downside of this approach if applied all the time: > Oftentimes they will either have to slow down and learn this and that, by reading some stuff online and internally asking questions. That is a slowdown and it often generates a lot of interruptions and delays for everyone. Having to solve a problem that you're not _initially_ equipped to solve is often how you _become_ equipped to solve similar problems in the future.
- voiper1 5y ago
  But... 1) The long tail. You may never face a similar problem in the future. 2) Surely being forced to figure it out on your own is not the most productive and healthy manner of improving your skills. All human performance areas have teachers and coaches.
- btheshoe 5y ago
  I often find it easier to learn how to do a new thing when I'm shown how to do the new thing and can ask questions about the new thing to someone who understands how the thing works. It could be that this pair approach can actually help skill development
  - pydry 5y ago
    I vastly prefer this approach to being onboarded. Documentation is always way too vague about or just plain missing critical details and too specific about things I don't care about.
- crispyambulance 5y ago
  > Having to solve a problem that you're not _initially_ equipped to solve is often how you _become_ equipped... That's been true in my experience. Almost every step forward in my career development has involved a very uncomfortable and uncertain adjustment period. It helps immensely to have people around who are curious, receptive to questions and who can empathize and provide some guidance. It seems that the more heavily project-management-oriented a workplace is, the less slack there is for this kind of career development. It's not uncommon to have workplace cultures where one has to prove themselves in some kind of "sink-or-swim" or "show-how-you've-suffered" scenario before they are deemed "worthy" of consideration. It's sort of visible in the culture of stackoverflow which I think of as a kind of microcosm of the attitude in many workplaces.
  - redhale 5y ago
    My previous company called that somewhat uncomfortable feeling where you sort of know how to proceed but not completely the "learning edge", and it's a term I really like. I always aim to keep myself and my team on that learning edge to keep people growing (avoiding complacency/stagnation) while not exposing them to too many roadblocks. It's a constant balancing act.
pjc50 5y ago
Takes a long time before it acknowledges pair programming, but it gets there in the end. But it never even attempts to quantify the bottom line: > the work actually assigned getting done faster as people working together can get it done much faster The only thing that's definitely true is the task is consuming 2x FTE salaries for its duration. Does that translate into 2x faster progress? It's extremely hard to say, as all the previous struggles with software estimation and time recording have shown us. The challenges are not dissimilar to allocating work to execution units within a CPU; a programmer with two tasks assigned who swaps between them when blocked is "hyperthreading" and usually achieves higher throughput, although frequent task switching incurs time costs. So in practice engineers have multiple things in progress, both for their own account and things they're helping other people with. That is, after all, part of the point of telling other people about it in standups. > Probably at some point you have experienced how quickly things can get done, especially in case of emergencies (like “OMG, something is wrong in production”) where multiple people with different skills and knowledge jump together into one “room”? This is however a warning sign to me. There are a lot of mechanical systems you can run at more than their rated performance in emergencies before experiencing burnout, and the same applies to humans. You can't just crank the team up to "flank speed" and leave it there. (irrelevant aside: apparently the USN have called their O365 migration plan "Operation Flank Speed", which I find unreasonably funny. https://federalnewsnetwork.com/navy/2021/05/navy-transitioning-more-than-200k-users-to-new-online-collaboration-platform-next-week/ https://federalnewsnetwork.com/navy/2021/05/navy-transitioni... )
- redis_mlc 5y ago
  There's no short-term advantage to pair programming when one or two of them are already experts. However, usually you can think of a way to turn it into some kind of lesson/benefit like, "While I'm updating this, can you see how to do that operation in one step?" There are times when anti-pair programming is helpful. An example is in large companies, where sometimes it makes sense for one developer to assign themselves a particular role to "deal with" an internal inefficiency, like a bloated approval process, or a broken internal tool. Over time that dedicated person can improve or workaround that problem with persistence, freeing fellow developers to focus on more productive tasks. So taking one for the team.
PopGreene 5y ago
> Let's contrast with an approach where two (or even more) engineers with somewhat disjoin (sic) skills were assigned to one task... Holy crap! He's invented the Software Development Team!
thenoblesunfish 5y ago
I think you could also argue that the solution here is not to assign multiple people to one "task", but to write "tasks" that are atomic enough that one person can and should do them, and use some higher-level abstraction for problems that require teamwork.
- wutwutwutwut 5y ago
  What problems do you work on in isolation without teamwork? No talks about design, no code reviews, no functionality review, no one updating the documentation etc?
vekker 5y ago
I've always been annoyed with JIRA's limitation of 1 task = 1 assignee, but IMHO assigning 2+ people to every task by default is overdoing it. Depending on the product and the team, many tasks can be pretty straightforward if the backlog grooming is done often and the tasks are prepared well. Also, many developers chose to become a developer because they have a more introverted personality and they like working on their own for long stretches of time. If you force them to always work together or sync up with each other more often than is necessary, it will lead to more burn-out.
pydry 5y ago
I agree with mostly all of this but I find in practise that developers often have a kind of instinctive revulsion of this kind of joint collaboration. There are a lot of people who hate pairing for instance. I'm not really sure why and I'm not sure what to do about it. I certainly don't want to force them work in a way that doesnt sit well with them, but on the other hand you lose a lot of the benefits of closer collaboration highlighted here. I also get the feeling that this instinctive revulsion is often rooted in something developers usually dont want to speak openly and honestly about (e.g. fears about being commoditized or the mental stress of having your every keystroke scrutinized). This makes it almost impossible to create solutions which mitigate these issues (e.g. a pact) since the issues are shrouded in mystery.
- heisgone 5y ago
  As you point out, the issue is forcing people to some artificial collaboration. People don't dislike collaboration. They dislike the lack of autonomy. In my experience, Scrum teams have some of the worse collaboration. People are focused on their assigned task and don't have time to speak to others. The issue here is not that a task is assigned to one person. The issue is that building software around the concept of fragmented tasks is an horrible way of managing work. The author of this blog mention reading "The goal", which is a Taylorism/lean bible. That's the issue.
helsinkiandrew 5y ago
> The coding part might or might not be pair-programming If more than one developer is working on a task and they aren't pair-programming doesn't that suggest that they have looked at the task and how to implement it and split the task into independent sub tasks that they are each working on. But isn't that the approach to just about any modern development process? In just about any team I've been in we've all had a good understanding of the architecture and issues/approaches that other developers are working on both formally and informally.
elisbce 5y ago
The purpose of assigning one person to a task is NOT that the assignee has to do it all or know it all. The purpose is to have a single point of responsibility that oversees things and get it done. Assigning to multiple persons without clearly dividing responsibilities is doomed to fail. And what's worse, when the task failed, people point fingers towards each other and no one wants to take responsibility.

46 points by signa11 5y ago

This is the essence of Mob Programming as popularised by Woody Zuill. Can recommend.

I mostly agree in principle, but I think this quote illustrates the downside of this approach if applied all the time: > Oftentimes they will either have to slow down and learn this and that, by reading some stuff online and internally asking questions. That is a slowdown and it often generates a lot of interruptions and delays for everyone. Having to solve a problem that you're not _initially_ equipped to solve is often how you _become_ equipped to solve similar problems in the future.

voiper1 5y ago
But... 1) The long tail. You may never face a similar problem in the future. 2) Surely being forced to figure it out on your own is not the most productive and healthy manner of improving your skills. All human performance areas have teachers and coaches.
btheshoe 5y ago
I often find it easier to learn how to do a new thing when I'm shown how to do the new thing and can ask questions about the new thing to someone who understands how the thing works. It could be that this pair approach can actually help skill development
- pydry 5y ago
  I vastly prefer this approach to being onboarded. Documentation is always way too vague about or just plain missing critical details and too specific about things I don't care about.
crispyambulance 5y ago
> Having to solve a problem that you're not _initially_ equipped to solve is often how you _become_ equipped... That's been true in my experience. Almost every step forward in my career development has involved a very uncomfortable and uncertain adjustment period. It helps immensely to have people around who are curious, receptive to questions and who can empathize and provide some guidance. It seems that the more heavily project-management-oriented a workplace is, the less slack there is for this kind of career development. It's not uncommon to have workplace cultures where one has to prove themselves in some kind of "sink-or-swim" or "show-how-you've-suffered" scenario before they are deemed "worthy" of consideration. It's sort of visible in the culture of stackoverflow which I think of as a kind of microcosm of the attitude in many workplaces.
- redhale 5y ago
  My previous company called that somewhat uncomfortable feeling where you sort of know how to proceed but not completely the "learning edge", and it's a term I really like. I always aim to keep myself and my team on that learning edge to keep people growing (avoiding complacency/stagnation) while not exposing them to too many roadblocks. It's a constant balancing act.

pjc50 5y ago

Takes a long time before it acknowledges pair programming, but it gets there in the end. But it never even attempts to quantify the bottom line: > the work actually assigned getting done faster as people working together can get it done much faster The only thing that's definitely true is the task is consuming 2x FTE salaries for its duration. Does that translate into 2x faster progress? It's extremely hard to say, as all the previous struggles with software estimation and time recording have shown us. The challenges are not dissimilar to allocating work to execution units within a CPU; a programmer with two tasks assigned who swaps between them when blocked is "hyperthreading" and usually achieves higher throughput, although frequent task switching incurs time costs. So in practice engineers have multiple things in progress, both for their own account and things they're helping other people with. That is, after all, part of the point of telling other people about it in standups. > Probably at some point you have experienced how quickly things can get done, especially in case of emergencies (like “OMG, something is wrong in production”) where multiple people with different skills and knowledge jump together into one “room”? This is however a warning sign to me. There are a lot of mechanical systems you can run at more than their rated performance in emergencies before experiencing burnout, and the same applies to humans. You can't just crank the team up to "flank speed" and leave it there. (irrelevant aside: apparently the USN have called their O365 migration plan "Operation Flank Speed", which I find unreasonably funny. https://federalnewsnetwork.com/navy/2021/05/navy-transitioning-more-than-200k-users-to-new-online-collaboration-platform-next-week/ https://federalnewsnetwork.com/navy/2021/05/navy-transitioni... )

redis_mlc 5y ago
There's no short-term advantage to pair programming when one or two of them are already experts. However, usually you can think of a way to turn it into some kind of lesson/benefit like, "While I'm updating this, can you see how to do that operation in one step?" There are times when anti-pair programming is helpful. An example is in large companies, where sometimes it makes sense for one developer to assign themselves a particular role to "deal with" an internal inefficiency, like a bloated approval process, or a broken internal tool. Over time that dedicated person can improve or workaround that problem with persistence, freeing fellow developers to focus on more productive tasks. So taking one for the team.

PopGreene 5y ago

> Let's contrast with an approach where two (or even more) engineers with somewhat disjoin (sic) skills were assigned to one task... Holy crap! He's invented the Software Development Team!

thenoblesunfish 5y ago

I think you could also argue that the solution here is not to assign multiple people to one "task", but to write "tasks" that are atomic enough that one person can and should do them, and use some higher-level abstraction for problems that require teamwork.

wutwutwutwut 5y ago
What problems do you work on in isolation without teamwork? No talks about design, no code reviews, no functionality review, no one updating the documentation etc?

vekker 5y ago

I've always been annoyed with JIRA's limitation of 1 task = 1 assignee, but IMHO assigning 2+ people to every task by default is overdoing it. Depending on the product and the team, many tasks can be pretty straightforward if the backlog grooming is done often and the tasks are prepared well. Also, many developers chose to become a developer because they have a more introverted personality and they like working on their own for long stretches of time. If you force them to always work together or sync up with each other more often than is necessary, it will lead to more burn-out.

pydry 5y ago

I agree with mostly all of this but I find in practise that developers often have a kind of instinctive revulsion of this kind of joint collaboration. There are a lot of people who hate pairing for instance. I'm not really sure why and I'm not sure what to do about it. I certainly don't want to force them work in a way that doesnt sit well with them, but on the other hand you lose a lot of the benefits of closer collaboration highlighted here. I also get the feeling that this instinctive revulsion is often rooted in something developers usually dont want to speak openly and honestly about (e.g. fears about being commoditized or the mental stress of having your every keystroke scrutinized). This makes it almost impossible to create solutions which mitigate these issues (e.g. a pact) since the issues are shrouded in mystery.

heisgone 5y ago
As you point out, the issue is forcing people to some artificial collaboration. People don't dislike collaboration. They dislike the lack of autonomy. In my experience, Scrum teams have some of the worse collaboration. People are focused on their assigned task and don't have time to speak to others. The issue here is not that a task is assigned to one person. The issue is that building software around the concept of fragmented tasks is an horrible way of managing work. The author of this blog mention reading "The goal", which is a Taylorism/lean bible. That's the issue.

helsinkiandrew 5y ago

> The coding part might or might not be pair-programming If more than one developer is working on a task and they aren't pair-programming doesn't that suggest that they have looked at the task and how to implement it and split the task into independent sub tasks that they are each working on. But isn't that the approach to just about any modern development process? In just about any team I've been in we've all had a good understanding of the architecture and issues/approaches that other developers are working on both formally and informally.

elisbce 5y ago

The purpose of assigning one person to a task is NOT that the assignee has to do it all or know it all. The purpose is to have a single point of responsibility that oversees things and get it done. Assigning to multiple persons without clearly dividing responsibilities is doomed to fail. And what's worse, when the task failed, people point fingers towards each other and no one wants to take responsibility.