Fear is often a software practitioner’s first reaction to a new metrics program. People are afraid the data will be used against them, that it will take too much time to collect and analyze the data, or that the team will fixate on getting the numbers right rather than on building good software. Creating a software measurement culture and overcoming such resistance will take diligent, congruent steering by managers who are committed to measurement and sensitive to these concerns.
To help your team overcome the fear, educate them about the metrics program. Tell them why measurement is important and how you intend to use the data. Make it clear that you will never use metrics data either to punish or reward individuals—and then make sure you don’t. A competent software manager does not need metrics data from individuals to distinguish the effective team contributors from those who are struggling.
Respect the privacy of the data (Grady 1992). It’s harder to abuse the data if managers don’t know who the data came from. Classify each base measure you collect into one of these three privacy levels:
Individual. Only the individual who collected the data about his own work knows it is his data, although it may be pooled with data from other individuals to provide an overall project profile.
Project Team. Data is private to the members of the project team, although it may be pooled with data from other projects to provide an overall organizational profile.
Organization. Data may be shared throughout the organization.
As an example, if you’re collecting work effort distribution data, the number of hours each individual spends working on every development or maintenance activity in a week is private to that individual. The total distribution of hours from all team members is private to the project team, and the distribution across all projects is public to everyone in the organization. View and present the data items that are private to individuals only in the aggregate or as averages over the group.