This is a recent writing of mine in the Cutter eAdvisor that might be of interest to everyone:
Agile development yields productivity gains. Teams of developers,
managing their own work in collocated spaces, outperform externally
managed developers sitting in cubicles or offices. These teams are at
least twice as productive. This productivity is coupled with other
benefits, such as more creativity in deriving solutions to problems,
higher quality by cross-checking each other's work, and better
morale through socialization.
All of these benefits have seemed to be free: put the teams together,
get their commitment to a goal, and have them work within a time-box.
But what has been lost by taking the team members out of their
individual offices? What has been lost by asking them to manage
themselves as a team? Conflict! Unsurprisingly, it turns out that
collocated teams working under commitments and deadlines
often have different values and opinions about the best way to
accomplish their work. They sometimes come to work in a less
than collaborative mood, resembling Attila the Hun rather than
Tom the adult who happens to be a programmer.
Conflict is inevitable. However, nothing in the Agile vocabulary says
what to do when conflict occurs. To date, we've all been willing to take
the benefits without anticipating this cost. No wonder, for who likes
to deal with conflict?
I was at a client recently when a conflict occurred. An analyst was
upset that a programmer had taken liberty with an agreed-upon design
without first consulting the analyst. The programmer felt that the
change was so minor that he was well within his rights to go ahead
with it. The analyst felt that the programmer had been disrespectful
of her work and responsibilities. The result was raised voices, frayed
nerves, and spilled tears. Other members of the team tried to
mediate, to soothe the conflict, to no avail. The conflict ended with
both of the participants fleeing the team room to a private space
where they could get away from the other, lick their wounds, and
recover emotionally. Both the programmer and the analyst were
torn between feeling they were right and being embarrassed that
they had openly fought in front of the others, and they didn't know
what to do.
I am by no means trained in resolving conflict. When I entered the
team room, everyone kept their eyes on their workstations. They
were upset by what had happened. I felt that we had to talk about
this, so we gathered together and shared how the team members
felt. They all felt embarrassed that they had witnessed the conflict.
They also felt bad that they couldn't have helped those having the
conflict to resolve it, or to avoid it. They were agitated and worried
that this would upset the entire team, and they didn't know what to
do to resolve the problem.
We decided together that we couldn't ignore the conflict. Leaving the
bad feelings unaddressed would create a poisonous atmosphere
in what before had been an easy and collegial atmosphere. Worse
yet, we all acknowledged that if many more unresolved conflicts
occurred, the team might not be able to work together. So we
forged the following guidelines:
1) We accepted that conflict is a natural event when people work
together.
2) We determined that when a conflict occurs, no work will continue
until the conflict is resolved -- no sweeping conflict under the carpet.
3) We decided that the first thing we would do to resolve the conflict
would be for everyone in the team to describe how they feel (this
wasn't easy at first, as team members mistook analysis of the situation
with feelings).
4) Everyone would work together on a solution. We hypothesized
that if no solution was forthcoming, it was probably because emotion
was still clouding our thinking, so we would go through steps 3
and 4 in a loop until the solution was derived and everyone was
able to report that they were feeling ok.
I'm not a conflict resolution specialist, so I recommended to the
organization's management that they bring in a specialist to work
with each team. The specialist would teach the teams ways to resolve
conflict in a way that could handle more types of conflict than the
team and I had dealt with.
When I implement Agile processes, I sometimes help the organization
develop rules of conduct or etiquette. Sometimes I do this because
ill-will already exists and I don't want it exacerbated. Other times I
help build the rules because I feel that the people are truly at a loss
on how to get along; sometimes this is because of different cultural
perspectives, sometimes it is simply because they have spent so much
time working alone that they have forgotten, or never knew, how to
work in teams.
Some of the rules we've devised are:
1. Never use the word "you" because the other person may feel on
the spot and defensive.
2. Never refer to history (e.g., "three months ago, you said...!").
3. Be on time for meetings; if you are late, apologize and pay a
late "penalty."
4. If everyone is talking at once, use a pen to determine who talks.
Whoever is holding the pen talks, everyone else listens.
5. Everyone's opinion is important and needs to be understood and
taken into account.
6. No name calling.
In retrospect, I'm surprised that I didn't foresee this cost to team work.
The team members had previously been kept in relatively conflict-free
situations, with management responsible for resolving anything that
came up. Now it was up to the teams.
managing their own work in collocated spaces, outperform externally
managed developers sitting in cubicles or offices. These teams are at
least twice as productive. This productivity is coupled with other
benefits, such as more creativity in deriving solutions to problems,
higher quality by cross-checking each other's work, and better
morale through socialization.
All of these benefits have seemed to be free: put the teams together,
get their commitment to a goal, and have them work within a time-box.
But what has been lost by taking the team members out of their
individual offices? What has been lost by asking them to manage
themselves as a team? Conflict! Unsurprisingly, it turns out that
collocated teams working under commitments and deadlines
often have different values and opinions about the best way to
accomplish their work. They sometimes come to work in a less
than collaborative mood, resembling Attila the Hun rather than
Tom the adult who happens to be a programmer.
Conflict is inevitable. However, nothing in the Agile vocabulary says
what to do when conflict occurs. To date, we've all been willing to take
the benefits without anticipating this cost. No wonder, for who likes
to deal with conflict?
I was at a client recently when a conflict occurred. An analyst was
upset that a programmer had taken liberty with an agreed-upon design
without first consulting the analyst. The programmer felt that the
change was so minor that he was well within his rights to go ahead
with it. The analyst felt that the programmer had been disrespectful
of her work and responsibilities. The result was raised voices, frayed
nerves, and spilled tears. Other members of the team tried to
mediate, to soothe the conflict, to no avail. The conflict ended with
both of the participants fleeing the team room to a private space
where they could get away from the other, lick their wounds, and
recover emotionally. Both the programmer and the analyst were
torn between feeling they were right and being embarrassed that
they had openly fought in front of the others, and they didn't know
what to do.
I am by no means trained in resolving conflict. When I entered the
team room, everyone kept their eyes on their workstations. They
were upset by what had happened. I felt that we had to talk about
this, so we gathered together and shared how the team members
felt. They all felt embarrassed that they had witnessed the conflict.
They also felt bad that they couldn't have helped those having the
conflict to resolve it, or to avoid it. They were agitated and worried
that this would upset the entire team, and they didn't know what to
do to resolve the problem.
We decided together that we couldn't ignore the conflict. Leaving the
bad feelings unaddressed would create a poisonous atmosphere
in what before had been an easy and collegial atmosphere. Worse
yet, we all acknowledged that if many more unresolved conflicts
occurred, the team might not be able to work together. So we
forged the following guidelines:
1) We accepted that conflict is a natural event when people work
together.
2) We determined that when a conflict occurs, no work will continue
until the conflict is resolved -- no sweeping conflict under the carpet.
3) We decided that the first thing we would do to resolve the conflict
would be for everyone in the team to describe how they feel (this
wasn't easy at first, as team members mistook analysis of the situation
with feelings).
4) Everyone would work together on a solution. We hypothesized
that if no solution was forthcoming, it was probably because emotion
was still clouding our thinking, so we would go through steps 3
and 4 in a loop until the solution was derived and everyone was
able to report that they were feeling ok.
I'm not a conflict resolution specialist, so I recommended to the
organization's management that they bring in a specialist to work
with each team. The specialist would teach the teams ways to resolve
conflict in a way that could handle more types of conflict than the
team and I had dealt with.
When I implement Agile processes, I sometimes help the organization
develop rules of conduct or etiquette. Sometimes I do this because
ill-will already exists and I don't want it exacerbated. Other times I
help build the rules because I feel that the people are truly at a loss
on how to get along; sometimes this is because of different cultural
perspectives, sometimes it is simply because they have spent so much
time working alone that they have forgotten, or never knew, how to
work in teams.
Some of the rules we've devised are:
1. Never use the word "you" because the other person may feel on
the spot and defensive.
2. Never refer to history (e.g., "three months ago, you said...!").
3. Be on time for meetings; if you are late, apologize and pay a
late "penalty."
4. If everyone is talking at once, use a pen to determine who talks.
Whoever is holding the pen talks, everyone else listens.
5. Everyone's opinion is important and needs to be understood and
taken into account.
6. No name calling.
In retrospect, I'm surprised that I didn't foresee this cost to team work.
The team members had previously been kept in relatively conflict-free
situations, with management responsible for resolving anything that
came up. Now it was up to the teams.
To Post a message, send it to: scrumdevelopment@eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@eGroups.com
Offline 
Send Email