Inside TFS

In Search of Process Efficiency

Jeff Levinson says the first step toward being more efficient is getting on top of project time tracking.

• By Jeff Levinson
• 07/29/2010

For some reason this comes up time and time again and I don't understand why. I guess the issue is that people don't see the inefficiencies in their own processes because they work with them every day. If your process is routine, you don't think it has any aspects of it that can be improved, and so any change becomes inefficient -- an added burden that you don't have time to deal with. What am I talking about? In a nutshell, you need to ask what are the things that you probably do every day as part of your process that you do not need to do, and what can TFS do to help. Also, we'll explore why using TFS to help is not inefficient and look into some common misconceptions about TFS.

The first issue that people are likely to have with this column is the use of the term "process." Process denotes something heavy that is a burden to do. The dictionary definition of process (from dictionary.com) is "a systematic series of actions directed to some end." So, guess what? Processes are all around us -- Scrum is a process, XP is a process and so is any other development methodology. But somewhere along the line it became a bad word. As an industry we have to change that -- it's wrong. Process itself is not bad, it's the way that it is implemented that's bad.

The next item on the agenda is efficiency. The Encarta World English Dictionary defines efficiency as "the ability to do something well or achieve a desired result without wasted energy or effort." In order to know if you are efficient, you have to be able to objectively measure all of your processes to determine where the waste is. This is a core principle of Lean and every agile process there is. Everyone strives for efficiency but in looking at many companies they can't see the trees for the forest -- they focus on the big picture and miss the little things that contribute to the overall picture.

So what is one of the key areas that everyone complains about, no one does well, everyone knows isn't being done well, and yet organizational budgeting and scheduling issues are based upon? Time tracking. It's the one thing that everyone has a problem with and yet everyone has to do it in some way.

Why does this consistently come up when discussing Team Foundation Server? Many organizations explain to me that they don't really have a process for developers to report their time to project managers, so they send e-mails at the end of the week with what they worked on. Or project managers pull the developers' hours from an organizational timekeeping system. Many developers tell me that it's too hard to keep accurate track of their time. And yet these same teams also tell me they are adopting Scrum. This is not only impossible in and of itself, it is highly inefficient.

Scrum and many other agile processes require accurate time tracking. In fact, it is built into the process and that makes the process more efficient. How so? If you send in your time to the project manager by e-mail, or spreadsheet or other time tracking tool, the project manager has to gather that information for every member on the team (who may be sending it in a different way) and then manually construct reports that reflect the state of the project.

Sending the details of your time this way wastes your time too -- you have to write out what you did and how many hours you spent on it manually. Typically this is done at the end of the week when you can't remember how many hours you worked and what you were working on earlier in the week. And this then takes a huge amount of time for the project managers to put it together.

Taking an extra 15 seconds on each check-in to put the amount of time against a task increases the likelihood that the information is accurate. It also ensures that there is a built-in description of what you were working on, tracking the day that you did the work. The project manager then needs all of 15 seconds to generate a report for the whole team, a specific feature or individual team members. While this may not be 100 percent accurate, it will be a whole lot more accurate than the other way of doing things. And it will save all of that wasted time by the developers and the project managers.

There is no downside to recording time against tasks. The "extra" time you think it takes you really saves time. If you don't believe me, try it. Sit there with a stopwatch and watch a team member file their time, extrapolate that out to the rest of the team and then watch the project manager put it all together. Compare that to filling in your time in TFS. And another benefit is that many of the reports don't "light up" without the remaining and completed work being filled in (amongst other things, filling in this information allows you to improve estimates over time).

Go ahead, try it if you don't believe me.