Driving Changes on a peer-to-peer level

Question

This site is called "Project Management". I am unsure if my current context fits.

I am a scrum master. This means I am not "higher" or "lower" than anyone in my team.

We work on a peer to peer level (I hope this is the matching wording). And I am new in the company.

In the current situation there is a report which I would call "vanity metrics" (See Vanity metrics vs actionable metrics).

If I would be the leader, I would just say. "Stop it. Don't waste time for this report".

But I am not the leader.

I know, that if you ask "Why do you need this report?", then the others will find a lot of reasons why they think the report is needed. The more I ask into the direction like "stop it", the more the others will think they need to defend what they did in the past.

I think it is easier to convince people to start something new, than to convince somebody stop doing something which was done since several months. Related: Plan continuation bias

How to drive change on a peer-to-peer level?

Recommendations to books or articles are very welcome.

Answer 1

You can tactfully explore what changes have been made to improve the product or the team based on these metrics in the past few months. If these measurements have led to improvements or more effective decisions, they are not vanity metrics. Your newness can be a benefit here. You can say "Sorry, I'm new. Can you help me understand how the team or leadership has been using these metrics to make decisions?"

I they are vanity metrics, you can always take the approach of "what kind of information would help you make decisions more effectively?" and get people moved onto those measures.

Answer 2

Tough question; To my mind there are two choices:

1. Communicate the opportunity cost of vanity metrics to management. Measure the impact on project schedule/cost/quality by diverting resources away from production to ego stroking. (opportunity cost) On the other hand, if they define ego stroking as part of the scope, then stroke egos.
2. Help the team to prioritize; value added effort needs to be high quality; effort to comfort egos merely needs to be completed.

Answer 3

First of: thanks for the link to the vanity metrics blog. It was an interesting read.

Second point summary: monetize the costs

Second: I dealt with the same issue at my previous company. I created the report because I was asked to do it. After the first time I asked why I was creating it because it took some time to create (I could spend 3 to 4 hours gathering all the necessary information). The answer was: we use it make decisions on how to steer (obviously we had a long conversation about this because that in itself is not what a scrum team needs to hear from senior management).

Since I did not see the value of the report, I created it for a month. They got 5 reports in total. I asked them: "What have you learned from these 5 reports?" , "What actions will you take?" Their answer, "we have not read them yet." I stopped making them with the argument that if they have time read it, I will create it again. I added the argument that it was taking up a lot time that I could spent on my actual work and thus creating more value. This worked like a charm. I told them how much the creation of the report costs (including time needed from other people), it shocked them to see it in dollars. For me montizing the effort has never failed after that. If a company thinks the ROI is worth it, I check it after some time. And sometimes I was wrong, sometimes I was right (about it not being worth it), but someone always learned something from it.

Answer 4

If I would be the leader, I would just say. "Stop it. Don't waste time for this report".

Yes you could and this time you may be right. But are you always right?

The strength of a Scrum team is that it pools the knowledge and understanding of several people together. Decisions are made by consensus as a result of producing strong arguments or by adapting a good approach to working through problems.

I know, that if you ask "Why do you need this report?", then the others will find a lot of reasons why they think the report is needed. The more I ask into the direction like "stop it", the more the others will think they need to defend what they did in the past.

This is why it helps if a Scrum Master understands the motivation and bias that exists within their team.

With some team members you can simply present them with a strong argument.

Others team members may need to come to a decision themselves. In this situation it can be a good idea to focus on the consequences of the problem, rather than the problem itself. Often the team will then makes the decision itself.

For example, I might gather statistics on the time the team spends on generating reports. When the team sees these statistics they may decide that it is too much. As a Scrum Master you can then suggest they review all the reports they make and decide if some of them are unnecessary.

Making decisions like this is complicated and can be time consuming. It is worth it because a team of peers working collaboratively is a very effective way to work.

Answer 5

I think you have two issues and the first issue I am drawing the inference just based on what you wrote so I could be very wrong, but I'll take the leap.

A high performing team ideally would have a sense of team goals, objectives, a way of driving consensus, and mutual concern of its members among other attributes. I think your first issue is that your team may be not as high performing as they could be.

Your second issue is a lack of process. Decision analysis is an important management process and it takes a bit of effort to put and keep a good one in place. It takes some time to build decision criteria, methods of analysis, time to evaluate the problem, debate, and finally consensus building or voting or whatever the method is to choose. This doesn't require a leader to be done successfully and in fact probably works best peer to peer.

