SUBSCRIBE NOW!

Vol. 41 No. 4 — May 2024

NOTES ON DIGITAL TRANSFORMATION

“If you can’t measure it, you can’t manage it” is a famous saying that’s been quoted and debated for decades. Some leaders swear by it. On the one hand, the need to measure progress is essential in order to prioritize work effectively. People tend to behave differently when they are observed, in comparison to when they are not, which is a concept called the Hawthorne effect. Measuring progress shines light on what is going well and what can be done better, enabling the team to work more effectively. On the other hand, an excessive focus on numbers can lead to micromanagement and poor team morale. Once a metric becomes a target, it can be manipulated and misused. For example, if software development is measured by the number of lines of code, developers may be unintentionally encouraged to produce bloated code that doesn’t provide any real business value. While the target for the lines of code may be met, the code quality doesn’t improve. This is known as Goodhart’s law.

THE WHY OF METRICS

Setting up and reporting metrics in a positive way that helps the team to succeed requires skill and practice. An important first step in implementing metrics is to clarify what they will be used for. Metrics help the team and the organization to do the following:

• Measure success
• Identify bottlenecks
• Improve workflow
• Improve quality and user experience

Metrics are not used to:

• Keep everyone busy
• Control or micromanage
• Manage individual performance

TEAM METRICS

At a team level, qualitative metrics tend to work well. If the team has a good rapport when getting together and can reflect in an honest and transparent manner—for example, during sprint retrospectives—then enough useful insights and actions should emerge for the team to stay on track and keep improving. Patterns and trends are easy to see, because the team is close enough to the details of what is happening. The following are some common themes to reflect on at sprint retrospectives:

• Are sprint goals met?
• Are requirements clear for the future work in the backlog?
• What are the team’s three main impediments?
• Are roles and responsibilities of each team member well-understood?
• Is the team able to collaborate effectively and give constructive feedback to each other?

A team survey—highlighting common areas of concern about goals, processes, and roles—can also be useful in addition to sprint retrospectives. See my column in the April 2024 issue of Information Today for a deep dive into sprint retrospectives.

Some quantitative metrics that work well at a team level are:

• Velocity—the amount of work that a team can do in a sprint at a sustainable pace
• Predictability—the ratio of completed work to what was committed to in a sprint
• Lead time and cycle time—the time it takes for an item of work to be completed

BUSINESS METRICS

For stakeholders and leaders, at an organizational level, it’s quantitative metrics that are most effective. Numbers, graphs, and red/amber/green (i.e., a problem needs to be rectified/a potential problem needs to be investigated/the project is on target) indicators are clear and concise. They are more appropriate for understanding the big picture and even more useful if consistent across multiple teams. Organizational-level metrics that are useful include:

• Product or project goals met or not met
• Business value delivered or released
• Number of complaints reported by customers

CUSTOMER RATINGS

Customer ratings are metrics that are much less about the intricacies of how the team works and the techniques and tools they use and more about business outcomes. That’s why in addition to the team metrics covered here already, the team should also keep a finger on business metrics that they are reporting to the organization.

TEAM MORALE

Monitoring metrics that drill down to the work of an individual team member tends to be counterproductive. A number of features that an individual developer completed, for example, can never provide a full picture of this individual’s performance—it’s much more complex than that. Performance management is a completely separate process that should never be conflated with the metrics monitored for the team as a whole.

Drop-dead deadlines or targets can be another source of stress. If these are objectively required—for example, because they constitute a regulatory deadline or are tied to a calendar date such as the end of the year—this should be communicated up front. Announcing that a deadline is non-negotiable halfway through the project is not a good idea.

CONCLUSION