Why Group Dynamics and Interpersonal Skills Matter

You think group dynamics and interpersonal skills are just fluffy stuff?

Wrong-o. They are an essential element of competitive advantage.

High-tech companies succeed by out learning and out innovating the competition. Group dynamics directly the affect the ability of a team to think, learn, and innovate together.

Groups that avoid conflict won't be able to face tough issues or handle the creative conflict that generates new ideas.

Groups that are highly competitive won't share ideas and build on other's ideas. People won't share the credit for success, further decreasing the chance for creative collaboration.

Groups that defer to a person of higher status will miss many good ideas, and fail to tap and develop the talents of the entire group.

Groups that haven't learned to work well together will take the first workable solution to avoid unsatisfying and uncomfortable interactions.

It takes more than smart people to succeed. It takes smart people who have the interpersonal skills for creative collaboration.

(If you want to learn and practice collaboration skills, come to Secrets of Agile Teamwork July 21-23, 2009 in Redmond, WA.)

Five Reasons to Hire a Coach for Agile Teams

I run into managers who think that they can coach the team as the team adopts Agile methods. In my experience, this usually doesn't work out very well.

So managers, support the team as they learn Agile methods by hiring a coach! It's a investment in success.

Here are five reasons that coach cannot be you.

1. The team needs someone skilled in XP engineering practices and current on the latest testing tools. If you haven't written code in more than three years, or you've never worked on a team that used all the XP practices you don't have the knowledge to coach the team. Sorry. Doesn't make you a bad person or cancel out your value to the organization. Does mean you are not the right person to coach on XP.

2. You may have a conflict of interest. If you are being measured on delivery dates, its possible that you'll ask the team to cut corners, work extra hours, or drop practices to meet a date. That would be bad. The team needs someone who will hold the process in place and help them hold firm when someone is worried about making a date. That can't be you, if you're the one worried about making the date.

Even if you'd never do that, on some level, the team may not believe that yet, especially if you've ever done so in the past. And if they think you'll cave in the face of a date, they'll cave before you even ask them to. It just works that way.

3. A coach will help the team stick to the process, and guide them away from making adjustments that nibble away at iterative incremental development until they are back in a mini-waterfall.

Agile really does involve a shift in the mental model of software development, and until you have an intuitive grasp of the principles and values, the nibbles will make sense to you, too. You've got to live it for a while before you can coach it.

4. As long as you are there to solve problems and tell people what to do, it will be easy for the team to remain dependent on you. It may feel good to be needed, but in the long run, it doesn't help the team, doesn't help the company, and doesn't help you.

5. You've got a ton of other stuff to do supporting the team, removing obstacles, running organizational interference, and working on the work system. Plus you have to do the budget.

Of course, you don't have to be dependent on outside coaches forever. Once you've established a few Agile teams, you can develop a cadre of coaches made up of your own experienced people.

When to stand back, when to step in

Part of my definition of a successful team is that the members of the team increase their knowledge and capacity as a result of their work on the team. That means that giving the team the opportunity to learn is part of the job.

One of challenges I see when managers first start working with agile teams is knowing when to step back, and when to step in. Swinging too far in either direction hampers team learning.

Helicopter Managers step in too soon. They swoop in at the first whiff of a problem to "rescue" the team. They deprive the team of the chance to think, solve problems, and decide together. These managers may believe they are doing the team a favor; what they really do is hamper the team's development.

Absentee Managers throw up their hands and say "you figure it out," no matter what the issue, or whether the team has the skill and authority to solve the problem. These mangers let the team flail and churn, wasting time and building frustration. People do learn from mistakes; but when people feel frustrated, hopeless or abandoned by their manager, increased capability is not the likely learning outcome.

Self-organizing teams still need managers. But those manager need to know when to step in, and when to stand back.

Here are three guidelines to help managers gauge their actions with self-organizing teams.

#1. If the team has the skills to solve the problem--or they are on the verge of having the skills--give them space to solve the problem. If they're stuck or don't see how to use the skills they have, ask questions to help them get unstuck. They will learn much more from wrestling with the problem than having the manager fix it. (Assuming it's not a management problem. Then it's managements job to fix it.)

#2. When time is not of the essence give the team time to work the issue. If it takes a day or two to solve the problem, will it bring the company to it's knees? (If the answer is yes, you've got bigger problems than working with a self-organizing teams.) Keep in mind that many companies live in permanent fire-fighting mode and believe that everything is urgent. Or the manager believe that people won't actually apply sufficient effort unless they believe the issue is urgent. Again, that's a bigger problem. OTOH, if there's information that will help the team solve the problem give the information. Withholding the information is just plain wrong. Likewise, if there's a very simple solution that the team is overlooking, ask questions to help them discover it.

