Anonymous feedback sucks, but we give it anyway!

Anonymous feedback sucks, but we give it anyway!

A little while ago, the team coach at one of my clients suggested that we collect feedback from the team anonymously to understand the ‘team health’. My opinion has been that you can explore and understand a team’s health by frequently talking and working with them. So, I wasn’t really in favour of gathering data anonymously, but since I had started working at that place  only a few days ago, I asked for more information. 

Turned out, the team coach, who was a nice person and was quite experienced, was actually not in favour of collecting anonymous feedback either. However, the inexperienced manager of that group truly believed that feedback should be collected that way and therefore commanded the coach to follow the process. 

I believe that most of us don’t like receiving anonymous feedback. To validate my assumption, I spoke to a number of people. However, I wasn’t entirely surprised when many of them told me that they didn’t mind providing it when asked. Some even admitted that they have exaggerated while giving feedback anonymously. Giving and receiving feedback can be daunting, however, it can be worse coming from an unknown source.

My experience is that managers who have a command and control mindset do not like transparency, conflict or challenge. They see that as confrontation and try to avoid that.

How people engage with each other, and how managers and team members give or receive feedback often tells a lot about an organisation’s culture. Correct?

I can see that you are nodding your head, most likely in agreement. Well, if you trust me enough then tell me about it.  

Let’s try to analyse the feedback given in an unidentified and unspecified manner. An easier way to analyse that is break it down.

Analysis points:

  1. Is anonymous feedback good or bad
  2. What happens when people are allowed to give feedback anonymously
  3. How do we feel when we receive anonymous feedback
  4. Criticism or critique
  5. What does good look like
A person giving feedback to another while hiding his face

Is anonymous feedback good or bad

The debate about anonymous versus face to face feedback isn’t new. In my work as a coach, consultant and sometimes as a manager, I have come across scenarios where leaders were looking for, and at times, encouraging, anonymous feedback. Their logic or assumptions often were similar. “People feel confident providing anonymous feedback and we learn what our teams actually think about the organisation or the processes or the management or all of these.”

Nonsense!! If the culture of a place isn’t conducive to openness, people will not tell the truth even in an anonymous survey.

If people in a team find it hard to offer direct honest feedback, then it is clear that the group has trust issues. Because if I trust you enough, then I’d feel confident that you would listen, pay heed and won’t mind about my feedback.

So, in general, it seems that anonymous feedback isn’t a good thing.  

What happens when you are allowed to give anonymous feedback? 

How people respond to a request for feedback largely depends on how they feel in the setting in which they are. We respond and react passively or negatively in an environment that makes us feel unsafe. That’s why the ‘feeling of safety’ matters a lot. When employees feel safe to challenge the management, they inadvertently also save their employers from a lot of trouble. When they don’t feel safe, they won’t bother telling the management that the organisation was on fire, and in some cases, literally.

In a blame culture, while some people give up hope that the management would take any actions on their suggestions; few others find the request for anonymous feedback a great opportunity to vent their frustrations. They may exaggerate situations, they may skew data by giving the lowest score for everything and they may even lie if they feel vengeful. And  why wouldn’t they? Anonymity provides them the veil to do things that they wouldn’t otherwise do.

Receiving anonymous feedback: 

Here is a scenario that you will possibly recognize.

“Hi, we need to talk”:

Your manager comes to you and says,”I have received some feedback about you from some of the team members. They think that your quality of work is poor, you delay their work by not responding on time and you arrive to work late. I’ll have to take some action if you don’t improve.”

Naturally, you are taken aback because you thought you had cordial and honest relationships with your colleagues.  You considered them your friends and you always assumed that they would approach you for any concern they had about your work. Anyways, you always believed that you produced high quality work. You have been praised for your work by the clients and this feedback did not seem to make any sense.

So, you ask,”who has given that feedback?”

