What is the preferred number of tasks to assign?

Question

I am going to lead a small team for the first time in my career and I am determined to not subject my team to the same issues that I perceive to have been subjected to as a programmer.

This question is about one such issue. Some managers that I worked with usually assigned one task at a time and assigned the next task only when I completed the task at hand. Some managers used to assign a few tasks at a time, along with their priorities and left me to tackle them in the order that I liked.

I like the latter method, since it allows me to take a break and work on another task, if I hit a wall on any one task. But the managers who preferred the former method probably did so for a good reason.

So my question is, how do I choose, as a manager, the right way of assigning tasks? If you feel your personal experience as a manager or programmer assigning or getting assigned tasks contributes to the answer, please share it.

As an engineer I tried to look at it as a operations research problem, but I just want to ensure that if there is anything more to it, I don't overlook it.

Thanks.

Answer 1

It doesn't matter, you'll get it wrong anyway. Only the individuals themselves knows what's best for them, so I think it is a bit presumptuous thinking that you can do that better.

So the answer is: don't.

Assigning tasks is bad for software development since it hampers creativity and creates negative stress among other things. Consider turning it around instead and have the team select tasks. That makes it a personal commitment which is much more likely to succeed. It also creates a bit of healthy pressure because they have taken it upon themselves to complete the tasks, instead of having someone else do that for them.

It also frees up time for you to spend on really important things, like prioritizing work and removing impediments for the team.

Essentially this is going from "push" to "pull".

Answer 2

Working on multiple tasks at the same time always pays for quality. Assigning one task at a time and waiting for completion of that task before assigning another task also not a right option. Sometimes you will be stuck at a problem or working for long time on the same task make you exhausted.

My suggestion is to assign multiple tasks and tell him the priorities upfront. Let developer has the freedom to choose between tasks as long as he is delivering with expected quality.

Answer 3

I'm currently the scrum master on a small team working with Agile SCRUM, and have previously been the lead on larger teams.

I think it's best to let people pick their own tasks - let people assign tasks to themselves - which I suppose is roughly analogous to assigning tasks to people and letting them drop them and pick up something else. Progress on a task - whether someone needs help, has chosen a task they can't complete, etc. can be checked in a quick meeting every morning where everyone tells the whole team how they're getting on. Letting people pick their own tasks allows them to be exposed to parts of the system they might not see otherwise, and empowers them to make sensible decisions about their own work and get on with it without having to ask you "what's next" every time.

I think being a given a task and being expected to complete it before being able to do anything else comes from a more waterfall approach. The idea there is that we've identified these tasks and these are the tasks we have to do and they have to be done in this order because that's what we planned. The problem with that is that when you actually come to writing code, it often (usually) turns out that the plan didn't cover everything and you need extra tasks, or not as many tasks, or different tasks, or the same tasks in a different order.

To sum up: I think it's best to be flexible with people. But that's just my opinion :)

Answer 4

Considered having a task list somewhere where people can sign up for things and then work on them as they have time.

If overall too little progress for a person? Unassign one or more items and put them back on the list.

Modern bug-trackers can also handle tasks, making for great visibility on how things are coming along for others to see. You want one which is integrated with your version control system so you can just put a marker in the commit message, that is automatically picked up by the task manager.

Answer 5

I have a board with all tasks in priority order. The rules are:

• If you don't have a task pull the top card off and assign it to yourself.
• If someone else on the teams knows more about the problem consult them, but do the work yourself.
• If you run into a blocker bring it to me and move on to another task.
• If you feel like your taking to long or stuck get a consult from me or another programmer. If that doesn't work we treat it as a blocker (bring it to me).
• You should only ever be working on one task.
• You can skip cards only if your the one who knows the most about the problem.
• You may pair program as needed.

All tasks are reduced to no more than 1-2 days worth of work.

This only works in a group that wants group ownership and don't have different highly specialized roles (ie. flash developer, dba, embedded device driver programmers, etc).

Answer 6

My opinion on this topic is: It depends.
It depends on the developer. For example, there are developers that like the freedom of the second method along with the additional pressure this method puts on the developer. It puts additional pressure on the developer, because he is not responsible for completing one task in time but several. I am such a developer, time pressure plus the freedom to achieve the goals in the order I like really makes me productive.
There are other developers however, that can't cope with that pressure and get unproductive.