#3. If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time. If the solution space isn't bounded, then there's something amiss with the way the problem or decision authority has been delegated. Bound the issue so that the team is involved and there's appropriate fiscal and management oversight.

There's always a trade off between expediency and a learning opportunity. Self-organizing teams can outperform manager-let teams....but only if the managers are willing to navigate the balance.

Shifting from a manager-led team to a self-organizing team is a little tricky. It calls on a different set of skills, and brings up questions about value and identify for many managers.

But there's still plenty of work for managers to do. It just doesn't involve task management and having all the answers.

The Benefits of Peer Feedback

Peer feedback is a core skill for collaboration. It's impossible to work closely with out running into some bumps: differences, disappointments, and disagreements. Peer to peer feedback can help keep working relationships on track and improve results (and it keeps the manager out of the transaction so it doesn't be come a *big deal*).

I teach about feedback in both my team collaboration workshop and management workshops. "But does it work in the real world?" some ask. Ola Ellnestam blogs How I Learned about Feedback.

Five Ways that Team Members Build Trust with Each Other

Building trust may seem mysterious... something that just happens, or grows through some unknowable process. Like many things, there are concrete actions that tend to build trust (and concrete actions that are almost guaranteed to break trust down).

First, a definition of trust in the workplace. We all know that trust is the foundation for teamwork. But to hear some people talk about it, you'd think team members were getting married, not creating software together. What we need in the workplace is professional trust. Professional trust says, I trust that you are competent to do the work, that you'll share relevant information, and that you have good intentions towards the team. Taken broadly, that's trust about communication, commitment, and competence.

1. Address issues directly

It's inevitable that some person on the team will rub another person on the team the wrong way. Maybe it's they way he cracks his gum, or listens to voice mail on speaker phone. Maybe it's using your laptop and changing all the preferences. Maybe it's breaking the build and then leaving for lunch.

These frictions are inevitable. When a team member speaks directly to the person who is bugging him, he builds trust. Raising an issue says, "I value our working relationship, and I'm willing to have an uncomfortable conversation to make it better." It says, "You'll know where you stand with me; I won't be talking behind your back."

These conversations aren't always easy. Sometimes people delay the uncomfortable discussion until the situation becomes intolerable, letting anger and resentment build.

Sometimes people try to avoid the difficult conversation by telling their manger about the problem. And sometimes the manager falls into the trap of carrying the message. Seth had just started a new job and hadn't really made friends with anyone on the team yet, so he spent is lunch hour alone. On his second week on the job, his new manager called him in to inform him that another team member resented the amount of time he was taking for lunch, since 45 minutes was the unspoken rule.

