Loading ...
Sorry, an error occurred while loading the content.
 

RE: Réf. : [scrumdevelopment] Recent Advisor

Expand Messages
  • Mike Dwyer
    Peer pressure is, of course, part of the process as is ego and pride. It has been my experience the personal issues are kept in check with the formation of a
    Message 1 of 2 , Aug 3, 2004

      Peer pressure is, of course, part of the process as is ego and pride.  It has been my experience the personal issues are kept in check with the formation of a team and a reminder to the SCRUM Masters that friendship has nothing to do with teamwork.

       

      However, on our SCRUMs the most important components are humor, valuing the individual’s contribution to the team, and respect for the customer’s situation.

       

      -----------------------------------------

      Mike Dwyer

       

      -----Original Message-----
      From: gery.derbier@... [mailto:gery.derbier@...]
      Sent:
      Tuesday, August 03, 2004 3:59 AM
      To: scrumdevelopment@yahoogroups.com
      Cc: scrumdevelopment@yahoogroups.com
      Subject: Réf. : [scrumdevelopment] Recent Advisor

       


      >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.

      Crystal has two priorities : efficiency and habitability. Alistair Cockburn and Jim Highsmith have for long considered collaborative decision making at several different levels being an essential part of the Agile approach. Jim refered several times to Sam Kaner's work "The facilitator's guide to participatory decision making". ADC 2004 had a complete session about facilitation skills for agile teams (http://www.agiledevelopmentconference.com/schedule/tutorials.html#TU12)

      >No wonder, for  who likes to deal with conflict?
      Those who understand that conflict avoidance is an anti-pattern.

      Géry.



       

      "Ken Schwaber" <ken.schwaber@...>

      30/07/2004 22:22
      Veuillez répondre à scrumdevelopment

             
              Pour :        <scrumdevelopment@yahoogroups.com>
              cc :        
              Objet :        [scrumdevelopment] Recent Advisor





      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  
        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@...
      To Unsubscribe, send a blank  message to: scrumdevelopment-unsubscribe@...




      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

      Yahoo! Groups Sponsor

      ADVERTISEMENT
      click here

      [IMAGE]

       



      Yahoo! Groups Links

      ·        To visit your group on the web, go to:

      ·        http://groups.yahoo.com/group/scrumdevelopment/

      ·         

      ·        To unsubscribe from this group, send an email to:

      ·        scrumdevelopment-unsubscribe@yahoogroups.com

      ·         

      ·        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.





      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




    Your message has been successfully submitted and would be delivered to recipients shortly.