This is a mobile version, full one is here.

Yegor Bugayenko
28 November 2017

How Micro Is Your Tasking?

"What are you doing now?"—when you hear this question from your boss, be aware: you're dealing with a micromanager. Keeping us busy is the key objective of these creatures and this is what makes them so annoying. To the contrary, effective managers make sure we are productive, meaning that our results satisfy their expectations. They are not interested in knowing what we are doing to deliver them—they manage the project, instead of managing us. And the first step to making the project manageable is to decompose its scope into smaller pieces.

Imagine you want to re-design your apartment, having a few thousand dollars for this job. You hire a group of people and give them all your money up front. They ask you to come back in two months, when everything will be ready. You say "OK" and wait for two months. I'm sure you already know what I'm getting at—this project most probably will be a failure, to some extent. In the worst case you won't see these guys ever, they will just steal your money. In the best case, they will do something that will look "nice," but not as nice as you expected.

Why do we micromanage?

What do you do in order to increase your chances of getting the best case scenario? That's right, you micromanage them: you visit them every day, you ask them the famous "What are you doing now?" question, you push them when they are getting lazy, you control, you dominate, you annoy, you "stay on top," you play the guilt card when they miss or forget, you punish them every way you can.

You don't do that because you're evil. You just know that otherwise they will trash your apartment, will forget things, will miss something, will make mistakes, will spend more time and money than they are supposed to, will choose wrong fabrics, will purchase the furniture you don't like, and will do many other things you're well aware of if you've ever dealt with interior designers and house builders.

The more aggressive you are, the higher the chances you win.

And it's not because you are evil. You're not evil, you're stupid (not you personally, my dear and respected reader, but you get the point).

The problem is that the project is not manageable. That's why you have to resort to the last possible measure—micromanagement. Why is the project not manageable? Because its scope is not broken down into pieces. It contains a large single job called "Redesign The Apartment."

One of the key success factors for manageability is the famous 0/100 rule, which requires any task to be either "in progress" or "complete." There can be nothing in the middle. When such a rule is in place, the task can be delegated to its performer and they can become responsible for its completion, they can be trusted.

We can't "trust" our single large task to the performer, simply because it's too big to be trusted. If they fail, the cost of failure will be too high. We have to take a micro-scope and get into the task to manage it from the inside, annoying its performers, whom we are supposed to trust. The micromanagement we do is inevitable, because the scope is not broken down.

Scope decomposition was invented mostly in order to solve this very problem: to make the project more manageable. We need small tasks in the scope in order to be able to delegate them and never go inside in order to check what's going on there, who is doing what, why, and where.

The smaller the tasks we can break the scope into, the better.

How small can tasks be?

In our projects we break project scope into tasks of 30 minutes each. This may sound too extreme for you, but it works for us. We call them micro-tasks. We started to practice micro-tasking about seven years ago. We experimented with different task sizes, from 10 hours to 15 minutes, but eventually came down to 30 minutes.

When tasks are bigger, we lose the manageability and simply get back to macro-tasking. When tasks are smaller, the context switching overhead becomes too annoying.

In our experience, a senior programmer, if fully dedicated to a project, completes 6-10 tasks a day. This means that they spend 3-5 hours working, while the rest of the time is spent on doing something else. This is a much more effective use of work time than we can achieve with traditional macro-tasking management, where programmers barely work for two hours a day, spending the rest of their time on something else (my personal observation).

What obstacles did we have?

If you decide to go for micro-tasking, you will most likely have the same or similar obstacles that we've had. Here is a short list of them and my advice, which may help if one day you decide to break a "Develop a Mobile App" task into, say, 2,500+ micro tasks:

There could be something else, but this is a more or less an exhaustive list of the problems we were faced with.

Where micro-tasking didn't work

Obviously, any approach has its pros and cons. Micro-tasking seems to be the most effective management paradigm for us. However, it's not applicable everywhere, according to our experience. There are territories where we failed to apply it.

Everything else, including programming, unit testing, manual testing, performance/load testing, integration testing, deployment, code review, documentation, and even training, can and must be managed via micro tasks.

What benefits do we get?

The most important benefit of micro-tasking is that the project becomes more manageable, as was mentioned above. Here is a more detailed break down:

The benefits programmers get overlap with our benefits. If they are professional and motivated enough they find it effective and productive to work with micro tasks, which are always well defined and properly paid.

Are we monkeys or not?

Now the most typical complaint we hear about micro-tasking is: "It is for junior programmers who are OK with being code monkeys." To be honest, I also thought so a few years ago, when we started to experiment with XDSD. What I quickly found out is that the most professional and self-motivated developers were enjoying micro-tasking, while their less mature and less skilled colleagues were finding it difficult to keep up.