How can I encourage my coworkers to track the time they spend resolving issues and implementing features? We have software to do this, but they just don't enter the numbers.
I want the team to get better at providing project estimates by comparing our past estimates to actual time spent. I suspect that my coworkers don't see the personal benefit, since they're not often involved in project scheduling.
I suspect that my coworkers don't see the personal benefit, since they're not often involved in project scheduling.
That's fixable.
Make them involved in scheduling.
Joel Spolsky wrote an article on Evidence Based Scheduling that may help you find some arguments.
You have to convince your co-workers that better estimation skills can help them produce better software. Here are some points in favor of tracking task time:
You can accomplish this in the standard way - carrots and sticks.
The carrot(s) in this case could be "improved future estimation by understanding our current velocity" - but you would have to follow through.
Your comment that they are not often involved in project scheduling may make this a tough sell.
The most high-functioning among them, particularly if you have any followers of PSP, is that you are helping them get better.
The most common stick (to beat them with, not to hold the carrot in front of them) is "it is mandatory, do it". While not much of a motivator; at least the position is clear.
Lastly, is the software you are using contributing to their reticence? Is it clunky? Do they have to look up time-codes in System A, before then put their time in System B? Is it too granular, does it not allow for "off" time and demand an accounting of 8 hours per day. Make it as friction-free as possible to also help adoption.
Good Luck
In my experience, the following are the problems with most time tracking software:
I've addressed many of those issues by starting to use the pomodoro technique for myself. If I work 25 minutes uninterrupted on a task, it gets recorded right then, and my estimates are done in terms of those uninterrupted intervals. I'm still working on incorporating evidence based scheduling to communicate the uncertainty, and on translating my own fine-grained tracking into the coarse schedule estimates that PMs like, but it's definitely been an improvement so far.
Good way
Use software, which actually makes that easy and almost transparent, like for example Mylyn. Combine it with tools like for example an hour burn-down chart.
Bad way
Force them to fill in tedious timesheets, where you have to manually specify project, task, exact dates and times etc.
If you're not the team lead/PM then you're going to struggle with this one. People don't like to listen to their peers if it requires them to have to do more work than absolutely necessary (in my experience that's the case, anyways). Try taking it up with your team leader or PM, and if they agree with your case they can probably just make time logging mandatory (that's what's happened where I currently work).
If you're the team lead/PM you need to be more forceful in your role: these people are there to do what you tell them (effectively), and if you need more information to do your job you should get them to provide that information. If they're not willing to help you get the information it's probably because they don't understand why it's useful, try having a talk with them to explain how your projects often go off schedule/get over-estimated/whatever and why it's causing you problems, see if you can turn them around!
Track your time or don't get paid. Millions of people do it (consultants, lawyers, etc.), why can't they?
Some might think this is rather draconian, but it's not. If you work at Starbucks, you have to clean the bathroom. If you work at a bank, you wear a suit and tie to work every single day, and if you're a software engineer on a team that needs you to track your time, you do it!
Sometimes we have to do things at our jobs we don't like. We're all big boys and girls, I think we should be able to handle it.
Obviously the best answer depends entirely on the psychological blend of your team. Are they competitive? Design a recurring contest that rewards the winner for entering their time into the system. Adjust and tune the contest so that the players think it's fair and fun. Make it a game.
Perhaps they're concerned that if there was transparency into how much time they actually spent performing a task, there would be negative consequences. I've always wondered about designing an "effort tracking tool" that was anonymous and where buckets were sufficiently high-level enough that there would be multiple individuals pouring effort-spent amounts into each bucket that individual contributors couldn't be singled out. Even just getting more accurate effort costs for high-level project buckets might be useful data for project planning and overall team velocity, but this would avoid the "OMG, I can't believe Joe took 3x his estimate to do something so simple ..." or whatnot that people are afraid to report in a traditional time-tracking system.
I guess these are just two examples, but really, having a good grasp of the psychological make-up of your team will give you the right answer for how to incentivize or otherwise encourage them to contribute their effort cost information.
Think about why it might be that they don't respond well to this request. Don't just assume that they're lazy or avoiding effort.
Developers who avoid producing evidence are usually
This is why points-based estimation and shirt-sizing has taken off in recent years. It takes into account the very uncertain nature of the process of estimation and allows for "magic" (aka, averaging out of the uncertainties) to take control of scheduling.
And, while it may not seem logical, it does mostly work - at least as well as an hour- or day-based system. It is also very difficult to batter a team or individual around the head with what they've achieved in a month if it's done in an arbitrary way.
Scrum also allows developers control over the velocity, which means that they are making a promise to achieve whatever you choose from A, B and C or A, Y and Z. When they've made that promise, developers do not like to fail; but if you make that promise for them, they won't care. It's your fault if it's wrong.
I understand that you're saying you wouldn't use the reestimations in that way, but how sure are the individuals on your team of that?
Any tool that requires programmers to devote even more time away from programming isn't necessarily a great thing. Programmers already have plenty of overhead, they aren't having 5 minute meetings and then coding up a storm.
If you have the power, you can force them to do it. But by far the best solution is to build a seamless tool that makes it painless. I can't tell you how to do it for design, but for coding, you want to log changes made in the development environment. This used to be an impossibly high bar, but if you are using something like Eclipse, it's not that bad, maybe it already exists. This way, you can measure how much time is going into each file, and potentially in Java, each method. That's much finer-grained information than you get by asking them to bill out, and it can be pretty accurate.
Similarly, if you have a tool for entering designs, you can intercept there.
Depends on how and why you want them to track time, also are we just counting the time at the office or the time spent on the commute to work thinking about the problem as well?
Project scheduling is difficult and there is a good chance the metrics you get will not be as useful as you might think they would be. No two problems are the same so one task may take eight hours while another may take 32 hours to finish.
You might want to look into evidenced based scheduling as it has the developer estimate how long a task will take and then adjusts over time based upon how good their estimates are; however, it is not as good for large projects since you may not know all of the tasks up front. For large projects you might be better off looking at past projects of similar scope and using them as a yardstick as opposed to trying to aggregate individual estimates.
Try introducing them to personal organization systems like Pomodoro technique for example (there are many others but that's the one I'm trying now)
The technique uses a timer to break down periods of work into 25-minute intervals called 'Pomodori' (from the Italian word for 'tomatoes') separated by short breaks. Closely related to concepts such as timeboxing and iterative and incremental development used in software design, the method has been adopted in pair programming contexts. The method is based on the idea that frequent breaks can improve mental agility..
Instead of convincing them to enter their numbers, use a software that works effortlessly. I'm using ScreenAware: https://www.screenaware.com/en/ It tracks your time automatically and assigns it to the respective projects. So it's always accurate and no one has to guess anymore
Have you considered using your existing ticket system instead? Our ticket system monitors the time between the creation of a ticket and when it is closed. If you create tickets for tasks and make a ticket number a requirement for committing code, you're getting more bang for your buck.
