The fallacy of time tracking

I constantly see developers advocating the power of being and doing agile, how agile methodologies deliver all this benefits for the team and how our clients are going to get better value for their money, faster times to market, etc. However I am left with the feeling that it is often forgotten that we are still running a business and we have to make some profit in the process or we are all going home.

So when the opportunity to talk about these matters with people who are faced entirely with the business side of running Agile rises, I quite enjoy it. It opens a window into a way of seeing things that allows me to understand where they are coming from, what their main concerns are and what the reasoning behind their positions sometimes is. It is a fresh perspective, a new pair of eyes and I like to embrace that whenever I can.

Profitability, ROI, budgeting and agile contracts are recurrent subjects that worry people from the business end of the agile equation and that are not all that well explained by most advocates.Maybe it is because of where they come from, their lack of experience in the subjects, or simply they think it does not affect them. Buy just like a rowing eights team, for an agile organization to function at its best, everyone has to be on the same boat and rowing in synchrony to achieve their goal.

 

That is all good. But why is this post titled “The fallacy of time tracking”?

A few days ago a friend of mine who is a P.O. was looking for some way how to calculate the profitability/ROI of his team and the projects they are working on and this is where the idea for this post came to be. 

Let there be time tracking

If you worked at one of the old-school big companies here in Spain, or come from an MBA you are probably thinking... What's so hard about it?

Just ask the team to start writing down on an excel spreadsheet or the back of the cards the amount of time they took to complete the task and the role of the person. Then your friend can later look at it, crunch the numbers and have the metrics he wants. I mean, it is not rocket science. We have been doing it like this for who knows how long now! And that’s exactly what my friend’s first reaction was!

Who hasn't had to fill in the excel spreadsheet, maybe even something fancier: a Visual Basic application, or that web page in the corporate site... Hell, I even had to create one of those :)

It sounds like a great idea! However, as popular as per task consumed time is... Tracking time spent on a task is a flawed and most of the times harmful way of measuring the profitability of a project or team.

Here are some of the reasons why, in my opinion, this is so.

Time tracking is inherently imprecise.
Forget about the precision. If you think you are doing this because you will get a precise result, abandon all hope and go cry in a corner, because you will not get it. It is extremely complex, if not impossible to track exactly how much time one spends doing something.

We humans are really bad at tracking time. What may seem minutes could really be hours if you are in a state of flow and minutes can seem like hours when you are not engaged in the task at hand or under stress. Add to this: interruptions, context changes, etc... All this little things that we should be keeping track of that per se may not seem like much, but that definitely adds up to time.

Yes. There are tools that track time, like stopwatches, mobile phones, time tracking apps. And yes, they help. Maybe they can track how long you have been using a certain application, of if there is mouse movement, etc. Sadly they are not quite there yet when it comes to mind reading or detecting if the user left.

Then there is matter of the “per role price”. The fact that usually different roles are most of the time “priced” at different levels and the reality that often the same person is undertaking more than one role, makes the task of tracking real cost per hour even more difficult since sometimes you are working as a developer, other you are “the architect”, or a tester, etc. This makes it not only about the time you work, but also what kind of tasks you are performing, since for your company it is not the same from a costs perspective.

Time tracking is most of the time just done wrong.
People forget. We forget what we did. We forget to write it down. We forget to start the timer. We get interrupted and spend time in things that are not part of any particular project. Things like answering a question from a coworker, the meeting we got called without being notified, chilling out on Facebook, or drinking coffee, etc.

Of course from a business perspective we are expected to work a certain amount of hours each day, and if it's not in the time sheet report, it doesn't exist. So, what usually happens is that this time, goes in the report under whichever project we are supposed to be working on, or under the project that is doing the best so far.

This is curious effect. It seems that just by existing, this report acts like a pressure point. Is it forcing the guy filling in the hours to “lie” about what he is doing? Well, you may argue that’s nonsense because no one is actually forcing him. But social arrangements that produce responsibility are arrangements that create coercion, of some sort.

What about crunch time? Does it go in the report too? Does it cost the same as regular hours?

Time tracking can be manipulated and corrupted.
I have often seen people manipulate the reports by compensating from other tasks or other projects in order for everything to look neat. They report perfect estimations and perfect execution. Of course, not just because it looks nice, but also because of the bonuses they will be getting for not having any schedule deviations.

