Measuring Development Time: Not the Best Way to Spend Your Time
Managers and project managers are often obsessed with time. Time is useful to consider, but measuring time doesn’t always give us the information we really want or need. For example, Johanna Rothman tells us that you can’t measure work by time. By focusing on time, rather than results, you may not get the results you want.
Part of the reason people like to focus on time may be that we often confuse time spent with “effort” or “work.” While it is true that work takes time, more time beyond a threshold can be counterproductive. Rather than measuring time as a proxy for effort, you may be better off trying to make the most of the productive time you and your team members have. Johanna Rothman advises keeping an eye on email and meeting times to improve the effectiveness of the time that people can be productive. And remember, the number of productive hours in a work day can often be less than eight.
Time, while easy to measure, doesn’t tell you a whole lot about the value of your team's work. Jason Fried claims that one way to be more productive and to work with higher quality might be a shorter, thirty-two-hour-work week.
These variations in a standard work routine might be especially tricky in organizations that trade in billable hours. Robert Pozen suggests that a billable hour model is flawed and that we measure results not hours. By doing this, he suggests focusing on improving efficiency; aiming for, among other things, fewer (and shorter) meetings; and frequently reprioritizing the work you need to do.
In short, rather than measuring time, figure out how to get the important things done in a reasonable time interval. All of which resonates with the themes of agile software development, especially the focus on delivering value.
A side effect of focusing more on results—and less on time—is that we can be more energized by spending our time on the right things, so there is a synergy between efficiency and energy.
Time measurement is deeply ingrained in our business culture. The problem with using this model without thought is that you often get what you measure—be it lines of code or hours of effort. Rather than running your project by habit and focusing your measurement efforts on time, try changing your mind. Think about what you want to measure, and use time only as one input into your process of understanding how to work more effectively.
On your projects, how closely is time, rather than delivered value, measured? Do you have a good way to measure the delivered value other than time? What things do you do to make better use of your time at work?