Manager says, “All feedback that we receive is anonymous. We don’t want people to feel exposed or unsafe for providing information or feedback. And we also don’t want people who receive feedback to be vengeful.”

“That’s a load of bollocks!”, You feel like saying to your boss, but decide to keep this thought in the mind and don’t actually utter it. Times are tough and saying that could be a career limiting move.

Instead you mutter, “I understand that, but without knowing exactly what the issue is, I can’t accept or even take action on this feedback. Actually, I think all of that feedback is incorrect. If you tell me who’s provided this feedback then I will work with them to fix things.”

Of course you never get that information.

The problem in the above scenario is that you don’t have any specific information. The feedback was vague, you didn’t know who provided that. You also don’t know whether your boss misunderstood what your colleagues said about you or whether they all were truly two-faced people. If you have a weak manager, then the first thing that comes to your mind is whether your boss was making up all that feedback. 

Whatever the case maybe, now you have a dislike and distrust of almost all your team members and also your boss. The damage has been done.

Criticism vs critique:

Criticism is always an attack on someone’s person. When you give critical feedback, you’re talking about that person and how bad they are. However, when you critique, you talk about an attribute of a person, and not the person.

Brene Brown says this about anonymous feedback:

“If you’re not in the arena also getting your ass kicked, I’m not interested in your feedback.”

What does good look like?

The good looks like working in a culture where people feel safe speaking out, respect is a common behaviour, the management folks are open and honest in accepting mistakes and failures and actively ensure that their teams do the same by encouraging them.

I worked with few such teams (I have yet to see an ideal organisation) where people openly expressed their opinions and views. The leaders there created a culture where we felt safe to debate and challenge in an honest, healthy and respectful way.

In an environment like this, team members as well as managers can offer genuine and meaningful feedback in a supportive way. There you talk like mature people. And that not only helps the individuals to grow, but also helps their teams and organisations to stay on course. These cultures also encourage frequent and just in time feedback instead of waiting for a quarter of a year to deliver bad news.

Follow here
Three Agile and Scrum questions from a reader

Three Agile and Scrum questions from a reader

Delivering work using Agile practices can be tough because work environments vary and different organisations throw different kinds of challenges on us. I often receive questions from readers about agile delivery practices. What I have been observing for a while is that the questions mostly relate to dealing with people. As Jerry Weinberg said through his Second Law of Consulting, “No matter how it looks at first, it’s always a people problem.”

This post answers some of the common questions that I recently received from one of my contacts. I have made some minor edits to make the questions generic. 

Coaching teams and organisations

Question 1. How should I as a Scrum master go about coaching the organisation about Agile. I come from a consulting background and coaching is usually limited to the Scrum team that I work for. Are there any techniques that can help me coach organisations or stakeholders?    

Answer: As a Scrum master, oftentimes you will only work with a couple of teams. Coaching one or two teams is easier, manageable and more convenient. However, there’s no optimum number of teams that a Scrum master can work with. Although it might appear useful that a Scrum master should only work with one team, a lot depends on the nature of the work the teams are doing, their maturity in terms of the agility, the complexity of the work, the structure, size and the culture of the organisation etc. 

One thing is sure that as a Scrum master, an organisation wouldn’t want you to be spread too thin. In his book Secrets of Consulting, Jerry Weinberg offered us his Law of Raspberry Jam, “The wider you spread it, the thinner it gets.” And, as you may know, good jam has lumps. I think a thinner jam loses taste too. In our terms, that’d be losing focus or interest.

Now coming back to your question of coaching the organisation. It pays to confirm what someone means by coaching. People often confuse training and coaching. Let’s assume that they want you to coach the organisation on using Agile practices. How would you do that? Of course you will understand their context, the training and skill gaps, and possibly the problems they want to solve through coaching. Accordingly you will find the things that will offer you few quick wins and time to find a long term solution.

