Software Development & Management

Time tracking is very bad... and sometimes helpful

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:

Agile point systems

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.

  • Work that require R&D (all development require R&D, even if business say that there are no resources for it) assume unknowns. Long term estimations are known to be fault, so aren't used.
  • Any estimation is done basing only on 100% sure information. "I will spend X points on R&D, then I will tell you how much points will take to do first step. Once we have first step done and evaluated we will estimate second step".
  • Days, people, tasks, environments, challenges differ. Precise time tracking brings only unconstructive pressure - therefore is not used.

Precise focus tracking

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.

  • Time boxing for typical jobs helps to asses the budget
  • Precise time tracking allow to align the team and find fluctuations early
  • Agencies need to remember to put creative resources only to "open tap" jobs to not generate loses and not lose the best ones.

Defensive time tracking

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).

  • Teams in such case should start using simple, but precise time trackers.
  • Each distraction should be tracked: meeting, question, bug fix, release, pair programming, discussion, etc.
  • Results should be shown with repeating to the business that as long team is not bunch of co-owners giving 1000% of their own, people are being hired for X hours per week and requesting more will cost more, bring more frustration, fatigue and fails.

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.

Next article

Software Development & Management

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

Previous article


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