Giving Feedback – A Worse Than Useless Idea

One of the favorite activities of HR departments seems to be herding people into teamwork trainings. In these trainings they will have endure learning about all sorts of ideas related to teamwork. Most of them with no scientific validity. Learning to give feedback to other team members has its sure place in sessions like these.

We also have the common practice of managers giving feedback to employees. This is a particularly toxic version of the feedback idea.

I guess that the belief is that it all will contribute to better teamwork and performance. It does not though.

The whole idea of giving feedback to others actually prevents any type of progress towards collaboration.

If you are interested in agile ways of working, this is something to think about. Most agile ideas are based on increased collaboration…

Why Give Feedback?

The way I see it, the idea is often that:

  • You will bring to the attention of others how they have behaved/performed.
  • After receiving your helpful feedback, they will then be able to improve. In the direction that you so graciously have identified.

Thus, the feedback is about the other person. You tell them how things are so that they can alter their behaviour. Great idea!

So What Is So Wrong With That?

Many things…many things…I’ll focus on one aspect below:

From Team Facilitation Point of View

The problem is the mindset commonly associated with giving feedback. I perceive it like this:

  • The way I percieive reality is the right one!
  • I will now educate you on what the truth is! That is a one way process!

In the research of Argyris and Schön, we find a similar mindset called “Unilateral Control Mindset“:

  • I understand the situation; those that see it differently do not
  • I am right; those that disagree are wrong
  • I have pure motives; those that disagree have questionable motives

Pretty similar, isn’t it! For me, the way “feedback” is most often used, is deeply rooted in the mindset of unilateral control.

If so, how would that affect things in a Scrum/Agile team or in an agile organization?

“It would prevent any sort of progress when it comes to collaboration!”

Wow! And that is the opinion of master facilitator Roger Schwarz. Author of “The Skilled Facilitator“, the standard textbook for team facilitation.

In his book Schwarz dismisses the unilateral control model. Instead he bases his facilitation approach on the quite different “Mutual Learning model“.

The Mindset Of Collaboration

Some assumptions in the Mutual Learning model are

  • I have some information; others have other information
  • Each of us may see things the other do not
  • Differences are opportunities for learning
  • People are trying to act with integrity given their situations

According to Schwarz, when acting from these assumptions, true collaboration, synergy and growth is possible.

So, what is the difference? A key difference is that with this mindset you do not assume that you understand the full picture. You accept the fact that in a complex environment, such as a team or an organization, for one person to know what is the “truth” is not possible. Instead you focus on learning.

So, please stop giving feedback/passing judgement on others. It does not matter if the “feedback” is good or bad.

You do not have the full picture, pretending you do is both silly and unproductive.

My Take On It

So, what to do then? Communication and collaboration is great. It is just that giving feedback is not the way to achieve that!

Here are some alternatives that have worked well for me:

  • Make sure that you know what the needs of people in your environment are.
    • What do your teammates want to experience, learn, achieve etc?
    • What would make them feel that working together is worth their time and full attention?
  • Take responsibility for making your own needs known
  • Take responsibility for that the way you work adresses the needs of the people around you
  • Engage in dialogue. Do not give feedback.

Note that these are all focused on you. Your learning, your needs and what you can do. So, if this does not work out, you know who to talk to… 😉

Good luck, and if you have any feedback on this article….you know what to do with it 😉

(Sent it to me that is, in the comments field, for mutual learning…;-)


Inhumane Scrum Masters In Demand

I was talking to a friend the other day. She was looking for a job as a Scrum Master. Her background is technical and the last year or so she has been working as a professional coach. Not in IT that is. Just helping people to think and grow.

We came to talk about if she should include her coaching skills in her Scrum Master applications. Others had advised her not to.

“Companies might feel that professional coaching is too touchy-feely for a Scrum Master”, they said.

So, she was leaning towards not mentioning it in her applications.

