Time tracking has been a point of contention between developers and managers for as long as I’ve been working in the web design and development industry. That’s sixteen years. I’ve been on both sides of the issue working as both a web developer and as a manager. Tracking your time as a web developer is an essential practice for any small business practicing agile development. And I’ve got some pretty good reasons to back it up.
In this post…
Timesheets have historically been the bane of developers. Let’s take a look at Jeff Sutherlands rant on the lameness of timesheets to see why:
Actually time sheets are worse than lame:
- they demotivate developers
- 10-15% loss of productivity is the minimum
- developers have to fake the time to fill them out properly
- erroneous data is used for reporting and management makes bad decisions
- customers are deceived
- they have nothing to do with quality code production
- they focus the whole organization on phony data instead of production
Nevertheless, this is not enough for many managers to give up time sheets. Just like the waterfall process, there is a psychological dependency so strong, it is as if they are on drugs.
I’m guessing that this rant comes on the heels of larger companies trying to enforce a time tracking policy onto an agile development team without fully understanding the agile workflow. A small business, however, definitely needs to incorporate time tracking if they are going to empower developers to manage themselves. Time tracking is also essential for a small business who wants to know where their most precious commodity, time, is being spent.
Pelago would be the first to admit that the waterfall method does not work in the web-based software development industry. We just so happen to be a web design and development agency that practices agile development and uses timesheets. We’ve encountered several reasons why managers of smaller development teams should not give up timesheets — reasons based on real-life experiences running an agile software development business.
It’s not all about the developer
The points made by Jeff feed directly into the ego of the developer. First of all, developers should not be faking time. They should learn how to track their time accurately. It’s not that hard to do and we’ve worked with many developers over the years who have found it quite easy to track time once they make it a priority. When running a small business, you are accountable to more people than just your developers. If the developers are too demotivated by the process or can’t find the time to track their time, find new developers. The other points about erroneous data, deceiving customers and focusing on phony data all stem from the assumption that a developer can’t track their time accurately. Developers may be a stubborn bunch, but they are perfectly capable of accurately tracking their time. Besides, there are so many great agile time tracking apps available online that make time tracking really easy. There really isn’t any good excuse for developers not to track their time.
It’s not all about the code
It’s true that time tracking takes time, but a 10-15% loss of productivity seems exaggerated. All that we ask of our developers is that they start a timer at the beginning of each task and stop the timer when the task is completed. They can apply the timers to their timesheet at their convenience. At our web design and development agency, Pelago, our billable hours increased by 30% when we introduced time tracking. That increase covers whatever minimal loss of productivity we may have introduced when we started requiring developers to track their time. The only realistic point made above is that time tracking has nothing to do with quality code production. This is true that there is no direct correlation between time tracking and code quality. But that’s not why we track our time.
We track our time because we have a business to run.
Better planning through time tracking
When it comes to running a small software development business, planning is everything. You’ve got to plan your sprints and your project deliverables. Once you’ve started tracking developer time it is quite easy to pull up historical data for planning out future sprints and projects. If you know how long a developer will require to get through his list of three pointers you can plan more accurate sprints that won’t burn out your developers. Developers may think it will take then a given number of hours to complete a task, but our time tracking data has shown that you have to double the developer’s estimate for a more accurate idea of how much time a task will require. In other words, doing task and project management with time tracking gives you a more accurate picture of how efficiently your team will perform a set of tasks.
Accountability
A small business practicing agile development is accountable to more than just its developers. You have managers, owners, and in the case of startups, shareholders; all of whom have expectations. The software development process, in the context of a small business, encompasses so much more than just the finished product. Managers will want to know how much time certain features required so they can report back to other managers, owners, and shareholders. They will want to know which features inundated the development team and which features were developed without a hitch. Why? Because if a project is behind schedule it helps to have a good reason for it. Or, if a feature needs to be added to your product, good historical time tracking data will give you a good idea how long the development will take.
In addition, developers have expectations of one another. Some developers may be working their asses off while others are hitting up the ping-pong table every hour. If developers are tracking their time, you are one report away from knowing who is doing their job and who isn’t. Disparity in effort among developers may not have any effect on the quality of code, but it will kill morale and may ultimately take the product down with it.
Accurate Flat Bids
Just because agile development makes us faster at web development doesn’t mean we are immune to inaccurate estimates and scope creep. Having estimated over 300 projects in the last 10 years, we strongly believe in the predict, track and learn cycle of estimating projects. We’ve honed down our estimating skills to the point we can estimate a project to within 10% of it’s final outcome. We could not have done this if we did not track our time. The win-some-lose-some mentality behind flat bidding is not a very sound business practice. It leaves you open to underestimating projects and scope creep. Disciplining developers to track their time gives your business a much higher probability of accurately estimating future projects and takes the guess work out of flat bidding.
Billing Hourly
In our case, we are a web development agency that does agile development and bills clients at an hourly rate. We gave up on flat bidding long ago because they required too much work up front; defining a bulletproof scope when neither the client nor ourselves had a clear picture of what the finished product looked like. Billing hourly allows us to quickly develop a web application that will inevitably change as the client watches it come to life. Changes in scope are easily tracked and billed without interrupting the agile development process.
Short-term gain, long-term loss
Lightning McQueen learned this lesson the hard way. He was all gas-n-go’s and was positioned to win the Piston Cup when his two back tires blew out. He didn’t win the race. If an agile software development business decides not to track their time, they will likely not suffer any consequences in the short-term. However, they will experience long-term repercussions as a result of their decision. Developers will burn out while cramming to complete poorly planned sprints, managers will struggle to quantify why a given feature is taking longer than it should, and shareholders will start making uncomfortable inquiries. Had a time tracking system been in place, many of these problems go away.
The discipline of accurate time tracking is getting more and more simple to accomplish with the advent of so many great online time tracking apps. Intervals, for example, will let you toggle timers on and off whenever you start or stop a task. You don’t have to recollect your workday at 5pm because the app has already done it for you. It also seems that other online agile project management tools are beginning to come around and add time tracking as a feature.
Feel free to contribute to this conversation. Meanwhile, there are some additional conversations on this subject over at StackOverflow.com:
it’s funny you don’t mention one argument why timetracking is essential for agile development. You’re laying out why it’s important for your company in regards to work as a software development service company. I would really like to know how you integrate the time tracking in your daily agile developement process? Not only tracking the time but also using the data. If it’s just about the billing this has nothing to do with the agile process in special.
Can you provide more insight e.g.:
+ How granular do you track and how did you come up with the clusters you book your time on?
+ How do you use the data in your process other than billing the hours to your client?
From the article:
If you have data from previous sprints than you can more accurately plan upcoming sprints. Developers don’t want to be stuck trying to hammer out the remainder of their tasks on the last day of the sprint just because the sprint was planned poorly.
I’m curious how, if at all would your processes change if you were the owner of a small biz that utilized contract developers to both build and maintain a complex web application. I’ve struggled keeping communication flowing between my “lead” developer and short term developers. I’ve also felt at the mercy of the lead developer’s priorities. He’s a code monkey for a week or so, then other times it’s like pulling teeth to get anything done. Granted, he also wears the sys admin & 2nd level help desk hats. However, it always seems like the helpdesk & sys admin tasks “magically” multiply whenever I’ve pushed for more development to get completed. I’d appreciate your ideas. I’ve tried about everything I can think of to motiviate and keep projects moving forward.
We’ve been there. Plenty of times. We call our code monkeys “mudders,” because they are like racehorses that run well on a muddy racetrack. And we’re familiar with the vanishing developer. Ultimately we solved the problem by always having our lead developer in house as a full time employee. We’ve learned the hard way that building and maintaining complex web applications with contract developers doesn’t work. There a million things that can and will go wrong with the process. As long as you have one full time developer you have someone to bring in at those critical moments when the web app goes down and the client is breathing down your neck.
If you are set on using contract developers the only advice I can give is to create enough lead time to accommodate communicating with the developers and allowing them room to get everything done. It’s not the most efficient way, but is probably the only option, short of hiring them on full time.