(I do wonder why no one bothered to tell Seth this, and why no one invited him for lunch in his first week on the job, but that's another issue.)

When his coworker talked to the manager instead of talking directly to Seth, he broke
trust. When I talked to Seth, he'd been at that job for over a year, and still didn't fully trust his coworker. No one likes a tattle tale.

When people don't know how to have difficult conversations...or think it's not their job to navigate working relationship, trust erodes. And that's why people need a framework to talk about interpersonal feedback.

2. Share Relevant Information

If you don't support an idea or approach, say so. (Of course, there are more effective and less effective ways to do this.)

When someone on the team withholds and opinion or concern when a topic is under discussion and then comes back later to say "I thought it was a bad idea from the start," other team members feel blindsided. That breaks trust.

Relevant information is about the task, but it's also about you. People tend to trust people they know as individuals and can identify with. Shared experience, shared interests and identification form solid ground that people can land on when there is friction and conflict. You don't have to share your deepest secrets, but letting other people on the team know something about life outside work makes people "real." It's hard to trust a cipher; much easier to trust and be generous with someone who shares some of the same challenges and interests that you do.

In order for teams to function, team members need to believe that their co-workers are reliable. Without the confidence that others are reliable and will carry their share of the load, few will commit to a shared goal.

3. Follow Through on Commitments or Give Early Notice When You Can't

No reasonable person expects that every person can meet every commitment all the time. We know that sometimes a piece of code turns out to be more complex than anticipated or we discover we didn't fully understand the task when we made our estimate. But when you wait until the moment the task was due to let people know it's going to be late, it breaks trust. So let people know as soon as you know, and renegotiate.

4. Say No When You Mean No

Sometimes you just can't take on another task, or do a favor that someone asks for.
But most of us are programmed from an early age to please other people. If we say no, we're called selfish or "not a team player." But if you really can't do what's asked, it's more respectful to say No and let the other person get on with getting his need met elsewhere.

Saying Yes without follow-through leads others to doubt your word. If you can't say No, your Yes won't mean anything.

It may seem paradoxical, but building competence trust sometimes means admitting that you don't have all the answers.

5. Show What You Know and What You Don't Know.

Be generous in sharing your knowledge (without inflicting help). But also be willing to hear other peoples ideas, build on them, and help others shine. Admit when you don't know the answers; there's nothing worse than a know-it-all who is wrong. Ask for help. That helps other see you as a real person, and people generally like to be helpful.

Three Myths about Teams

Myth #1: All a team needs to get them working well together is a clear goal and sufficient pressure to perform. I’ve never seen a team without a clear and compelling goal gel; but I’ve seen plenty of teams who did have a clear goal flail and fail. Until a group of people decides to work as a team and decides to agree, they won’t function well as a team.

Myth #2: A manager can discern individual contributions to team results. While a manager can tell certain things about the way a team is functioning, in most cases, it’s impossible to tease out individual contribution. And when managers try to assess who has made the biggest contributions, they are often wrong. Taking action on an incorrect assessment can have devastating effects on the team, and makes the manager look foolish.

Myth #3: If the team isn’t struggling or working long hours they aren’t working hard. Teams that are working well together make the work look easy. They work at a purposeful, yet relaxed pace. They even look like they are having fun.

system blindness

One of the big problems I see in organizations is that managers who want to improve productivity pull the wrong levers.

For example, one company I know of decided to improve performance by ranking everyone in the company from 1...n, and firing the bottom 10%. Not surprisingly (to me at least), performance didn't get better. But the managers were surprised (when they noticed at all).

Individual performance is important, but it's often not the primary lever to improve organizational performance--it's the work system that needs improvement.

In the company that tried ranking to improve performance, there was no clear product direction, priorities shifted weekly, and teams where broken and reformed every few months. Improving any of those factors would have had a much bigger over all improvement effect than forced ranking and culling.

We like to believe that people succeed or fail by their own efforts. I don't discount individual effort....but focusing only on individual effort blinds us to system effects.

Applying "the simplest thing that could possibly work" principle

What problem are organizations trying to solve with incentive pay?

Is an incentive plan the simplest, most effective way to address the problem?

Most managers believe that incentive pay plans encourage the desired behavior, drive performance improvement, and reward (individual) achievement. That may be the case, with certain kinds of work.

But before looking to incentive pay to improve performance, look at the work system.

What are the organizational impediments that might be preventing desired performance?

What else might be preventing people from achieving the desired results?

Do people have a clear understanding of how their work contributes to the bottom line and the companies mission?

Do people have a clear expectation of what's expected of them day-to-day?

Do people have the tools to perform?

Do they have the skills?

Are they receiving feedback from the system and from their peers and managers?

Will individual incentives actually encourage the behavior the organization says it wants?

Will the side effects of incentive pay help or hinder the organization?

These questions need to precede the decision to use incentive pay to drive behavior and results.

As Ann Bares, writing for Workforce.com says,

Much as our management "customers" might like to believe the contrary, incentives are not a sound substitute for an effective organizational structure, good management practices or clear and regular communication.

So work on improving the system and managing well before looking to incentive pay to improve performance and results. That's the simplest thing to do. Plus, for interdependent work, incentive pay is likely the wrong level to pull.

Read Ann Bares' full article here (requires free registration).

Self-organizing Teams Interview

Bas de Baar and I had a little video chat about self-organizing teams a couple of weeks ago. Video is here. (Thanks to Andres and George for pointing out the empty link.)

A Poor Performer?

Mark Levison has an interesting post in response to a Scrum Development discussion about "bad apples" on a team.

Before applying the label, look for reasons the person might not be performing. There are lots of reasons for a temporary dip in performance. Or, it might be a problem with the tools available, or the environment. It's very common to attribute problems with the system to the individuals (and vice versa).

Our own prejudices can get in the way. My friend Jerry tells a story about when he was a grader for a college course. His job was to read essays and grade them based on criteria. When he turned the grades over to the professor, the professor challenged one of the grades, an A. "You can't give this person and A," he said, "he's a C student."

Mark offers a quote from Linda Rising:

"In many cases, a supervisor “determines” the ability of a worker in about three weeks, labelling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice."

Mark advises:

So before we rush off to action on poor performers:

Stop, let go of preconceptions
Re-examine the person's role on the team
Listen/Watch - don't measure
Only if there is a problem - then solve it.

I agree.

Also see:

George Dinwiddie's Working Hard or Hardly Working, and my response.

and...
When is it time to move someone off the team?

A Conversation with Glen Alleman

'twas the night before Christmas, and all through the house, not a creature was stirring, not even a mouse...

But Glen Alleman and I were chatting via his blog about the difference between self-organizing and self-directed teams, and how failing to recognize the difference gets people in trouble from time to time.

A (slightly) edited form of the conversation:

Esther: I'd agree that self-organizing teams are not the same as self-directed teams. I specifically reference self-organizing teams, not self-directed teams. Self-organizing teams exist within an organization context and serve the needs of that organization.

I agree there is still a strong role for management in organizations that have self-organizing teams.

Glen: My experience has been whenever the term "self organizing team" is used it is taken to be "self directed." In the absence of a specific statement about the differences in the first sentence of any article the listener jumps to the end with "we're going to run our team in the absence of management." The next step is usually the cancellation of the project ;>)

