Tag: teams

Giving Feedback – A Worse Than Useless Idea

Posted on by berglundhenrik

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…;-)

Henrik Signature

The #1 rule of agile management

Posted on by berglundhenrik

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!

Why?

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.

People

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.

Products

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.

Competition

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.

Chaos?

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?

signature

 

 

 

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

Cake-mix and improving life at work

Posted on by berglundhenrik

In the early 1950’s, cake mix was introduced in the U.S. Take some mix, add water, and put it in the oven. In ten minutes you had a homemade cake. Great idea, right?

It wasn’t. Really bad idea actually. Huge failure!

Until one of the vendors figured out what the problem was, took action accordingly and left their competition behind in the dust, wondering what happened.

So what happened, and why should you as a software development professional care about that?

What they figured out was that the original mixes made it too easy. Housewives of that time took great pride in their occupation. Clearly, just adding water would simply just not qualify as baking a homemade cake.

The solution was to have the housewives add a fresh egg to the mix. Fiddling around with an egg was messy enough that the housewives now felt like they contributed to the baking. Now this was something that they could serve as homemade!

And it works the same way with ideas! If you have some great improvement idea you would like to promote, you need to make sure that everyone affected by your idea will have the chance to contribute something to the mix! Then it will be their idea also, not only yours.

So, if you have worked out a brilliant solution to some problem, don’t tell your co-workers! Instead, ask everyone involved to join you, working on solving the problem. Carefully facilitate the meeting so that everyone gets to contribute their thoughts, and see what the group comes up with. (I’ll be writing more about how to do that in another blog shortly.)

But, what if the group discussion results in a solution that is not as good as one you have already worked out? Well, one advantage is that the group solution may actually get implemented. And that’s a start! In contrast, the chance that a prepackaged solution, offered by you, is sustainably implemented is very close to 0.

Also, often when I do this, I’m surprised to see that the solution crafted by the group is actually better than mine…but maybe that’s just me 😉

Wait! Someone says, maybe it was that adding the egg to the mix actually did make the cake taste better? Well, I have further proof for you skeptics, and I might do another blog on that later. But the only way to truly learn something is to try it out yourself, so next time your about to sell some new solution to your team, just consider that this may be true:

People do not like other people’s ideas, they like their own ideas!

Change your tactics accordingly and just see what happens…

-Henrik

Credit to Gerald Weinberg, in whose fine book “The Secrets of Consulting” I first learnt about this idea.

Who’s got the power?

Posted on by berglundhenrik

Who has got the most power over your team? Is it your manager, or perhaps your local tech guru?

Well…probably not! Not if you picked a reasonably motivated individual anyway…

According to team building expert Christopher Avery, the most powerful member of a team is the least motivated person!

Really? How can that be?

Easy…low motivation is more contagious than high motivation. Nobody likes to carry the weight of a slacker! Thus, slackers tend to drag their complete teams down to a similar low level of performance!

Interesting, but if we have an attractive bonus system and decent salaries, that will make sure everyone is motivated, right?

Well…take a look at this story, slightly modified from the version told by Alfie Kohn in his book “Punished by rewards”:

“An old man had some problems with the local kids. Every day they used to stop by and taunt him, throwing stuff at his house and calling him names. Luckily, the man used to be developer on an agile software development team in his youth. Using what he learnt about the human psyche in the old days, he came up with a plan:

The next day when the kids stopped by to taunt him, the man offered them each a dollar for coming back the next day to taunt him some more. The kids accepted his offer and came back the next day. When they did, the man offered them 50 cents each to come back again the next day. The kids grumbled a bit, but came back the next day to deliver some more abuse. When they did, the man again offered them some money to keep coming back, but now he only offered them ten cents each. The kids were really dissatisfied with this offer and never came back.”

By introducing a reward for something the kids enjoyed doing for free, he was able to take away their intrinsic motivation and make them stop.

Wow…we probably should take some care so that we don’t accidentally do that! But what does work then?

