Stop Killing Developers Creativity
“When you start working on a ticket, press ‘Start Progress’ - this will change its status to ‘In Progress’; if you’re getting distracted from your work for more than 1 hour, press ‘Stop progress’” - Carlos reads to himself
2 hours later…
And Andrea is certainly right - collection and analysis of statistics of how much time developer spent on a task, will have a profound impact on future planning. But this is only one side of the medal.
“The Reverse side of the Medal”
I am strongly convinced that the company thus loses more than it gains. You see, tracking time in such a way forces developer to always think about time. Now Carlos can’t afford himself to try this new tool Y, which could, in the long term, improve the quality of code and reduce the amount of errors, which ultimately would make company’s clients more happy (the more stable our software
- the better user experience is, right?). Or he could have come up with a way to improve existing application’s architecture, because he had time to think about it. Now he hadn’t, you take it from him.
There is also such thing as ‘Estimated time’ - time, in which task is expected to be completed, usually estimated by team leader or head of development. When you have only logging, developer mostly thinking of how to do his job in less time. In this case, there is obvious time limit and often Carlos will have to hurry to catch the allotted time.
Even if the manager says “do not worry, if you go over the estimated time”, this does not change anything. Developer will still be thinking of time.
But here is good news. If you want developer to be mechanical robot, which only makes tickets assigned to him, then you are on the right track. Moreover, with time limit specified, Carlos could focus better on the task and make the most of his brain. It’s like deadline, only in miniature.
Opinions regarding the use of deadlines generally diverge. Most agree on the fact that, in the long term, constant focus on some task and working more than usual, lead to fatigue. Here the ability to keep the balance is very important - sometimes tough deadlines make us summon strength and ship the product on time. Note that sometimes doesn’t mean “you must complete this task in about 4 hours, and then hop on the next one.”
What can we do about it
Let developers estimate the value of ‘Estimated time’ themselves. We want our developers to be independent. As for the logging, here as well, there are various options. I’m not asking you to opt-out tracking time, no. Just save Carlos from unnecessary stress and the need to press buttons and constantly keep track of time. For example, we can take into account the time between he accepted the ticket and completed his work on it (set status to resolved). Yes, the accuracy will suffer, but you can take this instrument error into account. I’m sure you can easily come up with another couple of ways.
Hope I managed to show you what could be the consequences if you’re forcing your developers to think about time. Tell me what you think? Is that true for your company? Are you satisfied with it? Answer in comments or send me an e-mail.