A common question raised by customer-side management:
But even if the question is not asked explicitly, does not mean nobody has doubts alike.
I worked in various environments. Let me review the most common solutions and their pros and cons.
Don't track anything!
This sounds like a programmer's paradise: one spends time to whatever is more productive at the moment. "Trust is everywhere!"
But let's look at a situation when some urgent side tasks are thrown to the engineer. Say, we had a release and discovered some small bugs after it. We need somebody to look at them and state the estimate for fixes.
Such investigation tasks may take considerable amount of time. But this is easily forgotten to be mentioned on stand-ups (or at worst cases one may be even forced not to mention them with a reason "This does not "bring any value to the current sprint", but let's leave such dullards away).
Besides, in this case you kind of "hide" from yourself and the team the real efforts spent for particular tasks. Sometimes one may spend few hours each day to investigate some naughty bug. And having spent 10 hours one creates a task for minor refactoring that would take 2 hours to be done. I think it's not fair!
Track your every billing hour
Any creative work needs a concentration and the concentration is very fragile.
During the workday anyone may be distracted by some "not-directly-my-work" questions or attend some short group sync-up meeting. Where to track that time? Should I create a ticket for every activity over 30min I had during the day? And what to do with those below 30min? Track to the current task? Why wouldn't I track some time for more-than-30-min activities to the current task too?
This may lead to some inflation of minor tasks.
This forces me to lie. And I don't want to! And I don't want to create a ticket for every activity either!
Track 5 to 8 hours makes perfect sense
This does not force an engineer to lie and gives a legal way to omit some really not important details (e.g. 10 minutes watching cat gifs after lunch).
This 30% buffer is enough to minimize controlling pressure and to concentrate on what has been really done.
A customer may ask: Why I pay for 8 hours and get only 5?
Because this is not really "hours". This is a 5-hours productive result of 8 hours workday. Which is pretty good, as for me.
Besides, those cheating with 5 hours can cheat with any amount of hours at all and without tracking too.
I believe the modern ways of management are about openness and transparency. So why not to give the customer (especially PO) an ability to track not the time but the efforts for particular tasks to identify problems earlier. Isn't it the "agile" is all about? These time records could be a good supplementary material for daily stand-ups, especially in remote teams.
Also do not forget that hours registered per day is not a real metric of performance, progress or anything alike. This is just a documented version of the stand-up meeting with some tracking capabilities.
If you're afraid this metric might be used as a punishment reason, probably better not to track anything at all.
- How to control software engineers?
- How I, as a customer who pays huge bags of cash per hour to this hippies, can really know that they are not cheating me watching youtube half a day?
But even if the question is not asked explicitly, does not mean nobody has doubts alike.
I worked in various environments. Let me review the most common solutions and their pros and cons.
Don't track anything!
This sounds like a programmer's paradise: one spends time to whatever is more productive at the moment. "Trust is everywhere!"
But let's look at a situation when some urgent side tasks are thrown to the engineer. Say, we had a release and discovered some small bugs after it. We need somebody to look at them and state the estimate for fixes.
Such investigation tasks may take considerable amount of time. But this is easily forgotten to be mentioned on stand-ups (or at worst cases one may be even forced not to mention them with a reason "This does not "bring any value to the current sprint", but let's leave such dullards away).
Besides, in this case you kind of "hide" from yourself and the team the real efforts spent for particular tasks. Sometimes one may spend few hours each day to investigate some naughty bug. And having spent 10 hours one creates a task for minor refactoring that would take 2 hours to be done. I think it's not fair!
Track your every billing hour
Any creative work needs a concentration and the concentration is very fragile.
During the workday anyone may be distracted by some "not-directly-my-work" questions or attend some short group sync-up meeting. Where to track that time? Should I create a ticket for every activity over 30min I had during the day? And what to do with those below 30min? Track to the current task? Why wouldn't I track some time for more-than-30-min activities to the current task too?
This may lead to some inflation of minor tasks.
This forces me to lie. And I don't want to! And I don't want to create a ticket for every activity either!
Track 5 to 8 hours makes perfect sense
This does not force an engineer to lie and gives a legal way to omit some really not important details (e.g. 10 minutes watching cat gifs after lunch).
This 30% buffer is enough to minimize controlling pressure and to concentrate on what has been really done.
A customer may ask: Why I pay for 8 hours and get only 5?
Because this is not really "hours". This is a 5-hours productive result of 8 hours workday. Which is pretty good, as for me.
Besides, those cheating with 5 hours can cheat with any amount of hours at all and without tracking too.
I believe the modern ways of management are about openness and transparency. So why not to give the customer (especially PO) an ability to track not the time but the efforts for particular tasks to identify problems earlier. Isn't it the "agile" is all about? These time records could be a good supplementary material for daily stand-ups, especially in remote teams.
Also do not forget that hours registered per day is not a real metric of performance, progress or anything alike. This is just a documented version of the stand-up meeting with some tracking capabilities.
If you're afraid this metric might be used as a punishment reason, probably better not to track anything at all.
Немає коментарів:
Дописати коментар