Selecting the right measures and determining the correct data to collect is critical. It is best to start slowly, gauge results, and build on success. Metrics are an incredibly important part of any continuous improvement environment. Teams want to know how they are doing and will be motivated to improve with practical, unambiguous data. Keep in mind, most suggestions on areas to improve, strategies to drive these improvement, and the efforts’ prioritization will come from the team.
This is not solely a management exercise; it is critical to involve teams in the process. In fact, the best results are those that come from the measurements that the teams feel are the most valuable. After all, they are responsible for delivering on their commitments, and therefore, have a vested interest in ensuring they have visibility into their project work.
One common management precept teaches that, “you can’t manage what you don't measure”. This is as true for individual teams as it is for the managers responsible for those teams. In an agile environment, this ideal means that scrum teams must take responsibility for the metrics they use to guide their work. Teams will not know how to gauge progress unless a baseline is established on agreed upon measures.
The dynamics of software development are familiar to every technology team. The viewpoints, ideas and rules of thumb that go along with the more formally defined policies, procedures and methodologies can sometimes be at odds with each other. Teams and their managers must be adaptable to integrating the culture of the team, while still constraining the risks, dependencies and natural uncertainties in delivering software. This process allows the people doing the work to have voice in the overarching team approach. Finding a common balance tends to produce the best combination of team input with the expected team outputs.
Metrics are equally important to the key constituencies of teams, their members and stakeholders. If measures are published simply to comply with a management edict, they will not be as valuable as a tool to drive excellence. Metrics need to become a part of the everyday culture.
No one should deluded into believing that building a metrics program is an easy undertaking. Such an effort involves changing a team’s mindset, culture and actions. Teams that are not use to metrics must alter their work habits, collect data, and publish a consistent set of metrics that are visible to the team, stakeholders, and the organization.
It is important to note that metrics are not a substitute for clear communication, focused objectives, sound decision making, common sense thinking, and realistic schedules. Regardless, implementing a dashboard is a proven way to bring visibility to all aspects of the development, deployment and production environments. Remember, what you don’t know CAN hurt you.
There is no single best set of measures. Creating a metrics framework and dashboard involves choosing measures that are oriented to meeting the needs of a given technical group. Since organizations are comprised of teams doing different types of work, teams may have a set of metrics that include both organizational wide metrics, along with team specific ones.
Many teams guide their work based on an existing published dashboard. In this case, the idea is to continually review and consider alternative measures to enhance or supplement the value of metrics already in place. Teams and project work are not static, and the same is true of the metrics employed.
