Collaborating on a task is great. Here's just some of the benefits:
- Having more eyes on a problem helps us work faster. Another human might spot the problem causing a bug we missed, avoid unnecessary work, and help us avoid getting stuck in rabbit holes.
- Hearing more voices when making a decision improves the quality of that decision. The earlier we get those voices in, the less rework we have to do.
- By having more ears in the room we can bake context-sharing into the development process, and reduce the need for separate meetings, processes, and roles dedicated to alignment.
- Some of our hard work can be draining. Sharing painful tasks can help keep us motivated.
- Collaborating on tasks means we need fewer tasks in progress at the same time. This means our backlogs can be shorter, which has benefits of its own that I wrote about previously.
I think most people (including me) don't feel like collaborating on tasks 100% of the time. I need time for myself as well. Given the advantages above though, it seems worthwhile to continuously look for ways to collaborate as much as possible, as long as it's sustainable.
This goal of collaborating more can be at odds with another popular goal: to parallelize work as much as possible.
If we create a large backlog of tasks ready to pick up then we intentionally make the barrier to starting new work very low. Starting new work takes less energy than gaining context on an in-progress task and supporting a colleague.
When I created backlogs like that I think it was primarily out of fear that without sufficiently parallelized work someone on the team (myself included) might find themselves with nothing to do. Never mind I couldn't even imagine what it would be like not to know a single useful thing to do. Never mind that having some slack in our schedules for small refactoring tasks and the like makes us more productive rather than less. Any stretch of time between an individual running out of work and the team deciding a next step seemed unacceptable.
There is a self-reinforcing feedback loop here: If we're used to picking up new work over helping finish in progress work then running out of new work is a big problem. By addressing the problem we further encourage ourselves to start new tasks.
One way to break out of this loop is using a work in progress limit, a maximum amount of tasks the team can have in progress at the same time. When at the limit an in-progress task needs to be finished before a new one can started. Retro on what the biggest obstacles are on setting the limit lower and try to remove them. A work in progress limit will force us to work on fewer things at the same time without having to give up the curated backlog (which is scary!).
Here's another self-reinforcing feedback loop incentivizing parallelization: As we practice collaborating on tasks our toolbox of collaboration strategies gets fuller. Until we have a full toolbox a lot of upcoming work can look unsuitable for collaboration, causing us to parallelize it preemptively and robbing ourselves of the opportunity to learn.
We can break this loop by committing not to parallelizing preemptively. This means accept some amount of pain and trying to find collaboration strategies to address that pain. Maybe it doesn't work and you'll fall back to parallelizing anyway. That's fine. The important thing is to try collaboration first.
How much do you collaborate on your team? How much do you parallelize work? Do you experience any tensions between the two?
Top comments (3)
I disagree with this sentence: "Starting new work takes less energy than gaining context on an in-progress task and supporting a colleague." I wonder what the breakdown is of starters vs finishers but I'm definitely a finisher.
Cool! Yeah, this is probably just personal preference more than anything else.
Does it matter for you where the task is at? Like, stuck in the middle, couple of commits in, but more than half of the work remaining vs. most of the work done and needing final touches?
One problem the backlog solves is, "how do I solve an isolated problem without a lot of context".
Is that really what we want? "Nail this in with the hammer" is a task I could do without context. But it leaves a lot of room for me to not understand the larger context: "this piece is structurally integral.", "behind this wall is a tank full of poison gas so make sure to use the exact nail we specified in the spec", etc. (p.s. supervillain laid construction business is booming over here).
My main reason for preferring collaboration/limiting parallelization is it helps force shared understanding of the underlying problem. From a business perspective: we work faster by giving everyone the context to know when to take a shortcut ("those prisoners have already been turned into zombies, we don't need to prepare breakfast"), or when to re-inforce something. From a personal perspective: I care when I am more than a hammer-swinger / code monkey. It's hard for me to connect a task with a vision. It's easier if, rather than solving a bucket of tasks, we're actually solving a problem. That needs a lot of context, alignment, etc that the backlog obviates.