In his article “One more time: How do you motivate employees?”, Frederick Herzberg reveals some related research results: The factors that cause job dissatisfaction are not the same factors that cause job satisfaction. E.g. salaries can cause dissatisfaction, but never extreme satisfaction. On the other hand “achievement”, “work itself”, “growth”, and “recognition” are all factors, “Motivators”, that can cause extreme job satisfaction.

This sounds familiar…pride in work, right to do quality work, focus on learning and personal growth are some of the “Motivators” that are right there at the core of agile development. And according to surveys like the annual VersionOne, “The State of Agile Development”, agile teams really do enjoy work more than other teams. But still, everyone is different. How can we make sure that each and every member in our teams is motivated?

Christopher Avery again has some insights. In his book “Teamwork is an individual skill”, he proposes that each team should have 5 conversations to enable high performance teamwork. One of these conversations is “aligning interests”, i.e. figure out what motivation each individual has to contribute his full potential to the team. Keep finding ways to rearrange work until everybody has similar motivation. He also offers a breakthrough technique to figure out what motivates each individual: Just ask!

So, who’s got the power on your team? How about just asking?

– Henrik

Co-located teams

Posted on by berglundhenrik

One of the best ways to get started with an effort to get more agile is to co-locate teams, creating “war-rooms” for them to work in. Studies like this show that co-locating teams at least doubles productivity. In the study above, the teams that used the new facilities after the study was finished actually did even better, doubling their productivity again, performing four times better than the company baseline. Also, both the teams and their sponsors were in general very satisfied with the experience.

How can such a large improvement be possible? Being co-located makes very high bandwidth communication possible, enhances learning and supports creating teams that really jell together. Remember, the bottleneck in software development is learning and the best work is carried out by small self organizing teams.

In the research on co-locating there are also some really interesting findings on what happens when people are not “at hand”. Communication drops of significantly it seems, right when people are first out of sight. Being 30 meters apart is essentially the same as being truly remote. One would think that use of email, phone calls, and video conferences would make up for distance in today’s high tech workspace, but in practice this is not so. Professor Thomas J. Allen puts explains it like this: “We do not keep separate sets of people, some of which we communicate in one medium and some by another. The more often we see someone face-to-face, the more likely it is that we will telephone the person or communicate in some other medium.”

So, if you feel up to trying out some co-located teams, here are a few tips:

  • Provide facilities for teams to work in, but don’t co-locate a team until they request this. Remember, the basic rule for all change is that it does not happen unless everyone involved individually takes the decision that the new way working is of direct personal benefit to them.
  • People may feel that giving up a private office for co-located space is a loss of status. To handle this, a co-located space must be made an attractive option. Working in a well designed space like this should be made feel like a privilege, not as a cheap alternative to offices. So use your best spaces and don’t crowd them. Provide windows, air, plants and lots of first class work equipment like whiteboards and computers.
  • Have just one team (i.e. ideally < 10 people) in each room. Agile teams get noisy and that is the way it should be. Provide noise isolation to prevent disturbing other teams/persons.
  • Supply adjectant conference rooms for meetings and hotelling cubicles for work away from team, making private calls etc.
  • Make sure desks support pair programming by having space for two people working side by side, shifting keyboard back and forth.
  • Encourage each team to write down and maintain its own set of rules on how to work together. This could include work hours, handling phone calls outside of war-room, no speaker phones, phones on vibrator mode, which type of discussions to hold in the war room and which should be taken to conference rooms, signals for indicating that a person wants some privacy etc
  • When co-locating and shifting focus from individual work to teamwork, remember to also update your performance evaluation systems. Bonus goals and other performance metrics need to be measured at team level (or in general, one organizational level up) to prevent sub-optimisation.

So, get right to it and tear down those office walls now…for people working in solitude refining the latest statistics on the wheat production in the EU, offices may be great. For software development it is simply not good enough anymore…

– Henrik