Unselfish Tasks

Your team has a list of tasks that need to get done. How do you decide who does what? It seems simple on the surface but as soon as you start thinking about it, it becomes more and more daunting. This time around, I’ll discuss how I prefer to do it and why. Hint: it doesn’t start with just assigning everything and hoping it gets done.

Have you ever hired a company to help pack and move your stuff from one house to another? I have done this more times (including multiple cross country moves) than I care to think about. I usually observe something like this:

The lead mover comes in, surveys the house with you.
Meanwhile, one or two people start putting down floor protectors, etc. Someone else is out at the truck getting the other equipment and supplies ready.
The lead gathers the crew and walks them through the house, pointing out what needs to be done.
Each person goes to a separate room and starts boxing things up. When they need help, such as wrapping large furniture, they call for it.
Once a critical mass of items are packed up, some of the crew starts moving them out to the truck, usually starting with big stuff. The rest keep packing, one to a room.
The lead or number two is out at the truck making sure things are loaded correctly.
Once everything is packed up, everyone shifts to hauling. By this time, most of the big, time consuming items are already out at the truck.

When a good crew is working, it starts to look like a ballet. There is constant motion, they are timing their movements to avoid bottlenecks, and they move back and forth between tasks as needed. They move between specialized tasks and general tasks at the right time, constantly talking to one another about what needs to be done next. They come together when a task is bigger than one person and split up when there are a lot of small things to be done. Most crews I’ve hired did not take a break as a team. They take breaks when they need them. One or two may stop for a drink or lunch, but the rest keep going, taking turns. There is only one truck and often only one door of the residence they are going in and out of, so staggering breaks reduces contention around those choke points.

Without fail, the good crews kept working as a single unit with many hands. There was a rough plan, but they adapted as the day went along. The crews that weren’t so good were bunches of individuals focused on their own assignment. It showed in the time it took and the number of times furniture banged into walls.

Let’s apply some of that to software development. I will assume in this article that you have a team that works together on a project and that you are using some form of iterative development such as Scrum, but the principles apply universally.

Here’s your situation:

You have identified a backlog of work to be done. It could be work you want to get done during a defined period like a two week sprint or it could be a more open-ended backlog like you would have in Kanban.
Each item (aka user story) in that backlog is broken down into one or more tasks that need to be completed to call the item done.
You have a team of people who can do the work.

Now how do you assign the tasks to the team members?

The selfish way

Most teams pre-assign every task to a person at the beginning of their sprint. Either one person (usually the team lead) or the group sits down with the list of stuff and starts putting names to tasks. They do it intelligently: assess the skills required, knowledge of work already done in the area, and availability of each individual. Once all tasks are assigned to someone, the team begins to work.

This may seem ideal. You know who is responsible for getting each thing done and every person knows what they need to do. That’s the root of the problem with pre-assignment. When I said good moving crews always worked as a unit working towards the single goal, I bet you nodded your head in agreement. Because the moving crew acts as a single unit, a team, they see only one assignment and they all share it.

Unfortunately, that’s not what most software teams do. Once all those individual tasks have been assigned out, they promptly stop operating as a single unit. They’ll help one another out when asked, of course, but they rarely work as a team. Why would they? They’ve got their individual assignments and they need to get them done. Their bosses can turn themselves blue telling them teamwork is crucial and it will not matter. If the developer stops “their” task to help someone else for any significant time, the dread sets in. They dread the end of the sprint when there’s four tasks with their name that say “not started” and they have to explain why. They dread that they will be seen as “less productive”. They dread “more productive” team members will get the more important tasks in the future. They dread their annual performance review where they are told yet again they are getting a quiet pay cut¹. The result is that regardless of their own personal inclinations towards selfishness or selflessness, the team member ends up acting selfishly. After all, the rules are set up to encourage selfish behavior!

The forced selfishness leads to haphazard completion of backlog items. Let’s consider a scenario with two developers, Bob and Priya. Bob is somewhat new to the team and tends to work in just a few areas of the product. Priya has been on the team approximately forever and has a reputation for getting the hard stuff done. In the upcoming sprint, three important and risky tasks need to get done along with five pretty straightforward tasks that also have medium importance. The team estimated the important tasks could still all get done in a single sprint by a single person, so rockstar Priya gets assigned to them. Bob got assigned the five straightforward tasks.

Bob quickly moves through his work. Meanwhile, Priya gets her first and second items done, but because challenges did indeed arise, she barely started working on the third one before the sprint ended. Even though he is more junior, Bob could have started on that third one when it was apparent Priya was falling behind. If he had, then when Priya completed items one and two, she could pick up where he started if needed. But it was also possible that Bob, wit the extra time, could have gotten the whole item done. With the important work done, both of them work to complete the five straightforward items. If the hard items were truly more important, then Bob would have been better deployed on one of them. However, the team didn’t know on day one of the sprint that Priya couldn’t get them done, so Bob was not assigned.

That’s a made up scenario but it is quite close to what I observe happening when work is pre-assigned in the real world. Perhaps you are thinking, “Bob would have had to ask too many questions to be productive?” Let’s deal with that.

