# Developers oriented project management: Leave tasks unassigned
As with software, **improving your company is an ongoing process consisting of
multiple small steps**. If you want your company to be more remote-friendly it
is also not _all-or-nothing_ decision. You can gradually start using techniques that
will bring you closer to your goal. This series of blogposts is not about
_why_ you should go remote, but rather _how_. Also, we believe that those techniques
will help you even if you are not planning to work remotely.
The first part was [about having very small stories](/2013/09/story-of-size-1/)
and how it helps everyone track progress and provides closure.
Today we are going to talk about leaving tasks unassigned instead of delegating
them to particular developers at the beginning of an iteration.
## You do not know how long given task is going to take
Let's start with an assumption. You want your developers to be doing **the most
important task for the project that can be currently done**. Usually this is one
of the most important criteria taken into consideration when assigning a task. So
let's say you have three developers and ten tasks to be done during the iteration.
Here is how you decided to split the work.
" rel="lightbox">
" class="fit">
Looks very promising. But here comes the reality. The most important task (no. 1)
takes longer than anticipated. And suprisingly one of the tasks (no. 3) turned out to
be easier and was finished earlier.
" rel="lightbox">" class="fit">
What effect does it have for your project? **Multiple times during this iteration
people are working on tasks which are not most important**. The first developer is
working on task 6, when task 4 and 5 are not even started. Task 7 won't be
finished by the end of the sprint even if it could be done instead of task 8.
And so on...
You can simply avoid these kind of problems by leaving tasks unassigned and
prioritized. Let your developer start the most important task when they are
free working on anything else.
## You might not know or be sure about the availability of your developers
If one of your developers gets sick or needs a little break your most
important tasks might be damaged. If you look at the original estimation
image the third developer is crucial to the success of this iteration. If (s)he
leaves the team due to health or personal reasons for some time there will
be some damage. The effects are similar to the ones mentioned in the previous
paragraph. People are not working on the most important tasks, the ones
**bringing the most business value**.
If you want **most possible freedom for your developers and coworkers** they cannot
be tight to the project they are currently working on. If your prioritiy is
for them to balance their personal and work life you cannot relay that they will
be available for given number of hours for the work on the project. Not to
mention the fact that the performance of developers vary greatly on daily
basis depending on their mood, health, and many external factors. There is only
one way to manage it. Surrender ;). Accept the fact that our power over reality
is limited and adapt often and quickly. Leave unassigned tasks to be done and let people
do them. If someone is not working today, someone else can simply do the task
instead.
## It all comes down to managing risk
Small, unassigned tasks are your tools for managing risk on daily basis.
The problems are constantly attacking our projects from all sides. People
effectiveness vary, illness happen, personal life interferes, tasks take longer,
external events occur. To finish things as planned is almost impossible. So
we need guidance that will help us deliver as much business value much as possible
and being constantly focused on most important aspects of our project. We need
flexibility in managing the project. The more the better. But good things also
happen. Sometimes people suprise us with their solutions and performance.
Opportunities arrive and we would like to take them. **So we need elasticity to
manage all that complexity that a software project is. And small, unassigned
tasks bring you that**.
Also it lowers the amount of _micrmanagement_ and attention that the project
needs. Instead of daily assigning tasks to people you just need to set their
prorities which you do for everything anyway.
## Find out more
There is more beyond what we wrote in this article. Find out in our
_["Async Remote"](https://blog.arkency.com/async-remote)_ ebook
or by [subscribing to the newsletter](//arkency.us5.list-manage.com/subscribe?u=1bb42b52984bfa86e2ce35215&id=4cee302d8a&group[15297]=4)
with tips and excerpts from the book similar in form to what you just read.
The newsletter will also containt exclusive content from the book that is
not published on the blog.
## In next episode
The next blog post will be about _Collective Ownership_ and what it has in
common with the techniques that we already described. [Subscribe](//arkency.us5.list-manage.com/subscribe?u=1bb42b52984bfa86e2ce35215&id=4cee302d8a&group[15297]=4)
to make sure you do not miss it.
## What is your opinion
Does your company practice these techniques? How is that working for you?
**Share your opinion in comments or on [twitter](https://twitter.com/intent/tweet?source=webclient&text=I+just+read+newest+%40arkency+blogpost+and+completely+disagree+%3AP)**.
## In this series
* [Story of size 1](/2013/09/story-of-size-1/)
* [Leave tasks unassigned](/2013/10/refactor-to-remote-leave-tasks-unassigned/)
* [Take the first task](/2013/10/take-the-first-task/)
* [Chronos vs Kairos: Find out how you think about time when working on a project](/2013/11/chronos-and-kairos/)
* [Developers oriented project management](/async-remote/)