One of the biggest problems in agile development teams is “effort”. Of course it is always about effort, because effort is money and we all like our money. In planning we can cope with effort quite easily: “oh that’s a week effort”, but when it comes down to “what to do today” we start struggling. And how can we complete the “one week effort” if we struggle with our daily work?
My proposal for solving this issue is: At the end of the day, whatever you have done this day, if it is not complete, throw it away!
How can I do such a statement? I believe that every single task can be done in a day. Many agile and iterative processes take care that tasks are small. But none does enforce that a task has to be finished in one day, but allow that tasks can run longer. The additional pain involved in throwing away work takes care that everybody gets more aware of what value they create a day. If a single task takes longer than a day this can have three main reasons:
The task is way too big
This is obvious, and sounds contradicting to the assumption that every task can be done in a day, but on closer look it is just about the correct definition of a task. Throw away what has been done and split the task. Note that whatever has been done is not wasted. Because it was not clear in the beginning that this task would take longer than a day, there has been too less knowledge about this task. At the end of the day there is enough knowledge gained to make smaller tasks. Be reminded: There is always a unit of work that can be done each day.
Progressing with the task is blocked by others
Do not sit down and wait. Take another task. Resolving the impediment can be done earliest next day, and the solution will be available earliest in the day after. During that time two other tasks could have been finished. Ideally find out if there is a unit of work that you can finish before moving on.
A simple task takes too long
My favorite. It is very much possible that the developer is heading into the wrong direction. Throw the futile coding away and restart the next day. Although managers might not believe in this, I see many developers nodding, knowing that when you are stuck its easier to restart. In most cases code quality and efficiency is also better.
Is this wasting time? No it is learning! Learning to create manageable tasks. It also will lead to more accurate task definitions. Even when there will be a higher rate of revert after implementing this philosophy, it will rapidly decrease. Awareness of the actual tasks, the value they contribute and the quality of the result are easier to check. And the effort gets manageable, because the “oh a week of effort” could be identified as 3 days effort.
There are also a lot more aspects on this. By either committing code every afternoon, or throwing it away it is made sure that the codebase for every developer is identical each morning. Merging code is easier, and incompatible changes are less likely. Also it is less likely that two or more people solve the same issue. Besides these technical advantages this also frees developers mind for a relaxed evening. And there is no need to remember all the details from the day before.
The most common counter argument against this is, that it is impossible to define a whatever complicated task so that it can be done in a day. This cannot be true, because there has to be a starting point somewhere, and after sitting down 4 hours, something has been done. Even after 10 minutes already something has been done. A unsplittable 2 week task, can and has always to be split to 10 working days. The point is that not the average developer has to do this split in his head, and deliver after 2 weeks, but all involved people do this. And thus results are visible next day already. And it enables also less skilled developers to contribute resolving more complicated user stories.
This article has been written on a single day, reviewed on another, translated on the third and published on the fourth day. At the end of each day something was done.