What I want to say: There is no definite answer, it completely depends on your developers and you might need to switch your method for each individual developer.

Answer 7

It vastly depends on your coders. Some need to be assigned tasks, others are only productive when they actually choose their tasks.

It also depends on the tasks: keep in mind that at some point you'll need to assign a few tasks that nobody will want to do, but which still need to get done.

One thing to do is to have a reasonably complete list of tasks. Give some flexibility to your team members, in the sense that they should be allowed to split, when they feel it necessary, some tasks into smaller, bite-sized subtasks. This will give them a highly increased sense of having a say on what they're going to code.

On this list, make sure it's clear who is assigned which task, and which tasks depend on other tasks. If one task is needed to complete other tasks, it needs to be clear to everyone who to help or nag (depending on whether the assignee is working or not).

As much as possible, you want your coders to commit to their own tasks (they'll be more productive), and to help each other out (they'll work better as a team).

So start by letting them choose a couple of higher priority items from your list; things that they want to do, make it clear to them how the tasks relate to others' work, and encourage them to communicate while they work on things that depend on each others' work. (Avoid plaguing their work schedule with group meetings: they'll be just fine discussing things around a coffee or at each others' desks when needed.)

A point to keep in mind while doing so is to worry about the shier members in your team; they might be interested to work on this or that task but shy out of it because someone else with a bigger mouth wants to take care of it. Identify them quickly and force the odds a bit by periodically letting them choose their tasks first.

Your team will likewise include a few members who need to be assigned tasks. For these, proceed a bit like with the shy members (they'll frequently be the same ones, in my experience). The trick here is to know that, while most people dread making decisions out of the blue, they'll usually like to be faced with picking one option among a number of choices. what differs from a person to the next is the threshold. For some it's multitudes of options; for others it's as little as a single one. So, try to work out a number they're comfortable with. Then, in a first step, ask which among this, this and that task they'd rather do; and in a second, whether there is another task you hadn't thought of which they'd like even more. This will inhibit their fright and get them to choose their tasks without realizing it.

Another point to keep in mind is that you need to occasionally be firm. At the end of the day, you're the boss and if nobody is volunteering for a task in particular, you'll need to assign it outright. There are of course polite ways to do it, which I'm sure you know by now.

By the same token, be flexible. Some tasks will never seem to get done, because whoever volunteered quickly finds it boring or hard or whatever, and starts focusing on something else. Monitor for this and (gently) remove these tasks from them if needed. Your team members will appreciate if it comes from you reassigning their tasks, rather than them loosing their face in public ("sorry, I couldn't make it").

Answer 8

The approach that I took when I was leading a team (6 people, 18 month project), which worked out well and the team members seemed to happy with (it could have done with some better tools/automation, but we didn't have the budget to buy pencils, let alone a task management system), was to start out by identifying all of the tasks and subtasks that needed to be accomplished for an iteration, and assign a rough difficulty estimate with the whole team. Then I'd take that list back, refine it if necessary, prioritize tasks, and assign team members to specific tasks.

Each team member would then get sent their entire detailed task list, prioritized and with time estimates, deliverables for that task, etc, plus a shorter overview of what tasks the other team members were working on. Everyone had the opportunity to get back to me if they felt that the timelines needed to be modified, or the deliverables weren't clear enough, etc.

Each evening, the team members would send me an email with what subtasks they had worked on, and how far along that task was. This let me see how well our time estimates were, and to keep an eye on what people were spending time doing. If someone was spending a lot of time on something with a lower priority, while higher priority tasks were not being done, then I'd have a discussion with them as to why they felt they needed to be working on first, and see if there was a way to juggle around tasks in order to ensure that dependencies were being finished before they were needed.

This worked out particularly well because the team members knew everything that was expected of them for a given iteration, which helped them make better design/implementation choices for their modules (we had an overall design, but the details were left up to the team members who were implementing a particular feature), and allowed team members to easily collaborate since they knew exactly who was working on what feature. I provided guidance in terms of listing out priories and dependencies, but left it up to the team members on what order they wanted to work on tasks.