This is a mobile version, full one is here.

Yegor Bugayenko
9 January 2018

Five Stages of Microbudgeting

Microtasking, which I explained in an earlier post, works only when each task has a very specific reward for success and a punishment for failure. I believe that the best reward and punishment instrument is money. The budget is fixed, the programmer gets it only when the task is completed (reward), no matter how much time it costs; if it is not completed, there is no money at all (punishment). Pure and simple. However, a logical question arises: how can we know upfront what is the right budget? Who sets it?

When we started to play with microtasking in our projects, in 2009, we were asking programmers to estimate each task. It did work, but only with very simple and obvious tasks. More complex ones almost always suffered from either under-estimating or padding—numbers were either very small and task performers were complaining in the end, or they were too big and customers were asking for refunds. It was not a manageable situation.

Then, we realized that it would be better if all tasks were rather small, with exactly the same budget. We tried to use two hours as a universal and fixed estimate. Everything else that didn’t fit—programmers were allowed to reject. This model didn’t really work either, because our managers had to deal with a very large amount of rejected tasks and didn’t know how to make them smaller, since they were not programmers.

Finally, in March 2010 we found a solution, which was labeled Puzzle Driven Development (PDD). According to this concept: 1) Any task has a very small fixed budget (we use 30 minutes); 2) The task performer is allowed to complete only part of the task; 3) The code that is being returned to master must include @todo markers, called “puzzles”; 4) Puzzles are automatically converted to new tasks.

The beauty of this approach is that the most complicated part of the software project management—scope decomposition—is moved to the shoulders of those who are the best at it: programmers.

We are using PDD in all our projects now and have even created a public instrument for GitHub repositories, which allows anyone to play with PDD at no cost: This is exactly the same tool we are using in our commercial projects.

However, if and when you decide to apply microbudgeting to your project, together with PDD, there will be problems. Psychological ones mostly. In my experience, people go through five stages when they face microbudgeting for the first time:

You understand already that the vast majority of those who try to work with us can’t really get to the final point—they quit somewhere in the middle. Most probably something very similar will happen on your projects too.

What is the solution? I don’t really know.

Statistically speaking, three to five people out of a hundred manage to survive and become effective and productive. Thus, to build a team of twenty people you will have to screen and try at least 400.