These kinds of associations are what makes time tracking the preferred tool used to sharpen the stick or sweetening the carrot at the risk of killing intrinsic motivation and undermining the corporate culture. They create politics at the workplace and in my opinion these politics are waste of energy and time that gets in the way of actually performing.

Time tracking is not a core business activity and it is extremely time consuming.
Let me ask you a question. Have you seen anyone who thinks that tracking where his time gets spent is what he gets paid for? Unless you work at RescueTime.com or some other company that creates time tracking software, this doesn’t hold true for you.

Even better, have you seen one of these spreadsheets with a special project that says: "put here the time you waste filling in the time you spent doing real work"? Yet it should be there right?

Sadly this is time you end up charging your customers for and that you could have spent delivering value. It is hard to believe any customer would be willing to pay for it, if they knew the truth.

Time tracking is a lagging indicator.
There are leading indicators and lagging indicators. The firsts provide you with information before the particular change you are after actually happens. I in a way they tell you about the future.

On the other hand, lagging indicators provide you the information only after the fact. Time consumed per task belongs to this category. On its own it doesn't reflect the "potential" project deviation until it has already happened.

When I think of this I am always reminded of the Windows progress bar.

Everything would be going smoothly while copying a file until it got to around 99% and then the bar would simply stop moving. Parked at that last 1% for orders of magnitude more than what it had taken to get to the other 99%.

That's what happens to projects and tasks tracking over and over when focusing on the time spent. Instead of: “How much time have you taken already in this task?” a more helpful question to ask would be: “How long do you think it will still take you to complete it?”

Why do we drink the poison then?
Everyone is fixated with using hours gathered at the individual task level to know the profitability of the projects. I wonder if this is a reminiscence of the use and abuse of Gantt charts and project planning tools.

Why are we so prompt to attempt going down this “time tracking” path?

Sometimes I have heard people say: Well, we need to know because we charge by the hour, right? To which my answer usually is: Not really. No.

The notion that you charge by the hours someone is ___insert favorite software-development-related activity here___ is at best naïve. Unless you don't really care about your customers, or running a successful business, you are not supposed to be charging by the hour.

You should be charging (and you probably are) by the customer's perceived value. In other words, you charge by how much value your client sees that you are offering him with your product or service. From this point of view, your per hour cost will only be the lower bound to your final price. Often people construct their prices from this lower bound, sometimes, so that they can completely ignore it... *sigh*

There is another common response that comes up and it is this: Our people need to be supervised and time sheets are the way we do that.

If you treat people like children, they will behave like children. In my experience if someone is not performing as expected in a mature team doing agile, it will be spotted right away by the rest of the team and dealt with accordingly. I would go as far as to say that, if your team needs someone breathing on the back of their neck in order to perform, you have bigger problems to attend to.

It is not all bad… Well yes, but not always.
There are places where the benefits of time tracking overcome the disadvantages. For sure in some cases you can have some degree of time tracking without it being prejudicial. Don’t get me wrong. I’m not against tracking time or any other metric as long as it fulfills a couple of requirements I find indispensable.

• Recording the metric should not impact the team in a noticeable way.
• The metric in its self doesn’t get perverted. Carrots and sticks anyone?
• It’s not a vanity metric.

Is there another way?
The starting point to overcome this fixation and avoid most problems derived from it I think is to instead of starting with a metric and work our way backwards, ask ourselves what is the real motivation behind the particular metric we want. Only then we can choose the right things to measure and when to measure them. It may as well be that we already have the tools needed to calculate what we need.

Do we want to know the project's profitability? Why? Or is it the overall team profitability that we are interested in? Is it because we want to know if the project will stop being profitable and if so, when is it going to happen? Or on the other hand we are trying to figure out what the base cost for this project is in order to provide a budget?

Each of these questions is in its own is a subject worth exploring in future posts and I hope to not only approach the metrics and calculations of some of these KPI in an agile environment and how to use them best for portfolio management, but also, and more importantly, the motivations behind them. 

If possible maybe raise some questions that I feel are fundamental and get you thinking. Until then, see you soon!