“Bob would have had to ask too many questions to be productive” is a very loaded statement. It assumes the only value we get from completing work is that the work is done. It doesn’t place any value on the improvement of Bob’s skills and knowledge of the product. If Bob is able to improve his skills on this item and get it done, then the team is better off in the long run. Priya can go on vacation knowing Bob can be trusted to handle anything that comes up. Without Bob getting that experience, we have the bus problem.²

Even when all team members are equally skilled, we can run into issues when pre-assigning tasks. Multiple people end up working on multiple backlog items. The amount of time any given backlog item takes to get done swells because only one person ever works on it. The quality assurance team ends up in a boom and bust cycle because for most of the sprint, backlog items are getting done at a very slow pace, then there is a big wave of backlog items completed at the end of the sprint. They go from “what do I work on?” to “how can I get this all done?” as the end of sprint looms. Too often, they stay in the “what do I work on?” mode because often nothing gets completed at all.

The increase in work-in-progress, combined with everyone thinking they have to get their assigned tasks done first, increases the chance of blocked or paused work. If Bob has to ask Priya to help him out on something, but Priya’s work is more important, Bob is most likely going to be told by everyone else to move on to his next thing until Priya is done. Pausing work comes with the cost of context switching: it takes time to resume work later. You need to remember what you were doing and may need to also fix things that got broken because of other changes in the system.

Increasing work-in-progress also increases the chance of having two sets of changes that conflict with one another (merge conflicts are rarely fun). This is a risk when working on the same backlog item as well, but the team tends to communicate more when working on the same backlog item. That communication reduces the risk.

So, to make a nice neat list of it, here are the perils of pre-assigning work:

Reduces team work by focusing team members on their own work and not the team’s work.
Less important work often gets done before more important work.
Reduces knowledge sharing and cross training.
The number of backlog items that are work-in-progress (WIP) increases.
More WIP means each item takes longer to complete and increases risk.

The advantages:

Creates a sense of comfort — but does that really help?.
Creates a false sense of predictability — only an advantage if you like lying to yourself.

The team-focused way

The team-focused way is to assign tasks only when someone is about ready to work on it. Here are the rules:

Each backlog item is prioritized in relative order. This is usually done by the product owner.
The team breaks down each backlog item into tasks. This can wait until the backlog item is ready to be worked on.³
No one is assigned to any task until they are ready to work on it. You may assign the backlog item itself to a person, but not the tasks. That person is responsible for understanding the goal of the backlog item and making sure the backlog item gets done correctly. They may or may not work on any of the tasks.
When you are ready for your next task, you take the highest priority task that you are able to do. This is not an ironclad rule but be careful about breaking it too often. Break it only when it is a matter of having the right skills. Do not break it because you don’t like the task.

That’s it.

The advantage:

The team is focused on the team’s work, not their own work.
Multiple team members have knowledge of each part of the solution. No bus problem² here.
The skills of each team member grow because the team members aren’t allowed to stay in their comfort zone.
Two brains are better than one. Team members don’t spend time figuring out who to ask when they need help and don’t spend time bringing that person up to speed with what’s going on.

The drawbacks:

There are people with specialized skills who may not be able to work on everything. Categorizing tasks by type helps some here, but not a lot, unless you have multiple people with the same specialization. If you have only one specialist and they’re the only one expected to do that work(a bus problem²), then pre-assignment is ok, but you should also be working on fixing the bus problem. I recommend reading Team Topologies by Matthew Skelton and Manuel Pais for more on how to handle complex team structures.
Too many people piled onto one backlog item can make for excess coordination overhead. To reduce this, you should aim for a 2-3 people working on tasks related to a single backlog item unless it is unique in some way.

Parting thoughts

As I wrote this article, I did a mental inventory of solutions I’ve been part of that had no business being as successful as they were. I also inventoried the ones that seemed to be all pain for little gain.

Yes, they correlated. The ones that were successful usually did not pre-assign tasks. The ones that were painful did.

So stop being paranoid that if you don’t have everything assigned up front, it won’t get done. At best, it doesn’t matter. At worst, pre-assignment creates the problem you were trying to avoid.

Footnotes

A quiet pay cut is when you get told you met most or all expectations, but your raise falls well short of real inflation. Your purchasing power has been cut even though the dollars went up. ↩
The bus problem refers to having a team member who is so indispensible that you wouldn’t know how to recover if the team member got hit by a bus. That is, removed from the team suddenly. Busses aren’t really that dangerous but people do leave teams all the time, even if only temporarily(vacation!). If you have a bus problem, you have a very real risk with a highly likelihood of occurrence whose potential impact grows the longer you avoid solving it. ↩ ↩² ↩³
Because you are reducing work in progress, you do not necessarily need to break down backlog items into tasks until the team is ready to start work on the backlog item. A reason to consider breaking down backlog items into tasks earlier is if you need to know how many backlog items you will get into a sprint with a high degree of confidence. More on that another time (maybe). The question of how much you need that high degree of confidence often brings out strong opinions, but I think there are a lot of factors that can come into play. In a perfect world, I am in the camp of where we do not create the tasks until the backlog item is being worked on. The world isn’t perfect. ↩