Evaluating People, why can’t I use all that data

This subject comes up repeatedly. We address this in the TSP management training, but because organizations are fluid we frequently must explain the perils to someone encountering this gold mine of information for the first time.

A simple and short answer is that the data is recorded by individuals. Developers are smart enough to know what you are looking for, and give it to you. If they believe the data will be used to evaluate them, they will try to look good. This usually means that the data is no longer fully true, but “fudged”.

If you really want task hours, that’s easy. Leave the clock running.

What about lines of code per hour? There are countless ways of manipulating the line count, for example use “cut-and-paste”.

Almost any measure can be manipulated in one way or the other. The problem is, if the data is not fully true, it no longer can be used for planning or improvement. So what can we do? Go back to that focus on planning and improvement!

Teams and individuals are provided goals and objectives. They will make team and individual goals to support the project goals. It takes some, though not much, effort to collect data. It takes some more effort and discipline to learn from the data to make plans and improve one’s personal process. The results should be better outcomes.

The detailed data in logs can be very revealing and very personal. Other data, such as when a product completed and how many defects were found in final test, however, are public. Separate the private and public data. Make this policy clear.

“Your personal loc rate is for your planning. I don’t so much care what it is as I want it to be accurate and consistent so you can tell me whether or not you can finish this work in the time I’ve asked.”

“I know you inject defects, I don’t care how many, just that your defects don’t show up in system test or production.”

Let’s also remember that software is not an individual game, it’s a team sport. That senior developer might get more task hours huddled in a closet, yet could make the entire team more productive by mentoring or answering questions. Everyone should be assuming team roles, speaking up when they are behind and assisting teammates when they are ahead.

The possibilities are too broad to cover in a short post, but organizations can get enormous leverage by providing a supportive environment and evaluating on a coherent set of behaviors and outcomes. Let the person closest to the work worry about the details in the workbook. Management needs to look out for the big picture objectives.

Advertisements

About Bill Nichols

PhD in Physics from Carnegie Mellon University I'm a software team coach and instructor with the TSP Team at the Software Engineering Institute
This entry was posted in Performance Management, Personal Data. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s