Despite the challenges, many software organizations routinely measure aspects of their work. If you wish to join this club, keep the following tips in mind.
Start Small. Because developing your measurement culture and infrastructure will take time, use GQM to first select a basic set of initial metrics. Once your team becomes used to the idea of measurement and you have established momentum, you can introduce new metrics that will give you the additional information you need to manage your projects and organization effectively.
A risk with any metrics activity is dysfunctional measurement, in which participants alter their behavior to optimize something that isbeing measured, rather than focusing on the real organizational goal. For example, if you are measuring productivity but not quality, expect some developers to change their coding style to expand the volume of material they produce, or to code quickly without regard for bugs. I can write code very fast if it doesn’t actually have to run correctly. The balanced set of measurements helps prevent dysfunctional behavior by monitoring the group’s performance in several complementary aspects of their work that lead toproject success. Never attempt to use metrics to motivate performance.
Explain Why. Be prepared to explain to a skeptical team why you wish to measure the items you choose. They have the right tounderstand your motivations and why you think the data will be valuable. Use the data that is collected, rather than letting it rot in the dark recesses of a write-only database.
Share the Data. Your team will be more motivated to participate in measurement activities if you inform them about how you’ve used the data. Share summaries and trends with the team at regular intervals and get them to help you understand what the data is tellingyou. Let them know whenever you’ve been able to use their data to answer a question, make a prediction, or assist your management efforts.
Define Data Items and Procedures. It is more difficult and time-consuming to precisely define the data items and metrics than youmight think. However, if you don’t pin these definitions down, participants may interpret and apply them in different ways. Define whatyou mean by a "line of code," spell out which activities go into the various work effort categories, and agree on what a "defect" is. Write clear, succinct procedures for collecting and reporting the measures you select.
Understand Trends. Trends in the data over time are more significant than individual data points. Some trends may be subject tomultiple interpretations. Did the number of defects per function point found during system testing decrease because the latest round of testing was ineffective, or did fewer defects slip past development into the testing process? Make sure you understand what the data istelling you, but don’t rationalize your observations away.
Measurement alone will not improve your software performance, but it provides information that will help you focus and evaluate your software process improvement efforts. Link your measurement program to your organizational goals and process improvement program. Use the process improvement initiative to choose improvements, use the metrics program to track progress toward your improvement goals, and use your recognition program to motivate and reward desired behaviors.
