All too often new Scrum Masters get super excited about leading a project that they begin to lose touch of the basics and rely heavily on the “process” of leading a team through metrics instead of relying on the core values of Scrum and Agile. While metrics are important for opening channels of communication with a backbone of empirical evidence to back it up, metrics can very easily fall well outside of the boundaries of Agile and become distracting anti-patterns. I have debated on this subject a number of times with other scrum masters as to where they think metrics lie on the border of agile and anti-pattern. Here are some of my thoughts.
Ways to ensure metrics are NOT agile:
Metrics are process/tool heavy –Don’t prioritize gathering metrics over interacting with your team to drive discussion and remove impediments.
Metrics place importance on process over people –Don’t allow a specific metric to overshadow what your team is telling you, always consider your teams words more heavily than any metric.
Metrics do not deliver value to the goal– If metrics are distracting you or your team from what the sprint goal is then you are losing focus and need to realign without relying on predicting results or distracting metrics.
Metrics focus on results– Using empirical evidence to guide decisions is not the same as using metrics to set expectations. Regardless of metrics, a development team should always be allowed to openly discuss what they feel they are capable during a sprint.
Placing too much importance on metrics can create stakeholder tension– By offering uncultured KPI’s to stakeholders you may be incentivizing a lack of communication and collaboration. Use metrics to back informed decisions, not to avoid conversation.
Singular KPI’s can reduce transparency– There is no single, perfect metric that can explain where a team is and what they are capable of. Singular metrics can greatly distort the reality of progress to stakeholders if they are not cultured appropriately and used to tell a truthful story.
Ways to help metrics be agile:
Metrics are part of inspection– Being able to understand and culture metrics can help a Scrum Master better understand where they may be able to help with invisible pain points for the team.
Metrics can decrease necessary documentation– Stakeholders will always ask for highly detailed reports, especially during a demo, instead of spending long winded conversations laying the groundwork of where the team is, correlative metrics and decrease the amount of foreground conversation and get straight to the demonstration of new features.
Metrics can create insights for putting teams first– Use metrics to highlight when teams may be working harder than they usually do. For instance, being aware of the amount of used development time as compared to velocity allows use to compare the shared work across a team to their historical average. Use metrics as a means for empathizing with your team, not separating them.
Metrics can point out possible invisible impediments– Teams are not always aware of issues that may be slowing them down and causing unnecessary stress. For instance, being able to visualize committed story points as compared to story point creep mid sprint can help a Scrum Master determine if their team needs to change the way they approach planning for their next sprint. Use metrics as a tool for understanding issues silently, without using them as a mirror to be held against the team.
Metrics drive empiricism– Use metrics as an initial starting point of conversation with your teams but drop them as soon as the team has provided their input. For instance, if your team is growing their sprint velocity by 15% every sprint since the start of the project, it is an opportunity for you, as a scrum master, to ask the team if they feel like they are burning themselves out, instead of using the metric to expect growth to continue along the trend line. Use metrics to ask the right questions, not to provide answers.
How can we make KPI’s “Agile”?
The first thing to realize is that metrics are a muted voice within a development team, they are not meant to supersede the information that a development team communicating to their Scrum Master. Instead, healthy metrics should only be used to drive healthy and constructive conversation around how the team can improve and roughly where they are within the purview of their current goals. Metrics are not an indicator of where a team will be, rather they are simply an acknowledgement of where the team has been in the past. While metrics are helpful in obtaining a base layer understanding of the team’s ability to produce stories, they shouldn’t be held accountable to what they were capable of in the last sprint. Never put metrics over people and conversation.
Scrum Masters are not Jira administrators. Jira is a living document of the work that has been completed, is currently being worked on, and what may be worked on in the future. However, using Jira, or tools like it, are process heavy and deliver limited value to the stakeholders. However, if tools like Jira are a necessary evil for a scrum team then be sure to share the work within the tool, automate as much of the output as possible, and extract as much data out of Jira without having to do any more work than the minimum to ensure that your team’s goals and values are the core focus at all times.