Over the years Ram had been setting goals/ KPI for his team with ease. For the development team, it would include lines of production code, # of defects that were detected by the test team; for his test team it would be # of in-process defects detected, # of defects found in UAT; for the business analyst group it was defined by the number of complete specifications he would provide, the quality of it being measured by the number of times he was changing the specifications.
This year, the organization was moving towards a cross functional team, and Ram had to adopt it. So Ram asked his three leads (development/ test/ analyst) to double-hat as the lead for each cross functional team as well. In over two months, he found that everyone who belonged to a different capability than the lead, was unhappy. Ram found his apprehensions about the cross functional team coming true.
Ram listened to his HR lead telling him – “What gets measured, gets done.”
Why did Ram land in this situation in the first place? What would you recommend to Ram, continuing from what the HR lead told him?
Suggested Solution
Here’s my perspective on what could have caused Ram to land in this situation:
1. The leads are able to understand from their past in their own area… and worse still, they probably have seen the other capability teams as being the issue, in the early avatar – so that could be influencing them.
2. Sometimes, we find people interpret the change in direction very superficially. So the response tends to be one of complying with the mandate, just in the letter and not in spirit.
3. At an extreme, Ram might himself not believe in this new approach. This would then make it difficult for him to truly understand the intent of the change.
4. There are other times, when the organization itself is the issue. It keeps coming up with new directions ever so often and then they all fade away. So this could have become the case of the boy who cried “wolf, wolf…”.
What could Ram do:
1. First Ram needs to internalize what is the reason for this change from “capability silos” to “cross functional team”.
2. Next he needs to have a dialog on this with the three leads in their new avatar – helping them understand the intent, and also listening to their challenges.
3. All of this will now help in setting a single goal-set for the team, and then determining the right set of metrics for the cross functional team.
This could be the way to re-look at one of the metric:
Let’s say the goal is no significant defect in UAT. This now becomes the goal for the analyst + developer + tester.
So it would result in front-loading the challenges.
The business analyst would then be not that concerned about making the changes to the specs, in as much as making sure the specs will ensure that the developer and tester can ensure that the issue will not get detected in UAT.
The developer will no longer be satisfied in just meeting the specifications and griping about the changes that come. He would work with the analyst to clarify early and often – so that he does not have a UAT issues.
The tester will not look at the ratio of the defects he detected in testing to the UAT defects found. He would instead focus on providing the testability inputs up front to the analyst if it is ambiguous to ensure that there no unnecessary defects. He would work with the developer to share the test suite early on, as the goal for him is not about how much did he discover in testing. The goal is to ensure together to reduce the number of UAT defects.
So, in summary, get each team member to have the same metric (goal) and how they will meet it together. The goal is not silo-specific, as earlier – which would have only proved the efficacy of them individually, but not collectively as a team.
