Stuck?  Here is my brilliantly original recommendation: Take tasks that aren't done, and give them to someone new or different.

I frequently talk to clients and friends who are just not getting software out the door.  They are frustrated, and they wonder why the development team seems to be blocked.  There are many reasons that this can happen, but most of these reasons can be eliminated by a simple, even simplistic, management technique.  Consider the most basic logic:  the team is blocked because tasks aren't getting done.  Some person is not finishing some task.  The task might get done more quickly if you can find a different person with a chance of finishing this task more quickly.  So, the management management method is: Take tasks that aren't done, and give them to someone new or different.

"Yes," you respond.  "That is a simplistic and even idotic diagnosis.  This situation is a lot more complicated."

"Yes," I admit.  "The situation probably does look complicated."  Here are some reasons I have seen for this situation:

• You divided the work between more than one team, and you don't have control over the other team
• You assigned tasks in big batches, and you don't know whether tasks in the middle of the batch  are getting done promptly.
• It's difficult to find or to hire someone who is qualified to pick up the new tasks
• You promised responsibility for a certain role to one of the lagging parties
• You committed to a fixed price contract, and you want to see what gets delivered at the bitter end.
• I don't want to offend a valuable team member / partner.

Those are real constraints that involve real relationships.  And yet, there are things you can do to enable reassignment to happen almost automatically, without offending people.

Run a single team with a single task list.  This gives you a bigger team to draw from.  If you divide your effort into two teams with two task lists, then you have only half as many people to pick up each task.  Also, if there are two teams, and a member of one team can't be given the "if you don't like it, fix it yourself" message about a task assigned to the other team, his only recourse is to blame the other guys, which is not productive.  This is why I don't like "Outsourcing" part of a project to an "outside" group, and I describe Assembla's goal as "building a single global team", with everyone presumed to be on the "inside".

Share all information. previous post about this.

Assign only one step at a time.  If you assign a whole bunch of tasks to one team member, then those tasks are not available for other team members to work on.  This can only slow you down.

Allow team members to claim unclaimed tasks.

Complain once about an un-done task, and then reassign it.  This will get you moving a lot faster than if you try to work through the situation with the first assignee.  If the task is do-able, you will get it done.  If the task is inherently impossible, then the new guy will point this out, you will learn something, and the first guy will have a nice feeling of vindication.  You can see that with this is also an easy way to upgrade your team.  The weak performers run out of tasks, and are replaced by strong performers.

Make it easy to join the team.  This is the key enabler.  Most software projects put a lot of barriers in the way of new team members.  At Assembla, we try to set the project up so it's easy to join, see what is happening, and start participating in builds.

"Should we shut down the first effort when we bring in someone new?" you might ask, "or should I just let two people / teams work on it?"  The answer to this question depends on how you balance cost control and skilled resource shortages with speed.  Clearly, it's more cost effective to take the old guy off the project and not have duplicate effort.  However, you will have faster average progress if you can afford some duplicate effort.