Talk About Quality

Tom Harris

Archive for August 2006

Monitoring for Encouragement

with one comment

When you deploy a new process, one question that comes up is, “Will it last?” And the usual solution is monitoring — recordkeeping and reporting to track how it’s going. But do we really want to check up on everyone to make sure it’s really happening, and going smoothly, and producing results? Or better to just let people alone so they don’t feel that somebody’s watching them?

The concern stems from people’s thinking of monitoring as a negative thing. If monitoring shows problems, will their managers criticize them? If monitoring shows fewer results than expected, will people think the process isn’t working?

But monitoring can be a positive tool if used correctly. Promise yourselves that:

  • If monitoring shows the new activity not happening enough, managers will take that as a signal to ask their people what they need help with. A manager’s job is to provide what his people need to do their jobs — perhaps something needed to make it happen is missing. Ask and find out.
  • If monitoring shows the activity not producing enough results, wait! Focus first on the results that are there. Seek out the people and groups that produced them, and compliment them. When people are encouraged and rewarded (even just with positive attention), they’ll do more, as well as feel more comfortable asking for help if they need it.

While we’re at it, monitoring does not have to be complicated. Here’s an example, in this case, for code reviews. Something everyone believes in, but can be hard to keep going.

Make yourself a spreadsheet with just four columns: Scope of Planned Review, Planned Review Date, Did it Happen? and Number of Issues Found.

For the first good while, all you have to do is make a check mark for each planned code review that actually happened, and find out how many issues were found. Yes, there’s a lot more to code review than these two basic measurements. But as a tool for help and encouragement, they’re all you need.


Written by Tom Harris

August 30, 2006 at 10:18 pm

Posted in Agile, Code Review, Metrics

Are Reviews My Work?

with 2 comments

Want quality improvement, professionalism, and mentoring? Just deploy this short list of responsibilities for each and every person in your company:

  • Do your assigned job correctly
  • Regularly take a step back and find ways to improve how you do your job
  • Demonstrate these improvements to those around you

What’s missing, though?

These guidelines don’t tell you where reviews fit in. Specifically, when somebody, who is doing his job correctly and trying to improve how he does it, comes and asks you for your review and comment on some work product.

We know that reviews can catch defects at 1/10th the cost for each stage earlier we do them. Going further, reviews can be a mentoring platform, and teach extremely effectively, because they are based on people’s current, real work.

Still, many of us react to such a review request, at best, by agreeing to do it, maybe even doing it on time, but all the while feeling, “I’m helping someone else, but I’m taking time away from my own work.”

So that’s the question: is there a fourth item on the list:

  • Review others’ work when they ask your help

I think there can be, but only if management, in its leadership role, declares that reviewing others’ work is part of each person’s job. And in its management role, rewards time spent on reviewing equally with time spent on the assigned job.

Getting the benefits of any kind of review — code review, design review, or others — depends on it.

Written by Tom Harris

August 29, 2006 at 11:32 pm

Posted in Agile, Code Review