Techniques of coaching depend on who you’ll deal or work with. I often mix things to make them accessible and practical. For example, I’ve organised brown bag sessions, arranged team surveys to find out what they want to learn, scheduled coaching sessions with other Scrum events so that teams don’t use the sprint time for training, coached teams by organising team contests etc. My experience is that given sufficient notice, stakeholders enjoy taking part in contests or challenges.

 

Getting pushed back on Agile Delivery

Question: Many times I get to deal with Clients who have low agile maturity. Either at the team level, or at the stakeholder level. I get pushed back on Agile process delivery as this would disrupt their business. In such a scenario, I initially did an Agile/Scrum 101 training. Talked about my successful experiences from the past with successful Agile delivery. However, I still felt that the clients or teams were not convinced. How should I have approached this as SM differently to get the stakeholders or team to buy into Agile ways of working?

Answer: That’s a good question and many Scrum masters, Agile coaches and delivery managers experience similar challenges.

First thing that we should understand is that Agile itself is not the goal. Even though some organisations might say that they want to be Agile, their main objective is possibly to solve some other problem through applying Agile methods or the mindset.

What often seems to happen is that when given a responsibility, many Agilists blindly start applying frameworks, tools or methods. This results in pushback from teams as well as stakeholders. (You might want to watch this video about tools and frameworks). Agile is about change and we know that people don’t like change because change is hard. (But remember that change is not always resisted. Having new born babies brings a huge change in people’s life, but almost everyone enjoys that even though it turns their lives upside down, at least for a while.)

Your clients must have hired you for a specific reason or reasons. They wanted you to solve some problem for them. Understanding their problems, their context and what bothers them builds your own confidence in the problem solving process and also instills confidence in the client. Running Agile 101 is the easy part. Knowing whether that is required, is the hard part.

Old School Product Owner?

Question: I had a tough PO who needed all requirements into the project delivery roadmap. What would be the best way to convince a PO that we cannot have all the features in the product roadmap and can only accommodate a MVP approach ensuring we can only focus on features that can be developed in a given period of time.  

Answer: It appears to me that your PO was not trained in product ownership and was only carrying the PO label. You might want to show them this video from my talk at the Agile POs and BAs meetup. In this talk I explained what product ownership is and how the prioritisation works. I’ve heard that many people found it useful. 

Although things have slightly changed since Henrik Kniberg wrote about MVP, sometimes I still use the sketch that he created to explain the idea.

You may also want to make sure that the POs you work with get training in product ownership and understand that their job is not to manage people, but to work with them for frequent delivery of valuable outcomes. You can do that by building a trusted relationship with them. Think about getting into a social contract with them.

Side note: there is no single ‘best way’ for almost anything, but there are always many good ways. ‘Best’ expresses ‘the only way’, while there can be more than one way of achieving our goals.

So, these were my responses to the questions. What else would you add to these answers? Would you answer these questions in a different way or would you give a completely different answer? Let me know.

Follow here
Biases, mindset and tools

Biases, mindset and tools

Few recent conversations made me think about the approaches and tools that we choose for delivering valuable work. Many people rely solely on tools that they’ve always been using. They never change their ways of working. Or, they may change the labels, but not the actual approach.

This is the snippet from the first conversation:

One of my ex-colleagues mentioned that his primary stakeholder, who happens to be the executive of the department, told him not to bother her about the process and frameworks he was using. She hated any mention of Agile, Kanban or Jira. She needed detailed plans, roadmaps and estimates and believed that other approaches didn’t work.

Why was that? 

The other conversation happened during a recent event. A participating senior manager of a large organisation was concerned that stakeholders don’t understand iterative approaches. He wanted to collect and use more data points to prove that work was happening. My personal observation was that his team and he himself lacked an iterative delivery mindset.  Was his approach to rely on data right?

What seems to be the problem? 

“Elementary, dear Watson!” (Actually, Sherlock Holmes never said those words in any of the stories. At least I didn’t come across those words. I have read Sherlock Holmes more than once, I enjoy that so much.)