Also, companies in general are asking for Scrum Masters that are experts in the technology that their team is working in she told me. Not for soft skills. So maybe her next step as a Scrum Master should be to take an advanced Java course?

Inhumanity as a core skill?

And I have seen this before. So perhaps a Scrum Master without soft-skills is what your organization needs?

Could be! To avoid changing anything that is. If that is your goal.

The actual job

The real skill set for Scrum Masters is designed to help organizations, teams and individuals to improve. And to improve is to change.

Guiding and assisting people as they change and improve requires zero Java skills.

It requires some serious soft-skills though.


Esther Derby wrote a nice summary of Scrum Master skills and traits a few years ago.

Some required things from her article:

  • coaching
  • facilitation
  • interpersonal skills
  • influence
  • team dynamics
  • systems-thinking
  • organizational change agent

These things all have to do with human beings and how they interact. These are not technical skills.

You could call them”soft”. They require quite a lot of courage though.

To be successful you will have to face your own inadequacies. You need to realize that your own beliefs and actions to a large extent are contributing to creating the things that you are most unhappy with at work. You need to work on fixing that.

You need to show vulnerability and you need to take those difficult crucial conversations with your peers as well as with people that outrank you.

If you acquire the skills and face up to these challenges, you can help create a healthy organization. According to Patrick Lencioni, this is what ultimately leads to business success.

So, about calling them”soft-skills”, I don’t know what would be any more hardcore than that…

Climbing Mount Everest? Nah, that seems like a walk in the park compared to the organizational change challenge 😉

The catch 22

Realizing that organizational health is the key to success requires a culture change for most organizations.

No culture change will happen without expert help though, but without culture change no experts will be allowed to help…

Which makes it a catch 22. Companies will keep looking for “Technical Scrum Masters” or the dreaded “Scrum Master/Project Manager” etc.

Unless you have organizational change super powers the sane thing would be to run like crazy when you see one of those ads.

On the other hand we need to resolve the catch 22 somehow. One way would be for some courageous people to take some kind of Trojan horse approach. Sign up as a “Project Manager/Scrum Master” and start working the change from the inside. Engage with the agile community and learn how to involve the leadership of your organization.

Another option would be that someone with adequate positional power decided to give it a try and brought someone in to help even though what was being offered currently seemed alien to the organization.

A note to hiring managers

The competition for good technical persons is quite high in some places. Hiring people with different backgrounds as Scrum Masters might be very much easier. In addition to that they might be more suitable for it. And salaries would probably be different to…

Just think about it. What would be a “safe to fail” way for you to give it a try?



Picture source:


The #1 rule of agile management

Think about this: If everyone in your organization could do whatever they wanted at work, would they do anything differently compared to today?

If so, your organization is in big trouble!


Because that means that some of your people do some of their work because they have to, not because they want to.

Consider these top three challenges of today:

  • The young people entering the work market today have other experiences and expectations
  • It has never been more difficult to guess what customers may find valuable
  • The global competition is tough, and getting tougher

None of these can be solved by people doing things because they have to. More on that below.


Try hiring someone with internet in their DNA from birth. Someone that has been building phone apps on their free time. Someone that has been contributing to open source, just for fun.

Then tell then that you will decide what they will work on. Also, you will tell them with whom to work. And that there are many other things that you will decide for them also. And that they will have to wait for a year before they can have any sort of real feedback from users.

Good luck with that…

We have to set our workplaces up so that people will want to work there.


The world is changing ever faster. It is also getting more and more complex and hard to predict. Guessing what customers may find valuable rarely works anymore.

Instead we need to learn what works through massively experimenting. This requires short development cycles. Measured in weeks, days or hours.

When it comes to innovating in a complex world, it is also a numbers game. A central investment decision point in a company, such as a product manager, will not do. We need to go for volume and for diversity of ideas.

Alas, you cannot command people to take initiative, to be creative or to be passionate! This only happens if they want to.


Whatever successful products you build is likely to be copied really fast by some competitor. The same goes for any innovative business model you may have. The average lifetime of big companies have never been as short as it is now.