Esther: As often as I see teams reject guidance from management "because we are self-organizing," I see *managers* abdicate any responsibility to the team or for the team. Neither stance is very productive.

But it does take both managers and team members time to figure out new roles and how to work in a new relationship. That's part of the reason I wrote the article.

Glen: It does take both side of the "team" to understand their individual and combined roles.

I've moved back into defense system for many reasons, but one is the continuous questioning of "how can this benefit the program as a whole - the entire business operation?" Management in this environment are the leaders of the subject matter experts, rather than the "supervisors" of the labor. We are working managers, rather than observers.

The article provides a wonderful starting point for the conversation about how each role contributes to the successful completion of the project.

###

My entire article (referenced earlier in this blog) seems not to be online right now :-(

Team Renewal

Jim Sowers asked for more information on team renewal.

Here are some reasons teams need renewal.

Over time, work that was initially a challenging learning experience becomes routine.

Life circumstances change and some team members need to focus their energy in a different direction.

Team membership changes.

The team may complete their initial goal.

When there are challenging interpersonal relationships on the team, people may get tired of putting that much emotional energy into the workplace.

The action you take depends on what's going on for the team.

It may be time to celebrate past accomplishments, aknowledge contributions and then disband the team.

There may be an opening to re-examime the work the team is doing, and find a new challenging project for the team to work on.

The team may need to reexamine their reasons for continuing as a team or continuing with the work.

Sometimes, for various reasons, its just time for individual team members to move on...so recognize, celebrate and then find a new team member (if necessary) and reform the team (because it will be a new team in many ways).

Some sort of periodic reflection (a retrospective!) is a good way to address on-going commitement before team members get bored or burn out....maybe on a half-year or yearly cycle depending on the work, and with an explict focus of doing a check-in on engagement.

Magic Chemistry of Teams

George Dinwiddie has posted his notes from one of my AYE 2008 sessions, Magic Chemistry of Teams.

During the session, I asked people to draw a time line that represented their experiences working on teams, then, working in small groups, identify the factors that were present on high-point teams and low point teams.

Here's a partial list of factors present on low-point teams (posted on George's site):

no vision
bad results around us
bad fit of skills & interests
alone
angry boss/poisonous environment
no common location
lack of appropriate tools & equipment
specialization
One Jerk/personal conflict
lack of respect amongst team members
absent leader
lack of face-to-face contact
lack of clear priorities
judgemental leader
loss of team members
blame/shame
team too big

Notice how many items on this list relate to how the team is established: vision, location, skills fit, priorities, tools and equipment, team size. These are all within management's responsibility.

If there is a clear vision, clear priorities, necessary physical environment, the right number of people with the right skills, then it's more likely that the items on the "high point" list will emerge:

common goals
clear goal/vision
clear role/expectations
new/novel/learning
presence of great skill
self-organizing
ritual
team members value each other
good humor
ate together
camaraderie
appreciation
recognition
trust
passion
friendship
flow

Too often, managers throw a group of people together and declare it a team. Calling a group a team doesn't make it so. It takes work to establish an environment where team work will emerge.

(It takes collaboration skills on the part of team members, too, as in Secrets of Agile Teamwork, coming up in February.)

Found Treasures

I was at a friends house this morning and picked up a book she had out as she worked on a course. As I flipped through the pages, it look sort of familiar, and when I came home I found it on my bookshelf.

More than 50 Ways to Build Team Consensus (R. Bruce Williams) is chock full of activities that teams can do to clarify their vision and goals, build commitment to task accomplishment, engage participation. (I have the 1996 paperback edition. Don't remember how much I paid, but it was less than the price quoted on amazon.)

I wouldn't do all of the activities (I'd skip the team song, for example); but if you work with a team and are looking for some ideas on how to get people on-the-same-page, talking, and engaged you'll find some helpful ideas.

