Agile Coaches: Metrics drive employee behaviour | HCL Blogs

Metrics drive employee behaviour in Agile Teams

Metrics drive employee behaviour in Agile Teams
September 28, 2020

Whether agility is top-driven or bottom-driven is a topic that hardcore Agilists have been discussing since a long time without any outcome. But everyone understands the importance of top-level leadership in driving agility in an organization. We have seen that when new leaders join organizations, they bring a fresh mandate which helps the whole organization embrace agility with a fresh perspective.

So, why is it that change of leadership is so important to bring in “more” agility to an organization that has failed a few times? Why can’t current leaders start looking at the pillars of Agile through a new lens? What stops an organization in its zest for agility, to get better value to the shareholders, to get the right products zoom into the market for end users, and to make everyone in an organization feel wanted?

Change the organization DNA to be more lean and agile by embracing the right metrics

The answer lies in investing in the right enterprise-level coach who can work across all organizational levels to bring in a Lean and Agile approach. These are the people who understand the dynamics of big organizations as “been there, done that”.

Once leaders understand the need for being Lean and Agile, they can get one enterprise-level Agile coach. Then, they can bring in agility by aligning the middle management layer with the top and bottom layers with the right mindset and habits that will go a long way in enhancing overall agility. For a start, one enterprise-level coach can bring in an Agile charter and start working on the top management layer. Consequently, more Agile coaches can be added, depending on the size, location, and criticality of operations, for getting incremental benefits.

One example of driving the right behavior is “metrics”. Why should metrics be used? The answer is because they can “measure appropriately”. Leaders tend to measure what is important to them. Traditionally, they have been using metrics to find out productivity, bugs, etc., which means that teams would use all opportunities to hide facts and showcase a rosy picture. So if we see, the behavior of teams can be literally changed by using the right metrics. So it is not wrong to say that "metrics drive behavior”. By using the right metrics, the right behavior can be enthused into all layers of the organization.

How can we use metrics?

  1. Metrics should be used to fish out and remove “issues” that block a team from delivering value. For example, if a team is bottlenecked because it has too many heroes who know too much about the code of one particular branch, metrics that measure the “dependency factor” of a user story should be used. This implies the number of team members who can single-handedly deliver that user story. For a team of six developers, we need to track this metric till it reaches 5/6 in number.
  2. Metrics should be short-lived. Once the desired behavior has been embedded in the team’s DNA, the team should stop using this metric and look at other behaviors, like not checking code daily, too many defects within the sprint, and other aspects.
  3. Metrics should be used to make decisions. Any metric which the management does not use to make decisions should be discarded because it is an extra cost on the team.
  4. Metrics should come from the team. This way, the team gets a sense of ownership of the issue(s) and tends to feel empowered.

Anti-patterns in metrics

  1. Defect Density: Teams tend to measure defects per thousand lines of code (LOC), but what is the purpose? Why can’t we look at the issues that lead to defects and ask teams on how leaders can help them to achieve better code quality? Scrum Masters can do a fish-bone analysis and find the root cause of the bugs, which could be incomplete or erroneous specs, miscommunication, violations of programming standards, etc. Then the teams can decide on the two biggest problems to solve, by using the 80-20 rule. Then, the team can devise an innovative metric that can really help unblock the team. For instance, the INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) criterion can be used for requirements to be marked as “ready”. This won’t even be a metric and can be used as just a field in the story that needs to be filled by the whole team looking at story readiness. Once the product owners and business analysts start writing user stories that are all showing to be INVEST-worthy, then this field can be let go from the tool too.
  2. Productivity: Leaders often want to know how much teams can deliver. But this metric is anti-Agile to the core. Velocity, for example, should be looked from the perspective of “planning vs productivity”. So we say that, velocity is a “predictability” metric instead of “productivity” metric. If velocity is used to know how much of the product backlog would a leader be able to achieve with the current team in place, then the teams would no longer try to hide or fudge productivity or velocity. They would rather give leaders a definite number which would be used by the leaders as well as the team to plan for future work. This brings in a major change in team behavior, once they feel that leaders don’t judge them by looking at velocity. This increases the “trust and truthfulness” in the team which are, undeniably, pillars of Agile.

The road ahead for successful Agile

If leaders and Agile coaches just touch upon this simple aspect and start embracing metrics (at different organizational levels) that drive positive team behaviors and remove bottlenecks, this would mean embracing the Lean to the core. Consequently, these changes would change the whole DNA of the organization to be more Lean and Agile.

Agility can only be done one step at a time, and “this”, to my understanding, is the sharpest communication by leaders that says, “The first step toward a Lean/Agile approach has been taken. Now let us all do our bit to bring it home.”