Developers oriented project management: Leave tasks unassigned
… and check why 5600+ Rails engineers read also this
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 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.
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.
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 ebook or by subscribing to the newsletter 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 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.