What trust means for teams

It’s a truism that trust is the foundation of teamwork.

But trust is a big word. What do we really mean when we talk about trust?

First, trust exists within a context. The sort of trust that you need for a productive working relationship is different from the trust you need for a healthy marriage. And it’s certainly different from the trust you need on a ropes course (which is why that sort of team building activity seldom has much effect).

What you need for productive working relationships is trust that says:

I believe you are competent to do the work

I believe that if you have an issue with me, you’ll bring it up directly

with me, not talk behind my back.

I believe will follow through on commitments—or let me know when you need

to renegotiate.

I believe you have good intentions towards me and the team.

And there’s a prerequisite for trust: a person needs to have a capacity for trust.

When is it time to move someone off a team?

When I talk to teams about self-organizing, people worry about what to do when some one on the team isn't working out.

If we're a team, they posit, we have to work things out so we can work together. Not necessarily so.

Teams need to manage team membership so that they can achieve their goals. There are times when teams can work things out to work together. And there are times when someone needs to go.

I see four common reasons to move to move someone off a team.

When a team member doesn't have the skills needed to do the work and can't (or won't) learn them in the timeframe needed by the team and the business. This can happen because of a hiring mistake, when the company moves to a new technology, or when the focus shifts from one type of work to another (e.g., from manual functional through the GUI testing to automated testing through APIs).

This is really hard when it's someone who has contributed and now can't make the learning curve. If there's no other way for the person to contribute, it's time to move him off the team. In the long run, though, allowing the situation to continue doesn't do anyone favors. The team may start to resent the non-contributing team member. The non-contributing team member doesn't have the satisfaction of pride in work and making a contribution. Everyone suffers.

When someone can't or won't work collaboratively. For example, when a person focuses on completing his tasks at the expense of completing the team's iteration goal, or the rest of the team agrees to share code-ownership and he refuses to relinquish control over "his" code. Or when an individual doesn't communicate with other people on the team.

On a team with interdependent goals, having a member who refuses to collaborate (for what ever reason) makes it harder for everyone to do their work. It also creates a dynamic where team members focus time and energy on the behavior of one team member rather than on building working software. It's futile to try to convince someone to work collaboratively when he doesn't value collaboration.

When the person challenges efforts to move forward that aren't perfectly aligned with his ideas. Sometimes an individual sees risks in an option and has a hard time talking about it in a helpful way. Usually this comes as "that will never work here," or "we tried that and it didn't work". This is irritating; AND there's often useful information behind the objection--when you tease it out. (And you can coach the person to modify their style.)

On the other hand, some people challenge efforts to move on a philosophical basis--they call into question whatever the team proposes on the basis of an abstract notion of how-things-should-be. It's really easy to get hooked on the content and get sucked into discussions about why some action is or isn't pure and correct.

There is a place for "devils advocating" and vetting actions against fundamental values. That's an important function on any team and I'm not talking about eliminating it. However, when one member has a pattern of challenging efforts to move forward, not letting go, and killing new ideas with criticism, its a problem. Especially when the challenge shifts to meet each new proposed avenue of progress that doesn't meet the purity test.

When someone has a fundamentally different vision of where the team should go. A few years ago, I was traveling from Amsterdam to Copenhagen by rail. My route required that I change trains twice. As I settled in to my seat after the first train change, a nice German woman asked me where I was going. "Copenhagen," I replied. "Oh, no, my dear," she said, "you are going to Berlin." I guess I could have argued, but instead I got off at the next station, back tracked, and got myself onto the train that was going to where I wanted to go.

It's like that sometimes with teams. Most of the team wants to go in one direction, and one individual wants to go in a dramatically different direction. And he argues for that direction, well after the majority of the team has expressed their commitment to go another way. The team spends lots of time trying to convince the one person, and that person spends a lot of time trying to convince the team. At a certain point, it's time to say, "This is where we are going. We want you to come with us. If it doesn't fit for you, we understand. And you'll need to go your own way." Early in the life of a self-organizing team, the coach may have this conversation. Some teams reach the point where they have the conversation amongst themselves.

There's a risk that the individual has the right of it, and the team is headed in the wrong direction. But if the team makes some movement, they are likely to discover that, and then they can make corrections. As long as the argument continues, no one is moving at all.

Excluding some one from a team is difficult. Most of us want to feel included and part of the group. That's a potent trigger for most of us. Some people feel overwhelming anxiety over excluding someone from the team. For others the need to belong is equally overwhelming. Helping someone move off a team is seldom easy. And when it's done--and handled with respect and caring for the person who is leaving the team--it's doesn't have to be a traumatic event for anyone.