If you are a consultant, even on an Agile team, you probably have to track your hours. I used to hate tracking my hours – and I’ve seen first hand how it can demoralize people. I once worked at a company where they decided to build an internal tracking system for us to put our daily hours into. The developer assigned to the project had to do the work in secret, and no one really knew about it until the project was done. It was one of the few databases that developers had no access to.
You can imagine the message that conveyed to the programming staff, and how it demoralized all of us. A couple years later I was a fledgling project manager at the same company (in addition to still writing code), and so I suddenly had access to see what people put in the comments section. It was pretty funny seeing how much people hated putting in their time. Developers assumed no one was reading their comments so sometimes they would put in “easter eggs” to see if anyone was actually reading them. One developer tracked time spent during his bathroom visits.
In fact, I myself had played similar games with time tracker. I once wrote an elaborate diary entry, based on the lyrics to a Moody Blues song called “Dear Diary.” My manager didn’t know the Moody Blues, and so she had no idea what I was writing about it, other than it was clearly mocking the system. Apparently my long entry skewed the formatting of their report, and she let me know that they do in fact read the comments. That made me laugh, but I don’t think it made me feel any better about Big Brother watching me at work.
After I left that company and became a consultant for the first time, I was okay with recording my hours. Since I was billing clients hourly, I pretty much had to get comfortable with it. Consultants get used to this, but internal employees who are full-time will still often get defensive about being tracked, and I think rightly so.
Agile methods encourage us not to micromanage our teams, and mandate that we judge a team by success of sprints and delivery of value, not hours spent at the office.
But if your team is billing hourly towards a fixed budget, then you will have to track the hours of your developers, even if that doesn’t feel very agile. It’s unfortunately a reality of hourly rate based consulting projects.
Here are some important Do’s and Don’ts to keep in mind:
DON’T let a budgeting reality demotivate your team, and make sure you don’t use this as an excuse to slip back into Command & Control micromanaging of your team.
DON’T put the hours billed per developer on the burndown, or within the task listing on your Scrum spreadsheet.
DO maintain the separation between a budget burndown and the team’s estimates of the time left to complete each task. One of the motivational values of Scrum is the forward looking nature: Each day the developers will re-estimate how much time is left on their tasks and update the task so that a burndown can be constructed. They should not be also tracking the time they spent so far on that task, because this is an invitation to micro-manage and have morale-killing conversations like “Why did you say this task would take 8 hours when in reality you have spent 12 hours on it?”
DO still trust your individual team members (or get them off your team!). And so when tracking the budget burn, don’t break it out by individual team member or by tasks they were working on. Simply show how much you have spent already as a team, and compare that to the budget left.
Ideally you will build a relationship with your managers or clients where they will simply trust you to spend an appropriate amount of time, and they won’t micro manage your hours. However, if you are in a situation where tracking hours is necessary, be careful not to let it become a poison pill to the morale of your Agile team.
