Agile Metrics in Practice #5: Dealing with the Detractors

A series for self-managed agile delivery teams wanting to continuously improve and stay ahead.

“What’s in the way is the way!”

Let’s face it: agile metrics in practice can be a struggle.   We’ve all experienced many blockers that fly in the face of optimising team success through the use insights that metrics can provide. Push back, inefficiencies, the fear of visibility and the weaponizing of transparency are all reasons for wanting to give up on many occasions. The hardest thing I find though is usually the reaction of stakeholders whether it be from peers, leaders or my own team members. Loosely speaking, I usually find three types of responses that are either unsupportive or undermine the role of metrics in building team success: the sceptics, the aggressors and the detractors.  In this post I elaborate more on these response types to help you recognise them and be more prepared for how you might respond. If you’re going to build a culture of agile metrics in practice, you need to know what you’re up against.  There’s no avoiding it, so name it and tailor your approach to building the right bridge to shared success.

1.The Sceptics

The first group of responses I encounter are from the sceptics.  As developers, they’re used to working with visibility but are most concerned about the ‘Big Brother’ effect and any micro-managing that may arise.  They fear the use of metrics will fail to account for complexity and encourage undesirable behaviour (read anything from gaming, manipulating or corrupting those with something to gain). They’re also concerned that adopting agile metrics will be too hard, take too much time and excessive weight to your process.

How to engage:
Despite their caution, they’re open to receiving the insights.  Start with a conversation about what prior experience they’ve had with metrics in delivering software, what’s worked and what hasn’t.  It’s often the case that any hesitation arises from encountering a negative experience either directly or indirectly. Demonstrate quick wins by keeping your learning system simple and making the metrics a by-product of your work.  Remove any manual collection of data and showcase the value from incremental improvements in team outcomes that are tracked overtime.

2.The Aggressors

The second group of people that undermine the effective use of metrics are those that weaponize them for personal gain and rarely for the common good of optimising team success. In this case, you’ll recognise metrics being applied as a lazy performance management tool, with a myopic lens imposing arbitrary benchmarks to cut off anyone who falls ‘below the line’. These are the folk that usually have most to gain, and ironically also the most to lose based on what they’re deflecting. Say hello to the den of hierarchy, dictatorships and bureaucracy!

Their practices feed a culture of metric tyranny.  Common practice examples include being fixated on data as the end rather than the means. Judgements are made solely on data with no broader context taken into account. Stakeholders aren’t included in any discovery conversations to identify possible influencing factors. The predominant viewpoint is narrow, backed up by a singular focus on only one or two metrics rather than a broader wholistic lens. Metrics in this case are often abused, gamed and turn any genuine intent to create a learning system on its head.  Additionally, in these environments metrics feed rewards, penalties and interpretation bias. They measure productivity with the intent of increasing efficiency (rather than effectiveness) and in the meantime make everyone miserable. With an adversarial mindset, teams are pitted against one another despite working on entirely different things with entirely different contexts.

How to engage:

Whoa! Need to take a breath after entering the den?  Do!  In these cases, play the ball and not the person.  Debate the facts and assumptions.  Show that you’re open to building a collaborative approach and take a collaborative tone.  Expand the discussion with a broader set of data points and enrol the support of peers in unpacking influencing factors that can be brought in for support.  Don’t be afraid of disagreeing, or conflict.  After all it’s just a different opinion that you’re offering.  Most of all, stay focussed on outcomes, ensuring success for the customer and removing inefficiencies for the team. Keep the discussion away from adding layers of process and turf wars!

3.The Detractors

Finally, there are the detractors.  These naysayers will be hoisting barriers at every turn to undermine or talk down the reality of having their work measured. The responses are usually driven from fear of the unknown or a lack of control. Arguments I encounter include:

• Metrics are an invasion of privacy,
• Metrics will slow the team down by making process too heavy
• All metrics are flawed and can/will be played.
• Developers are not stupid, they know how to manipulate metrics.
• Metrics lead to undesired behaviour.
• You’ll destroy team culture and encourage bad behaviours that essentially hack these metrics to appear more productive.
• Stop considering developers like code writing robots, trying to squeeze out more work from them. This will only cause team’s morale to plummet. Software development is a creative process, and give some breathing room to each developer

How to engage:
Listen. Start with why and declare your intent. Be explicit on what your agile metrics will and will not be used for. As a starting point, consider ruling out metrics influencing individual performance reviews, incentives and promotions.  Adopt a growth mindset and show you’re cooperative and willing to make changes across the board. Some team members you can help support, others you can’t.  Finding out involves open, safe, vulnerable conversations.

Take ownership for measuring your own team.

At Umano, we’ve always believed in empowering self-managed teams that self-direct their learning. Why? It’s simple: to bring their best selves to the task of doing their life’s best work. Delivery teams should be responsible for tracking themselves through metrics that are easy to obtain, communicate and understand.  Afterall, the people doing the work are responsible for the improvements.  If anybody measures anything, it’s the actual workers who act on those measurements immediately.  Feedback loops need to be short so immediate changes can made for improving effectivity.  Backed by data-driven insights to influence the practices of other teams around them, teams can feel empowered to shift the needle from ‘local’ optimisation to ‘global’ optimisation.  Mike Rother explains in Toyota Kata that Toyota believes the most important factor in productivity is a pervasive continuous improvement culture. Agile methods have natural pauses to allow your team to check and adjust.  At this point, teams should have an idea of the good and the bad of how to approach and do your best work.

Now take the bull by the horns and start measuring!

Umano is on a mission to help self-directed teams succeed by providing real-time feedback with data-driven insights that help agile teams to continually improve and stay ahead.

Sign up here to access your complimentary Umano account and see how your team’s agile sprint practices are tracking.

Join our slack community to learn from others and be a part of the data-driven movement to improving team performance.