Again, to survive we need to speed up on innovation and/or shorten the time it take to respond to competitor moves. Agile practices has been the standard attempted cure for that for more than a decade,

But, having people follow some agile framework because they have to does not work! Agile works because done right it awakens the intrinsic motivation in people.

When dropped inside a traditional organization without a mindset change, the practices give very little value.


A change of mindset is required


Gary Hamel's Pyramid of Human Capability

I think Gary Hamel explains the situation well. Look at his ‘pyramid of human capability above. It shows different levels of engagement employees can choose to apply at work.

It used to be possible to compete by having access to hard working obedient experts. This is not the case anymore. Anybody can buy that. In some places even for a very low price.

What matters now is if your organization can deal with the top three problems at the top of the article. The solutions to all of them are all based on decentralization and delegation.

Decentralization and delegation in itself will not fix the problem though. We also need people to start operating from another mindset.

  • We need people that show initiative when needed even outside their job description.
  • We need people that keep scanning the surroundings to come up with disruptive innovative ideas
  • We need people that feel passionate about their work.

The agile management solution

Since you cannot command people to take initiative, to be creative or to be passionate, the solution is quite simple:

The #1 rule of agile management: Treat everyone as if they were volunteers

If people choose to do whatever it is that they do, because they want to do it, then we have created the conditions needed to solve todays top problems. Anything less will not suffice.


What? We surely cannot have people running around doing whatever they like?

Well, no. Sort of. Some very successful companies that seem to grasp the #1 principle is WL Gore, Morningstar, Semco and Valve. All of these would probably look quite chaotic to an outside observer. They all are managed though. We still need management, but in a different form. Some might call it Management 3.0.

What to do?

I have using the #1 principle a lot. With great results! So can you! Right today, in your current organization. Here are some things to try:

  • Involve the team members when creating new teams. Having a say in what team to work on and what products to work on makes a big difference.
  • For each new effort: align company goals, team goals and individual goals. Do a team kickoff session and ask people: “What would you like to learn, experience, achieve to make participating in this effort worth your time and full attention”.
  • Redesign work until everyone is driven by intrinsic motivation. Moving Motivators is one useful tool for working on that.
  • Clarify the boundaries of self-organization for your teams. I.e. by using a delegation board.
  • Study the Christopher Avery’s Responsibility Process. This is essential learning for everyone in a modern organization. People are not used to thinking about what they want  it seems! BTW I have a really funny and powerful 45 min session on this that I’d love to do for your whole organization 😉


So, I hope that you found some inspiration and some new thoughts above. If you also actually want to try some of these things I’d be really happy;-)

Will you?





Image: (c) Creative Commons, CC BY 2.0. Port of San Diego, Operation Clean Sweep 2013


The goal of a Scrum Master is NOT to make herself unneeded

Next week it is time for FIFA World Cup finals! With that, it is probably also time for a number of less successful football coaches to start looking for new jobs…

But as the disappointed countries ditch their old coaches, they will most probably hire a new one right away.

It seems that for elite teams and world class athletes, working with a coach is the default choice. In the software development business this is somewhat different.

Current misunderstandings

I keep hearing things like “The goal of a Scrum Master/coach is to make herself unneeded”  or “For a mature team, we can do with a part time Scrum Master/coach”. None of these make any sense to me.

I can understand where it is coming from though. I think it is since we have little historical experience in our business working with team- and organizational coaches.

People, including most newly assigned Scrum Masters, do not know what to expect from such a role. What value does it add?

Commonly this also leads to the Scrum Master role being implemented as some sort of mix between a meeting booking secretary and a command and control rule enforcer.

But that is completely not the point of having such person assisting a team and an organization!

The actual idea with Scrum Masters

What a Scrum Master/coach brings is another focus and another perspective. For example, it is very hard to be focusing on the details and on the big picture at the same time.

That is why pair programming gurus recommend that the “driver” focuses on the details and the “co-pilot” focuses on the big picture.