These conversations remind me of a few cognitive biases. Primarily of the curse of knowledge bias and Dunning-Kruger Effect.

It might be true in both cases that one party thinks that the other one knew more than they actually did. My colleague possibly was talking in a jargon laden language that the business executive didn’t understand and decided that it was all nonsense. All the while the ex-colleague assumed that she being an executive knew more about what he was talking about. That’s the curse of knowledge. 

It is also possible that the same executive believed that she knew more about all delivery approaches. And the ones she actually knew more about, were the better ones, because she knew more about them (sounds dumb, but that happens). That assumption by her makes the other ones bad automatically, at least for her.  

That’s the Dunning-Kruger Effect.

The third point I want to make is not about bias, but about data. 

Data is ruining everything.

Well, not really. We rely on data for decision making. However, over-reliance on anything is bad, isn’t it? I must remind you of the Challenger catastrophe if you disagree with my assertion. You can read about that here. If you read the report, pay special attention to Richard Feynman’s observations and findings. Every word there is insightful.

In a nutshell, what happened then was that NASA wanted to make decisions purely on data, while an engineer had a gut feeling that there was something not right with the O-ring (type of a valve that stopped gases from leaking from the spaceship). That engineer didn’t have data to prove, only a strong gut feeling. 

We all know about the disaster where few astronauts sadly lost their lives.

The CTO in our scenario is focusing on data. It has been proven many times either through research, or in real life, that statistics often fails to influence us compared to social proof. 

Not convinced? 

Think how many times you have made decisions based on a friend’s advice. We approach our family or friends and read online reviews when we buy cars, houses, electronic equipment and other stuff. We look for social proof there.

So, I’m not surprised that by offering data to executives, this person is hardly making a difference.

What else is happening?

What do you think is happening in these scenarios? I’m looking for more insights before we jump into potential solutions.

Let me know either by commenting or emailing. 

Follow here
Commit to CRIME

Commit to CRIME

When Mike told me and few others that we should commit to crime and also get our teams to do that, I was like, “Huh? What do you mean?”. 

 He went on to explain what CRIME acronym was. 

CRIME stands for Collaboration, Retrospective, Investigating, Mapping and Exploration. I found the acronym useful as this reminds you of the basics that we should all be following and keeping track of. In fact, mnemonics has been a proven technique for remembering ideas and concepts for a very long time. People who have studied chemistry will possibly remember how they memorised the Periodic Table.

This website is a useful resource for learning more about mnemonics.  

I have attached the sketch for you that you can share with your teams.  If you can’t download it here, then please email me and I’ll send it to you.

Mike is a friend of mine from North Carolina. He is an author, speaker and QA Director. Although he used the acronym CRIME for testers, I modified it to suit Agile delivery people and teams.

 

Crime acronym

Follow here
Tips for Job Seekers

Tips for Job Seekers

As a #JobSeeker, one of my mentees asked for help and I gave him few tips to deal with the current situation. I hope they are useful to others too.

1. Do some planning:
– what can you do to manage the situation in the short term
– what does the long term look like

2. Stay afloat:
– In the short term, find ways to generate some income (selling used things online still works.)

3. Take Action:
– Re-connect with those you know and build new connections. Others might be in the same shoes as you are. So, gently ask for help and follow up after some time.
– Apply for relevant jobs.
– Can you deliver an online or virtual training? Consider those options too.
– Make a list of things you are good at. Don’t judge yourself by saying, “I’m not good at anything.” Just make a list. Can you cook, sew, build, design, teach, sing, dance,..? Someone out there might need help in that.
– Stay up to date with your skill area.
-Negotiate your rent, utility rates and mortgage.
– Can you secure a government grant to start a business? Find out.

4. Stop worrying:
Yes, easier said than done, but let’s try that. Worrying takes energy away. Distract yourself from negative things. Do things that make you feel better.

Things will improve eventually. Stay positive.

Advice for Job seekers

 

Follow here