2 min min read - December 5, 2014
"laws were most numerous when the commonwealth was most corrupt" Tacitus
Time tracking in projects is one of most hated elements of project management. It's not without a reason. From company point of view visibility on time usage (when time and work are resources) has huge value as it eliminates unknowns. The problem is that business is not always ready to hear the answers.
In the end literal time tracking always turns out another corrupting law (as in the quote) or evidence of such corruption. I would like to present three scenarios how time tracking can (or shouldn't) be used - all founded on my experience:
Most of mature organisations I worked with never used actual time tracking. They used pointing systems from agile methodologies like Scrum, Kanban or Lean and accepted that value of points is dynamic in periods.
Agencies are very different from actual product owning companies. Agency has precise budget and doesn't own decision on shape of the product. Agencies therefore try to unify products. This way they can defend budgets in front of the client by comparing them to real cases from the past.
There is situation, when time tracking can work as a "sword with two blades". In case of working with unexperienced product owners, who extend expectations without investment in resources (time, people, culture and knowledge). Many of us know quite arrogant questions like: "why it takes so long? what have you been doing? it is so easy, why we are delayed?". First of all in many times such questions are result of giving deadlines to set (or growing in time) goals without listening to the feedback/estimation (or without using LEAN methods which exclude long term planning at all).
For both Agencies and developers who needs defence strategy I suggest using Toggl. I have no connections to their team, but I personally used it and it saved me a lot of pain. It adds value to existing task management software and doesn't require replacing them.
Have you ever asked your developers to do some project for you? You spent vast amount of time on describing your goals, making mockups, explaining needs. Then you get something that looks ok, but once you start to use it it falls apart. You click something and result is not as expected. You ask about it and you get an answer „it was not defined“ or „it conflicts with other thing“. You keep asking „why you haven’t said it back then?“. Answer is „well, we didn’t know you will go that way“ and again „you haven’t told us about it“. Constant blaming starts to make your furious, team furious and your project goes nowhere. Well. In fact I am not going to make you help any better. Your developers were likely right. Good for you, is that they are also one to blame.… read more…
3 min min read - December 16, 2014
I don't mean Anonymous as organisation or movement, but anonymous as a state. After years spent in small teams I can appreciate value of close contact with everyone in the team. Knowing each other’s weak and strong sides benefits in great dual understanding (some small teams can't achieve that, because other reasons - for instance replacing discussion with announcement).… read more…
2 min min read - December 1, 2014