And it is the reason why the Scrum framework has different roles. To give each person fewer things to primarily focus on.

For example, deep in the code, you will also probably not be thinking about how to effectively reworking the organizational structures that are impeding innovation and thus slowly killing your organization.

That is one of the reasons that we have Scrum Master. They facilitate change and improvement. They do this since it is their primary focus.

Mature teams

But how about mature teams? For sure they could work well together without a Scrum Master?

Well, I have never seen anybody, regardless of skill level, successfully facilitating a meeting where they also tried to participate. With that approach, less great decisions will be made and team health will suffer in the long run.

And for the problem solving part? For a mature agile team the low hanging fruits have already been picked. The remaining issues are probably deep entrenched in individual habits and organizational culture. Big problems require even more time and focus. But when progress are being made, payback can be equally large!

And if you think that things are working fine in your team, remember: This does not mean that you have no problems, it just means that you are clueless…

What to do?

Should all organizations invest in a 100% Scrum Master for each team then? Or is it a 75% job, or a 50% job? Well that depends doesn’t it? It depends on how much value the Scrum master adds to the team and to the organization!

If the organization is able to produce significantly more value with some person being a full time Scrum Master for one team compared to with the same person splitting his time between two teams, then keeping that person focused on one team seems like a good idea, doesn’t it?

You will just have to evaluate this. Just as with all changes in the complex species that are our organizations, there are no one-size-fits-all recipes you can follow.

What organizations need to learn is not how to follow some “agile recipe”. Organizations need to learn how to learn. That is, how to come up with experiments and how to evaluate if those experiments improved things or not.

And if you happen to be a Scrum Master, to make this happen is your job! And it is a pretty challenging one. I’ve been at it for a while and it seems I’m nowhere near being fully trained for the job anytime soon…

If you are like me, and want to pick up the speed of your learning journey, there are lots of things you could do. Like reading some more books. Get yourself a coach. Attend some trainings. Visit a local user group. Do some more experiments at work. Learn in any way you like…and make sure that your role is a value adding position!

How would you do that?



Image: (c) 2014, A C Moraes, Creative Commons 2.0

There are no meetings in Scrum!

Well isn’t that great? Your team is now supposed to do Scrum and now there is another set of meetings cutting into the time you would rather use to actually get something done.

In popularity, “meetings” tend to be viewed as enjoyable as a dentist appointment. We have books like “death by meeting”, lean-gurus go on about meeting as waste, and yes, I have actually seen someone trying to schedule a dentist appointment just to get out of a sprint planning meeting 😉

Fine, except that there are no “meetings” in Scrum…

Scrum is a team based approach to solving complex problems. One of the basic ideas is that people together, with a variety of skills and views, can better solve such problems than each individual alone. This I am sure you know from experience. Even just describing your thinking to others often help.

So, the idea in Scrum is that it is useful if people work together in various ways all day long. How this is done, is mostly left up to people doing the work to decide.

Scrum does have some suggestions on how to spend a small bit of all that time that your team spends working together. Like planning what to do and how to work together on something and then evaluating the results after.

These are not meetings though. These are working sessions where each individual is fully focused on the collective task, participates every minute by learning or contributing and leaves feeling energized from new insights and happy from all the progress that was made in such a short time.

A very different session compared to what we usually call meetings. From all the meetings we all have had to endure, the word “meeting” is probably beyond saving, so maybe we should just stop using it.

For complex work, it is useful for people to work together. That does not make it a meeting. It is just people getting the job done together in the best way they can.

By the way, if you are doing some Scrum activities and they feel like traditional “meetings”, this is something for you to think about and improve. It is not mandatory to get bored and waste your time in Scrum. Quite the opposite. Perhaps once someone told you there was going to be a “meeting”, so you did set up a traditional meeting. This is understandable.

Well, now you know better, so just get your people together and figure out how to do it in a better way. In a way that builds your spirit instead of kills it!

Don’t settle for less.