If your team was a high performing and a member brought up an issue such as with metrics, the team would use this process to drive the decision needed. You may not like the answer but it was team driven and that's what's important.

Answer 6

welcome!

You're asking a general question with a specific example. I'll try to respond to both.

I see several relevant points here:

General:

• you are a scrum master
• you are new to the org

Specific:

• you think this report is a waste of time
• the consumers of this report are...? (whether it's the team or the stakeholders might affect how you proceed)

The fact that you are an SM, rather than a member of a dev team, is the most significant circumstance with respect to "driving change on a peer-to-peer level". There are plenty of ways for a team member to drive change on a team: for instance, a senior dev could lean heavily on their experience; a highly opinionated and assertive dev could dominate the conversation; a data-oriented dev could dazzle with statistics; and there are more. But a scrum master has a different role, and therefore a different approach.

A scrum master's role is to coach the team towards improvement. As the saying goes, "I'm not here to answer your questions; I'm here to question your answers."

In fact, I would move away from the paradigm of "driving change": that sounds as if the devs are horses pulling a wagon, and you're holding the reins, driving in a different direction. I suggest instead "encouraging change", "motivating change", "wondering about change."

Now let me pause for a moment and take up point two: you're new to the org.

How are your team dynamics going? I would strongly suggest teambuilding and team formation as your first priority: because until you are at least somewhat accepted and trusted by your team as one of them, they are not going to be open to any change suggestions from you. Take a look at the Scrum values, and see how you're all doing with those.

Encouraging change as an SM takes patience, respect, collegiality, and more listening than talking.

Okay, now back to how you, as a scrum master that is well integrated with your team, can encourage change in an area in which you believe there is room for improved agility.

First, try to let go of the conviction that you are Right about this, and if your team would just Listen To You, they would understand and be persuaded. This is not a productive attitude to bring into a conversation that is exploratory, curious, or encouraging. (Believe me that I know how hard this is to do! ;) )

The retrospective is the canonical place to inspect the team's processes and procedures and identify actionable areas for improvement. As SM, you can design the retro to encourage reflection about the broad areas that you think this report falls into. For example:

• make a chart with Effort on one axis and Value on the other. Have the team spend some time in silent writing on all the common activities they can think of, then place them roughly on the chart. Have a conversation if there is disagreement about where an item should go. Then look at the (high effort, low value) area of the board, and see if you can identify some things that could be moved in the direction of (low effort, high value) or even dropped altogether.

• have a discussion about metrics and reporting, and identify what goes into each and what is driven by each. Have the team collaboratively draw charts to show this: some of them will likely be the standard scrum charts of inspect-adapt cycles, and some will be more locally specific things.

• have a conversation about the past, present, and future of communicating with stakeholders -- involve your PO heavily in this. For every communication pattern or artifact in common use, tell the story of how we got here, and imagine where we might go in future to be more agile and provide more value.

Be open to whatever insights, questions, and changes might come out of these. Don't try to drive the conversation specifically to the outcome or even the specific topic that you want. If the team is especially engaged by one of these, repeat it a few times, either every sprint or interspersed with other approaches. I would let the team have a few of these before I brought up the specific report I was worried about, if they still hadn't.

One last thought: one approach that might be helpful in defusing this kind of pushback:

I know, that if you ask "Why do you need this report?", then the others will find a lot of reasons why they think the report is needed. The more I ask into the direction like "stop it", the more the others will think they need to defend what they did in the past.

is to try the "Five Whys" (https://en.wikipedia.org/wiki/5_Whys). I always introduce this with something like "I am not being deliberately obnoxious, this is a real technique." And instead of asking "why do you need this report", I would start with "why do we produce this report". (Always use "we" language!)

I hope this helps. Good luck!

Answer 7

This Question is best Suitable in context of Leadership skill.

Since you are new in team and team is following preconceived mind set you need to apply your leadership skills to convince what is more beneficial?

I agree that tool of opportunity cost can help but still how you apply that tool will be more important.

Answer 8

I would suggest that it really isn't your place to decide whether or not someone else finds a report to be useful. As a scrum master you're the informal leader of a team that doesn't have a leader, tasked to lead by persuasion and not authority. But that does not necessarily mean that you are to determine what the team is to do, nor whether a particular thing that the team is [externally ...] tasked with doing is beneficial or not. You should start with what the team is tasked with doing and then work with and within the team to facilitate it achieving its missions.

Especially given that you are new, "listen much."