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

ongoing peer feedback

Expand Messages
  • Christophe Louvion
    Trending committed story points vs. done at the end of each iteration is a great feedback to the whole (taking too much on, getting stuff actually done etc).
    Message 1 of 9 , Nov 28, 2006
    • 0 Attachment
      Trending committed story points vs. done at the end of each iteration is a great feedback to the whole (taking too much on, getting stuff actually "done" etc).
      We also have the retrospective: sharing the good, bad and ugly helps the team be aware as a group of their current issues. You can only fix problems you know about.
      Really well jelled teams will tackle any issues, including individual issues. Nobody runs without making mistakes.
      But sometimes, team members are not providing much feedback to each other (new to agile, cultural thing etc).
      One of my team is of the latter type. They will only discuss simple issues and table some hard discussions involving resurrent troublemakers -- chickens do not participate to retros.
      To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.
      Has anyone done something like this? How did it go?
      Any alternatives for helping team members speak their mind during retros?
       
      Thank you
       
      C

    • Brent Barton
      HI Christophe, I know of a couple organizations who used peer reviews at each iteration. Although I am not opposed, I have seen this backfire because the team
      Message 2 of 9 , Nov 29, 2006
      • 0 Attachment
        HI Christophe,
         
        I know of a couple organizations who used peer reviews at each iteration.  Although I am not opposed, I have seen this backfire because the team was not really empowered to do anything about this.  Also, some in leadership roles used this information to judge teams against each other and this made things worse.  Many people new to Agile are not familiar nor comfortable with shared leadership and the responsibilities that come with it.  From your description, the anonymous feedback is skirting the issue...the team needs to learn how to open up and trust themselves and the organization that supports them.  
         
        I would bias my approach to addressing the known issues with the team and using these as examples for the team to start understanding what an Agile team means.  One thing I have found useful is to hold two retrospectives:  one for all interested parties and one immediately following with the pigs only (as a check in to make sure the team is not damaged with unstated pain).  Caution: This needs to be strongly facilitated, ideally by an objective person.  Set the stage that this is about openness and honesty.  "We make the assumption everyone made the best decision possible based upon the information available at the time." (Kurth) 
         
        Use round robin listing style to get everyone involved (Pass is an acceptable answer, but ask for a response each time).  Process all lists into PBI's, Action items or noteworthy items (not everything translates into actionable work, of course).  I have found that some open up more because they feel the people who have authority to take broader action are in them room.  I have found more "meaty" retrospectives, better action plans and more trust built from these kinds of retrospectives.  It is also a great way for more mature teams to interact with the other teams.
         
        Brent
         


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Christophe Louvion
        Sent: Tuesday, November 28, 2006 9:05 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] ongoing peer feedback

        Trending committed story points vs. done at the end of each iteration is a great feedback to the whole (taking too much on, getting stuff actually "done" etc).
        We also have the retrospective: sharing the good, bad and ugly helps the team be aware as a group of their current issues. You can only fix problems you know about.
        Really well jelled teams will tackle any issues, including individual issues. Nobody runs without making mistakes.
        But sometimes, team members are not providing much feedback to each other (new to agile, cultural thing etc).
        One of my team is of the latter type. They will only discuss simple issues and table some hard discussions involving resurrent troublemakers -- chickens do not participate to retros.
        To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.
        Has anyone done something like this? How did it go?
        Any alternatives for helping team members speak their mind during retros?
         
        Thank you
         
        C

      • Esther Derby
        Hi, Christophe - You wrote: To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the
        Message 3 of 9 , Nov 30, 2006
        • 0 Attachment

          Hi, Christophe -

           

          You wrote: “To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.”

           

          People need to feel safe in order to bring up tough issues. So part of the work in retrospectives is to help people agree on ground rules that will help them be able to do that. 

           

          Anonymous ratings won’t help people feel safe.  If someone receives a low rating, he’s likely to feel *less* trusting.  Further, people don’t know how to change based on a number. They need clear descriptive information about behavior/results and impacts.

           

          So rather than try an anonymous review system, I’d try to find out why people don’t feel safe and try to increase the level of safety.  And I’d train the team on how to give peer-to-peer feedback congruently. 

           

          If you’d like to learn more about peer-to-peer feedback, I’ll point you to some articles.

           

          ED

           

          Esther Derby
          Esther Derby Associates, Inc.
          612-724-8114 www.estherderby.com

          Now available: Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen (Pragmatic Bookshelf, 2006)

          Secrets of Agile Teamwork PUBLIC workshop December 5-7. Email me for more information.


          From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Christophe Louvion
          Sent: Tuesday, November 28, 2006 11:05 PM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] ongoing peer feedback

           

          Trending committed story points vs. done at the end of each iteration is a great feedback to the whole (taking too much on, getting stuff actually "done" etc).

          We also have the retrospective: sharing the good, bad and ugly helps the team be aware as a group of their current issues. You can only fix problems you know about.

          Really well jelled teams will tackle any issues, including individual issues. Nobody runs without making mistakes.

          But sometimes, team members are not providing much feedback to each other (new to agile, cultural thing etc).

          One of my team is of the latter type. They will only discuss simple issues and table some hard discussions involving resurrent troublemakers -- chickens do not participate to retros.

          To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.

          Has anyone done something like this? How did it go?

          Any alternatives for helping team members speak their mind during retros?

           

          Thank you

           

          C

           

        • Vickydhiman
          All: Having people judge other people with score cards/ rating scales goes against Agile completely. If it is written as follows, it makes it lot less him over
          Message 4 of 9 , Nov 30, 2006
          • 0 Attachment
            All:
             
            Having people judge other people with score cards/ rating scales goes against Agile completely. If it is written as follows, it makes it lot less him over her over him scenario:
             
            1. What are things others can improve?
            2. What are things that are good?
            3. What are things that the person knew he has to improve but did not?
             
            Thanks

            Esther Derby <derby@...> wrote:
            Hi, Christophe -
            You wrote: “To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.”
            People need to feel safe in order to bring up tough issues. So part of the work in retrospectives is to help people agree on ground rules that will help them be able to do that. 
            Anonymous ratings won’t help people feel safe.  If someone receives a low rating, he’s likely to feel *less* trusting.  Further, people don’t know how to change based on a number. They need clear descriptive information about behavior/results and impacts.
            So rather than try an anonymous review system, I’d try to find out why people don’t feel safe and try to increase the level of safety.  And I’d train the team on how to give peer-to-peer feedback congruently. 
            If you’d like to learn more about peer-to-peer feedback, I’ll point you to some articles.
            ED
            Esther Derby
            Esther Derby Associates, Inc.
            612-724-8114 www.estherderby. com

            Now available: Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen (Pragmatic Bookshelf, 2006)

            Secrets of Agile Teamwork PUBLIC workshop December 5-7. Email me for more information.

            From: scrumdevelopment@ yahoogroups. com [mailto: scrumdevelopment@ yahoogroups. com ] On Behalf Of Christophe Louvion
            Sent: Tuesday, November 28, 2006 11:05 PM
            To: scrumdevelopment@ yahoogroups. com
            Subject: [scrumdevelopment] ongoing peer feedback
            Trending committed story points vs. done at the end of each iteration is a great feedback to the whole (taking too much on, getting stuff actually "done" etc).
            We also have the retrospective: sharing the good, bad and ugly helps the team be aware as a group of their current issues. You can only fix problems you know about.
            Really well jelled teams will tackle any issues, including individual issues. Nobody runs without making mistakes.
            But sometimes, team members are not providing much feedback to each other (new to agile, cultural thing etc).
            One of my team is of the latter type. They will only discuss simple issues and table some hard discussions involving resurrent troublemakers -- chickens do not participate to retros.
            To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.
            Has anyone done something like this? How did it go?
            Any alternatives for helping team members speak their mind during retros?
            Thank you
            C


            Everyone is raving about the all-new Yahoo! Mail beta.

          • Martine Devos
            Is not agile more about Here, new, us than There, then, them. In that case why start with what are things others can do and not what can I (what can you?)
            Message 5 of 9 , Nov 30, 2006
            • 0 Attachment
              Is not agile more about Here, new, us than There, then, them.
              In that case why start with "what are things others can do" and not "what can I" (what can you?) do?


               
              Martine Devos
              mmdevos@...
              skype: mmdevos1953


              ----- Original Message ----
              From: Vickydhiman <vickydhiman@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Thursday, November 30, 2006 6:25:13 PM
              Subject: RE: [scrumdevelopment] ongoing peer feedback

              All:
               
              Having people judge other people with score cards/ rating scales goes against Agile completely. If it is written as follows, it makes it lot less him over her over him scenario:
               
              1. What are things others can improve?
              2. What are things that are good?
              3. What are things that the person knew he has to improve but did not?
               
              Thanks

              Esther Derby <derby@estherderby. com> wrote:
              Hi, Christophe -
              You wrote: “To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.”
              People need to feel safe in order to bring up tough issues. So part of the work in retrospectives is to help people agree on ground rules that will help them be able to do that. 
              Anonymous ratings won’t help people feel safe.  If someone receives a low rating, he’s likely to feel *less* trusting.  Further, people don’t know how to change based on a number. They need clear descriptive information about behavior/results and impacts.
              So rather than try an anonymous review system, I’d try to find out why people don’t feel safe and try to increase the level of safety.  And I’d train the team on how to give peer-to-peer feedback congruently. 
              If you’d like to learn more about peer-to-peer feedback, I’ll point you to some articles.
              ED
              Esther Derby
              Esther Derby Associates, Inc.
              612-724-8114 www.estherderby. com

              Now available: Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen (Pragmatic Bookshelf, 2006)

              Secrets of Agile Teamwork PUBLIC workshop December 5-7. Email me for more information.

              From: scrumdevelopment@ yahoogroups. com [mailto: scrumdevelopment@ yahoogroups. com ] On Behalf Of Christophe Louvion
              Sent: Tuesday, November 28, 2006 11:05 PM
              To: scrumdevelopment@ yahoogroups. com
              Subject: [scrumdevelopment] ongoing peer feedback
              Trending committed story points vs. done at the end of each iteration is a great feedback to the whole (taking too much on, getting stuff actually "done" etc).
              We also have the retrospective: sharing the good, bad and ugly helps the team be aware as a group of their current issues. You can only fix problems you know about.
              Really well jelled teams will tackle any issues, including individual issues. Nobody runs without making mistakes.
              But sometimes, team members are not providing much feedback to each other (new to agile, cultural thing etc).
              One of my team is of the latter type. They will only discuss simple issues and table some hard discussions involving resurrent troublemakers -- chickens do not participate to retros.
              To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.
              Has anyone done something like this? How did it go?
              Any alternatives for helping team members speak their mind during retros?
              Thank you
              C


              Everyone is raving about the all-new Yahoo! Mail beta.


            • Vickydhiman
              Yes, exactly. Thats also a part of the questions asked. I just focussed on peer review questions in the last email. Thanks Martine Devos
              Message 6 of 9 , Nov 30, 2006
              • 0 Attachment
                Yes, exactly.

                Thats also a part of the questions asked. I just focussed on "peer review" questions in the last email.

                Thanks

                Martine Devos <mmdevos1953@...> wrote:
                Is not agile more about Here, new, us than There, then, them.
                In that case why start with "what are things others can do" and not "what can I" (what can you?) do?


                 
                Martine Devos
                mmdevos@acm. org
                skype: mmdevos1953


                ----- Original Message ----
                From: Vickydhiman <vickydhiman@ yahoo.com>
                To: scrumdevelopment@ yahoogroups. com
                Sent: Thursday, November 30, 2006 6:25:13 PM
                Subject: RE: [scrumdevelopment] ongoing peer feedback

                All:
                 
                Having people judge other people with score cards/ rating scales goes against Agile completely. If it is written as follows, it makes it lot less him over her over him scenario:
                 
                1. What are things others can improve?
                2. What are things that are good?
                3. What are things that the person knew he has to improve but did not?
                 
                Thanks

                Esther Derby <derby@estherderby. com> wrote:
                Hi, Christophe -
                You wrote: “To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.”
                People need to feel safe in order to bring up tough issues. So part of the work in retrospectives is to help people agree on ground rules that will help them be able to do that. 
                Anonymous ratings won’t help people feel safe.  If someone receives a low rating, he’s likely to feel *less* trusting.  Further, people don’t know how to change based on a number. They need clear descriptive information about behavior/results and impacts.
                So rather than try an anonymous review system, I’d try to find out why people don’t feel safe and try to increase the level of safety.  And I’d train the team on how to give peer-to-peer feedback congruently. 
                If you’d like to learn more about peer-to-peer feedback, I’ll point you to some articles.
                ED
                Esther Derby
                Esther Derby Associates, Inc.
                612-724-8114 www.estherderby. com

                Now available: Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen (Pragmatic Bookshelf, 2006)

                Secrets of Agile Teamwork PUBLIC workshop December 5-7. Email me for more information.

                From: scrumdevelopment@ yahoogroups. com [mailto: scrumdevelopment@ yahoogroups. com ] On Behalf Of Christophe Louvion
                Sent: Tuesday, November 28, 2006 11:05 PM
                To: scrumdevelopment@ yahoogroups. com
                Subject: [scrumdevelopment] ongoing peer feedback
                Trending committed story points vs. done at the end of each iteration is a great feedback to the whole (taking too much on, getting stuff actually "done" etc).
                We also have the retrospective: sharing the good, bad and ugly helps the team be aware as a group of their current issues. You can only fix problems you know about.
                Really well jelled teams will tackle any issues, including individual issues. Nobody runs without making mistakes.
                But sometimes, team members are not providing much feedback to each other (new to agile, cultural thing etc).
                One of my team is of the latter type. They will only discuss simple issues and table some hard discussions involving resurrent troublemakers -- chickens do not participate to retros.
                To break the mental barrier to providing feedback about people, a suggested idea was to run anonymous quick peer reviews at the end of each iteration (maybe with a 1 to 5 score), and provide everyone on the team with their personal average peer score and the total team average, so they can be made aware of the other teams member feeling about them while comparing themselves to the rest of the team (without not knowing anything else about anyone in particular). The assumption being that someone getting bad reviews over and over by his team will do something about it, or at least not be surprised when the team decides to reject him/her.
                Has anyone done something like this? How did it go?
                Any alternatives for helping team members speak their mind during retros?
                Thank you
                C


                Everyone is raving about the all-new Yahoo! Mail beta.



                Access over 1 million songs - Yahoo! Music Unlimited.

              • entretriens
                Anonymous feedbacks are sometimes effective in that they sometimes get the teammembers to speak. But not always. What are the size of your teams? Who s being
                Message 7 of 9 , Dec 1, 2006
                • 0 Attachment
                  Anonymous feedbacks are sometimes effective in that they sometimes get
                  the teammembers to speak. But not always.

                  What are the size of your teams?
                  Who's being rated? Their role? Their status?
                  What's the potential backlash for speaking openly?
                  What's your team like? Are the feedbacks objective?

                  Anonymous is well intentioned, but sometimes it's too easy to figure
                  out who rated what on who, in which case it's not very anonymous.
                  Moreover, it can potentially worsen morale if the rated think he is
                  doing fine and then is slapped with low ratings from his peers.

                  If there are barriers to feedback exchange amongst teammembers, then
                  it might be worth taking a step back and focusing on bettering the
                  relationships within the team. I don't refer to eventful morale
                  boosters as the good feelings soon fade after the moments are gone,
                  but measures that might improve the day-to-day interactions amongst
                  teammembers. If people can't honestly talk to each other, then it's a
                  sign of weakness on another level.

                  If the relationships are strong within the group then formal feedback
                  tends to work better regardless of what tool you use. Moreover, it's
                  also important for feedback occur less formally in small conversations
                  throughout the iterations in which case you can potentially fix and
                  avoid some problems -- the PM/scrummaster should foster this behavior.

                  For formal evaluations, I think a conversational element is important,
                  but I for one am not against a numbered rating system: I think it's
                  useful particulary for matrixed enviroments.

                  Thank you Dr. Sutherland for your template, I give it a whirl in my
                  upcoming releases.



                  --- In scrumdevelopment@yahoogroups.com, "Esther Derby" <derby@...> wrote:
                  >
                  > Hi, Christophe -
                  >
                  >
                  >
                  > You wrote: "To break the mental barrier to providing feedback about
                  people,
                  > a suggested idea was to run anonymous quick peer reviews at the end
                  of each
                  > iteration (maybe with a 1 to 5 score), and provide everyone on the
                  team with
                  > their personal average peer score and the total team average, so
                  they can be
                  > made aware of the other teams member feeling about them while comparing
                  > themselves to the rest of the team (without not knowing anything
                  else about
                  > anyone in particular). The assumption being that someone getting bad
                  reviews
                  > over and over by his team will do something about it, or at least not be
                  > surprised when the team decides to reject him/her."
                  >
                  >
                  >
                  > People need to feel safe in order to bring up tough issues. So part
                  of the
                  > work in retrospectives is to help people agree on ground rules that will
                  > help them be able to do that.
                  >
                  >
                  >
                  > Anonymous ratings won't help people feel safe. If someone receives
                  a low
                  > rating, he's likely to feel *less* trusting. Further, people don't
                  know how
                  > to change based on a number. They need clear descriptive information
                  about
                  > behavior/results and impacts.
                  >
                  >
                  >
                  > So rather than try an anonymous review system, I'd try to find out why
                  > people don't feel safe and try to increase the level of safety. And I'd
                  > train the team on how to give peer-to-peer feedback congruently.
                  >
                  >
                  >
                  > If you'd like to learn more about peer-to-peer feedback, I'll point
                  you to
                  > some articles.
                  >
                  >
                  >
                  > ED
                  >
                  >
                  >
                  > Esther Derby
                  > Esther Derby Associates, Inc.
                  > 612-724-8114 www.estherderby.com
                  >
                  > Now available: Agile Retrospectives: Making Good Teams Great, by Esther
                  > Derby and Diana Larsen (Pragmatic Bookshelf, 2006)
                  >
                  > Secrets of Agile Teamwork PUBLIC workshop December 5-7. Email me for
                  more
                  > information.
                  >
                  > _____
                  >
                  > From: scrumdevelopment@yahoogroups.com
                  > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Christophe
                  Louvion
                  > Sent: Tuesday, November 28, 2006 11:05 PM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: [scrumdevelopment] ongoing peer feedback
                  >
                  >
                  >
                  > Trending committed story points vs. done at the end of each
                  iteration is a
                  > great feedback to the whole (taking too much on, getting stuff actually
                  > "done" etc).
                  >
                  > We also have the retrospective: sharing the good, bad and ugly helps the
                  > team be aware as a group of their current issues. You can only fix
                  problems
                  > you know about.
                  >
                  > Really well jelled teams will tackle any issues, including individual
                  > issues. Nobody runs without making mistakes.
                  >
                  > But sometimes, team members are not providing much feedback to each
                  other
                  > (new to agile, cultural thing etc).
                  >
                  > One of my team is of the latter type. They will only discuss simple
                  issues
                  > and table some hard discussions involving resurrent troublemakers --
                  > chickens do not participate to retros.
                  >
                  > To break the mental barrier to providing feedback about people, a
                  suggested
                  > idea was to run anonymous quick peer reviews at the end of each
                  iteration
                  > (maybe with a 1 to 5 score), and provide everyone on the team with their
                  > personal average peer score and the total team average, so they can
                  be made
                  > aware of the other teams member feeling about them while comparing
                  > themselves to the rest of the team (without not knowing anything
                  else about
                  > anyone in particular). The assumption being that someone getting bad
                  reviews
                  > over and over by his team will do something about it, or at least not be
                  > surprised when the team decides to reject him/her.
                  >
                  > Has anyone done something like this? How did it go?
                  >
                  > Any alternatives for helping team members speak their mind during
                  retros?
                  >
                  >
                  >
                  > Thank you
                  >
                  >
                  >
                  > C
                  >
                • Esther Derby
                  He, entretriens-- ... Sometimes it is easy to figure out who gave the anonymous feedback...and then the feedback receiver wonders Why didn t s/he tell me
                  Message 8 of 9 , Dec 1, 2006
                  • 0 Attachment
                    He, entretriens--

                    > Anonymous is well intentioned, but sometimes it's too easy to figure
                    > out who rated what on who, in which case it's not very anonymous.
                    > Moreover, it can potentially worsen morale if the rated think he is
                    > doing fine and then is slapped with low ratings from his peers.

                    Sometimes it is easy to figure out who gave the anonymous feedback...and
                    then the feedback receiver wonders "Why didn't s/he tell me directly?"

                    Sometimes feedback receivers only *thinks* he knows who gave the
                    feedback...and then he wonders "Why didn't s/he tell me directly?" about the
                    wrong person.

                    When people guess where feedback came from, they get it wrong as often as
                    not.

                    When feedback is anonymous, the feedback receiver doesn't know who to go to
                    for clarification, nor can they put the feedback in context.

                    The result? Anonymous feedback breaks trust.

                    > If there are barriers to feedback exchange amongst teammembers, then
                    > it might be worth taking a step back and focusing on bettering the
                    > relationships within the team. <snip> If people can't honestly talk to
                    each other, then it's a
                    > sign of weakness on another level.

                    Indeed. And sometimes, people don't know how to give feedback in a way
                    that's congruent and helpful. Peer-to-peer feedback is a skill that agile
                    teams need to support inspecting and adapting working relationships.

                    <snip> I for one am not against a numbered rating system: I think it's
                    useful particulary for matrixed enviroments.

                    So let's do a thought experiment:

                    Suppose someone tells you: "You are a "3". Do you know what you need to
                    change to be a "4"? Do you know why you are a 3 and not a 2 or a 4? How
                    does it feel to have someone tell you that you are a "3"?

                    Ratings tell you something about another person's judgment or evaluation of
                    you. They don't give the information that would help you improve.

                    >Are the feedbacks objective?<

                    On some level, feedback is always about the feedback giver - it's his/her
                    perception of you, not the truth about you.

                    Esther

                    Esther Derby
                    Esther Derby Associates, Inc.
                    612-724-8114 www.estherderby.com

                    **Agile Retrospectives named one of the TOP TEN TECH BOOKS of 2006 by the
                    editors at amazon.com!**

                    Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana
                    Larsen (Pragmatic Bookshelf, 2006)

                    > -----Original Message-----
                    > From: scrumdevelopment@yahoogroups.com
                    > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of entretriens
                    > Sent: Friday, December 01, 2006 9:16 AM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: [scrumdevelopment] Re: ongoing peer feedback
                    >
                    > Anonymous feedbacks are sometimes effective in that they sometimes get
                    > the teammembers to speak. But not always.
                    >
                    > What are the size of your teams?
                    > Who's being rated? Their role? Their status?
                    > What's the potential backlash for speaking openly?
                    > What's your team like? Are the feedbacks objective?
                    >
                    > Anonymous is well intentioned, but sometimes it's too easy to figure
                    > out who rated what on who, in which case it's not very anonymous.
                    > Moreover, it can potentially worsen morale if the rated think he is
                    > doing fine and then is slapped with low ratings from his peers.
                    >
                    > If there are barriers to feedback exchange amongst teammembers, then
                    > it might be worth taking a step back and focusing on bettering the
                    > relationships within the team. I don't refer to eventful morale
                    > boosters as the good feelings soon fade after the moments are gone,
                    > but measures that might improve the day-to-day interactions amongst
                    > teammembers. If people can't honestly talk to each other, then it's a
                    > sign of weakness on another level.
                    >
                    > If the relationships are strong within the group then formal feedback
                    > tends to work better regardless of what tool you use. Moreover, it's
                    > also important for feedback occur less formally in small conversations
                    > throughout the iterations in which case you can potentially fix and
                    > avoid some problems -- the PM/scrummaster should foster this behavior.
                    >
                    > For formal evaluations, I think a conversational element is important,
                    > but I for one am not against a numbered rating system: I think it's
                    > useful particulary for matrixed enviroments.
                    >
                    > Thank you Dr. Sutherland for your template, I give it a whirl in my
                    > upcoming releases.
                    >
                    >
                    >
                    > --- In scrumdevelopment@yahoogroups.com, "Esther Derby" <derby@...> wrote:
                    > >
                    > > Hi, Christophe -
                    > >
                    > >
                    > >
                    > > You wrote: "To break the mental barrier to providing feedback about
                    > people,
                    > > a suggested idea was to run anonymous quick peer reviews at the end
                    > of each
                    > > iteration (maybe with a 1 to 5 score), and provide everyone on the
                    > team with
                    > > their personal average peer score and the total team average, so
                    > they can be
                    > > made aware of the other teams member feeling about them while comparing
                    > > themselves to the rest of the team (without not knowing anything
                    > else about
                    > > anyone in particular). The assumption being that someone getting bad
                    > reviews
                    > > over and over by his team will do something about it, or at least not be
                    > > surprised when the team decides to reject him/her."
                    > >
                    > >
                    > >
                    > > People need to feel safe in order to bring up tough issues. So part
                    > of the
                    > > work in retrospectives is to help people agree on ground rules that will
                    > > help them be able to do that.
                    > >
                    > >
                    > >
                    > > Anonymous ratings won't help people feel safe. If someone receives
                    > a low
                    > > rating, he's likely to feel *less* trusting. Further, people don't
                    > know how
                    > > to change based on a number. They need clear descriptive information
                    > about
                    > > behavior/results and impacts.
                    > >
                    > >
                    > >
                    > > So rather than try an anonymous review system, I'd try to find out why
                    > > people don't feel safe and try to increase the level of safety. And I'd
                    > > train the team on how to give peer-to-peer feedback congruently.
                    > >
                    > >
                    > >
                    > > If you'd like to learn more about peer-to-peer feedback, I'll point
                    > you to
                    > > some articles.
                    > >
                    > >
                    > >
                    > > ED
                    > >
                    > >
                    > >
                    > > Esther Derby
                    > > Esther Derby Associates, Inc.
                    > > 612-724-8114 www.estherderby.com
                    > >
                    > > Now available: Agile Retrospectives: Making Good Teams Great, by Esther
                    > > Derby and Diana Larsen (Pragmatic Bookshelf, 2006)
                    > >
                    > > Secrets of Agile Teamwork PUBLIC workshop December 5-7. Email me for
                    > more
                    > > information.
                    > >
                    > > _____
                    > >
                    > > From: scrumdevelopment@yahoogroups.com
                    > > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Christophe
                    > Louvion
                    > > Sent: Tuesday, November 28, 2006 11:05 PM
                    > > To: scrumdevelopment@yahoogroups.com
                    > > Subject: [scrumdevelopment] ongoing peer feedback
                    > >
                    > >
                    > >
                    > > Trending committed story points vs. done at the end of each
                    > iteration is a
                    > > great feedback to the whole (taking too much on, getting stuff actually
                    > > "done" etc).
                    > >
                    > > We also have the retrospective: sharing the good, bad and ugly helps the
                    > > team be aware as a group of their current issues. You can only fix
                    > problems
                    > > you know about.
                    > >
                    > > Really well jelled teams will tackle any issues, including individual
                    > > issues. Nobody runs without making mistakes.
                    > >
                    > > But sometimes, team members are not providing much feedback to each
                    > other
                    > > (new to agile, cultural thing etc).
                    > >
                    > > One of my team is of the latter type. They will only discuss simple
                    > issues
                    > > and table some hard discussions involving resurrent troublemakers --
                    > > chickens do not participate to retros.
                    > >
                    > > To break the mental barrier to providing feedback about people, a
                    > suggested
                    > > idea was to run anonymous quick peer reviews at the end of each
                    > iteration
                    > > (maybe with a 1 to 5 score), and provide everyone on the team with their
                    > > personal average peer score and the total team average, so they can
                    > be made
                    > > aware of the other teams member feeling about them while comparing
                    > > themselves to the rest of the team (without not knowing anything
                    > else about
                    > > anyone in particular). The assumption being that someone getting bad
                    > reviews
                    > > over and over by his team will do something about it, or at least not be
                    > > surprised when the team decides to reject him/her.
                    > >
                    > > Has anyone done something like this? How did it go?
                    > >
                    > > Any alternatives for helping team members speak their mind during
                    > retros?
                    > >
                    > >
                    > >
                    > > Thank you
                    > >
                    > >
                    > >
                    > > C
                    > >
                    >
                    >
                    >
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to: scrumdevelopment-
                    > unsubscribe@...
                    > Yahoo! Groups Links
                    >
                    >
                    >
                  • entretriens
                    People frequently make errors when attempting to pinpoint the source of anonymous feedback, I didn t mention that, but that doesn t mean I disagree. Did you
                    Message 9 of 9 , Dec 4, 2006
                    • 0 Attachment
                      People frequently make errors when attempting to pinpoint the source
                      of anonymous feedback, I didn't mention that, but that doesn't mean I
                      disagree. Did you mistake my response as being strongly in support of
                      anonymous feedback? As I mentioned earlier, anonymous feedback can
                      cause problems, but in the right environment the issues are minimized.

                      Did you look at the template set forth by Jeff Sutherland? It doesn't
                      appear so. I don't advocate a strictly numbered rating system, but
                      numbers tell a story of their own (they provide something
                      measureable), which I think is valid especially for larger scale
                      environments. Both the numbers and feedback are important as far as
                      I'm concerned.

                      --- In scrumdevelopment@yahoogroups.com, "Esther Derby" <derby@...> wrote:
                      >
                      > He, entretriens--
                      >
                      > > Anonymous is well intentioned, but sometimes it's too easy to figure
                      > > out who rated what on who, in which case it's not very anonymous.
                      > > Moreover, it can potentially worsen morale if the rated think he is
                      > > doing fine and then is slapped with low ratings from his peers.
                      >
                      > Sometimes it is easy to figure out who gave the anonymous feedback...and
                      > then the feedback receiver wonders "Why didn't s/he tell me directly?"
                      >
                      > Sometimes feedback receivers only *thinks* he knows who gave the
                      > feedback...and then he wonders "Why didn't s/he tell me directly?"
                      about the
                      > wrong person.
                      >
                      > When people guess where feedback came from, they get it wrong as
                      often as
                      > not.
                      >
                      > When feedback is anonymous, the feedback receiver doesn't know who
                      to go to
                      > for clarification, nor can they put the feedback in context.
                      >
                      > The result? Anonymous feedback breaks trust.
                      >
                      > > If there are barriers to feedback exchange amongst teammembers, then
                      > > it might be worth taking a step back and focusing on bettering the
                      > > relationships within the team. <snip> If people can't honestly talk to
                      > each other, then it's a
                      > > sign of weakness on another level.
                      >
                      > Indeed. And sometimes, people don't know how to give feedback in a way
                      > that's congruent and helpful. Peer-to-peer feedback is a skill that
                      agile
                      > teams need to support inspecting and adapting working relationships.
                      >
                      > <snip> I for one am not against a numbered rating system: I think it's
                      > useful particulary for matrixed enviroments.
                      >
                      > So let's do a thought experiment:
                      >
                      > Suppose someone tells you: "You are a "3". Do you know what you need to
                      > change to be a "4"? Do you know why you are a 3 and not a 2 or a 4? How
                      > does it feel to have someone tell you that you are a "3"?
                      >
                      > Ratings tell you something about another person's judgment or
                      evaluation of
                      > you. They don't give the information that would help you improve.
                      >
                      > >Are the feedbacks objective?<
                      >
                      > On some level, feedback is always about the feedback giver - it's
                      his/her
                      > perception of you, not the truth about you.
                      >
                      > Esther
                      >
                      > Esther Derby
                      > Esther Derby Associates, Inc.
                      > 612-724-8114 www.estherderby.com
                      >
                      > **Agile Retrospectives named one of the TOP TEN TECH BOOKS of 2006
                      by the
                      > editors at amazon.com!**
                      >
                      > Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana
                      > Larsen (Pragmatic Bookshelf, 2006)
                      >
                      > > -----Original Message-----
                      > > From: scrumdevelopment@yahoogroups.com
                      > > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of entretriens
                      > > Sent: Friday, December 01, 2006 9:16 AM
                      > > To: scrumdevelopment@yahoogroups.com
                      > > Subject: [scrumdevelopment] Re: ongoing peer feedback
                      > >
                      > > Anonymous feedbacks are sometimes effective in that they sometimes get
                      > > the teammembers to speak. But not always.
                      > >
                      > > What are the size of your teams?
                      > > Who's being rated? Their role? Their status?
                      > > What's the potential backlash for speaking openly?
                      > > What's your team like? Are the feedbacks objective?
                      > >
                      > > Anonymous is well intentioned, but sometimes it's too easy to figure
                      > > out who rated what on who, in which case it's not very anonymous.
                      > > Moreover, it can potentially worsen morale if the rated think he is
                      > > doing fine and then is slapped with low ratings from his peers.
                      > >
                      > > If there are barriers to feedback exchange amongst teammembers, then
                      > > it might be worth taking a step back and focusing on bettering the
                      > > relationships within the team. I don't refer to eventful morale
                      > > boosters as the good feelings soon fade after the moments are gone,
                      > > but measures that might improve the day-to-day interactions amongst
                      > > teammembers. If people can't honestly talk to each other, then it's a
                      > > sign of weakness on another level.
                      > >
                      > > If the relationships are strong within the group then formal feedback
                      > > tends to work better regardless of what tool you use. Moreover, it's
                      > > also important for feedback occur less formally in small conversations
                      > > throughout the iterations in which case you can potentially fix and
                      > > avoid some problems -- the PM/scrummaster should foster this behavior.
                      > >
                      > > For formal evaluations, I think a conversational element is important,
                      > > but I for one am not against a numbered rating system: I think it's
                      > > useful particulary for matrixed enviroments.
                      > >
                      > > Thank you Dr. Sutherland for your template, I give it a whirl in my
                      > > upcoming releases.
                      > >
                      > >
                      > >
                      > > --- In scrumdevelopment@yahoogroups.com, "Esther Derby" <derby@>
                      wrote:
                      > > >
                      > > > Hi, Christophe -
                      > > >
                      > > >
                      > > >
                      > > > You wrote: "To break the mental barrier to providing feedback about
                      > > people,
                      > > > a suggested idea was to run anonymous quick peer reviews at the end
                      > > of each
                      > > > iteration (maybe with a 1 to 5 score), and provide everyone on the
                      > > team with
                      > > > their personal average peer score and the total team average, so
                      > > they can be
                      > > > made aware of the other teams member feeling about them while
                      comparing
                      > > > themselves to the rest of the team (without not knowing anything
                      > > else about
                      > > > anyone in particular). The assumption being that someone getting bad
                      > > reviews
                      > > > over and over by his team will do something about it, or at
                      least not be
                      > > > surprised when the team decides to reject him/her."
                      > > >
                      > > >
                      > > >
                      > > > People need to feel safe in order to bring up tough issues. So part
                      > > of the
                      > > > work in retrospectives is to help people agree on ground rules
                      that will
                      > > > help them be able to do that.
                      > > >
                      > > >
                      > > >
                      > > > Anonymous ratings won't help people feel safe. If someone receives
                      > > a low
                      > > > rating, he's likely to feel *less* trusting. Further, people don't
                      > > know how
                      > > > to change based on a number. They need clear descriptive information
                      > > about
                      > > > behavior/results and impacts.
                      > > >
                      > > >
                      > > >
                      > > > So rather than try an anonymous review system, I'd try to find
                      out why
                      > > > people don't feel safe and try to increase the level of safety.
                      And I'd
                      > > > train the team on how to give peer-to-peer feedback congruently.
                      > > >
                      > > >
                      > > >
                      > > > If you'd like to learn more about peer-to-peer feedback, I'll point
                      > > you to
                      > > > some articles.
                      > > >
                      > > >
                      > > >
                      > > > ED
                      > > >
                      > > >
                      > > >
                      > > > Esther Derby
                      > > > Esther Derby Associates, Inc.
                      > > > 612-724-8114 www.estherderby.com
                      > > >
                      > > > Now available: Agile Retrospectives: Making Good Teams Great, by
                      Esther
                      > > > Derby and Diana Larsen (Pragmatic Bookshelf, 2006)
                      > > >
                      > > > Secrets of Agile Teamwork PUBLIC workshop December 5-7. Email me for
                      > > more
                      > > > information.
                      > > >
                      > > > _____
                      > > >
                      > > > From: scrumdevelopment@yahoogroups.com
                      > > > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Christophe
                      > > Louvion
                      > > > Sent: Tuesday, November 28, 2006 11:05 PM
                      > > > To: scrumdevelopment@yahoogroups.com
                      > > > Subject: [scrumdevelopment] ongoing peer feedback
                      > > >
                      > > >
                      > > >
                      > > > Trending committed story points vs. done at the end of each
                      > > iteration is a
                      > > > great feedback to the whole (taking too much on, getting stuff
                      actually
                      > > > "done" etc).
                      > > >
                      > > > We also have the retrospective: sharing the good, bad and ugly
                      helps the
                      > > > team be aware as a group of their current issues. You can only fix
                      > > problems
                      > > > you know about.
                      > > >
                      > > > Really well jelled teams will tackle any issues, including
                      individual
                      > > > issues. Nobody runs without making mistakes.
                      > > >
                      > > > But sometimes, team members are not providing much feedback to each
                      > > other
                      > > > (new to agile, cultural thing etc).
                      > > >
                      > > > One of my team is of the latter type. They will only discuss simple
                      > > issues
                      > > > and table some hard discussions involving resurrent troublemakers --
                      > > > chickens do not participate to retros.
                      > > >
                      > > > To break the mental barrier to providing feedback about people, a
                      > > suggested
                      > > > idea was to run anonymous quick peer reviews at the end of each
                      > > iteration
                      > > > (maybe with a 1 to 5 score), and provide everyone on the team
                      with their
                      > > > personal average peer score and the total team average, so they can
                      > > be made
                      > > > aware of the other teams member feeling about them while comparing
                      > > > themselves to the rest of the team (without not knowing anything
                      > > else about
                      > > > anyone in particular). The assumption being that someone getting bad
                      > > reviews
                      > > > over and over by his team will do something about it, or at
                      least not be
                      > > > surprised when the team decides to reject him/her.
                      > > >
                      > > > Has anyone done something like this? How did it go?
                      > > >
                      > > > Any alternatives for helping team members speak their mind during
                      > > retros?
                      > > >
                      > > >
                      > > >
                      > > > Thank you
                      > > >
                      > > >
                      > > >
                      > > > C
                      > > >
                      > >
                      > >
                      > >
                      > >
                      > > To Post a message, send it to: scrumdevelopment@...
                      > > To Unsubscribe, send a blank message to: scrumdevelopment-
                      > > unsubscribe@...
                      > > Yahoo! Groups Links
                      > >
                      > >
                      > >
                      >
                    Your message has been successfully submitted and would be delivered to recipients shortly.