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

Re: [scrumdevelopment] Re: Specific Change Capacity (was: Scrum Master 360 degree feedback)

Expand Messages
  • Simon Kirk
    Hi Eb. I take your points, just a quick couple of thoughts: 1. By rail-roading their retrospective I meant that I didn t want to drive the retrospective solely
    Message 1 of 46 , May 1, 2008
    • 0 Attachment
      Hi Eb. I take your points, just a quick couple of thoughts:

      1. By rail-roading their retrospective I meant that I didn't want to
      drive the retrospective solely towards what I thought they needed to
      improve. If the team identifies something as an issues, it's probably
      best to aim to resolve that in some manner, even if I include a bit of
      a nod in the direction that I think they should improve. If I do
      decide to drive them towards something else I'd better have a good
      reason, and make the decision collaboratively with the team.

      2. A wider retrospective is something I would look for, too: I think
      there you're referring to the team providing me with change items, in
      much the same manner as Tobias suggested.

      3. My concern for the team is often not engineering related, despite
      my wont :)

      4. As for having the PO in retrospectives - well that's another thread
      that I'm about to start ;)

      Cheers for the answer.

      S

      On 27 Apr 2008, at 17:19, Eb wrote:

      > Simon,
      >
      > Thought I'd jump in here and offer a thought. I'll lead with the
      > general Lean / Systems
      > thinking viewpoint that you should avoid locale specific
      > adjustment / improvement efforts
      > and focus on tuning the whole beast.
      >
      > When you say that you don't want to railroad 'their' retrospective
      > (by adding more wider
      > change?), I think you should look to a wider retrospective format
      > that includes you and
      > maybe the wider business 'value' produced by your efforts.
      >
      > Its great that the team are keen to improve specific engineering
      > practices, I know from
      > experience how nice it is to focus your efforts on 'engineering
      > stuff' - but don't let them
      > become blind to the larger mission of delivering value to your
      > customer and business.
      >
      > The finest piece of code will not deliver value if, for whatever
      > reason it is functionally (biz
      > value) redundant. I think that's where you and the PO (and the rest
      > of your company) fit in
      > and why you need to bring that into the retrospective process.
      >
      > I don't think you need to add to the overall volume / amount of
      > change the team is
      > exposed to, but you could look at wider, smaller, incremental
      > change. I think an
      > organisation can evolve but you need 'everything' to change, a
      > little, all at once: rise,
      > repeat.
      >
      > Cheers,
      > Eben
      >
      >
      > --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@...> wrote:
      >>
      >> Hi Tobias.
      >>
      >> I thought I'd start a new thread on this riff since it's slightly
      >> departing from my original subject.
      >>
      >> Using the Scrum process as you admonish is exactly what I'd like to
      >> do. However, even when we're doing two-week sprints (thus getting a
      >> significant amount of retrospective chances), the amount of change we
      >> can come up with AND effectively act on is pretty limited. A team's
      >> "Specific Change Capacity" (to crib a physics term) is really a
      >> fairly
      >> small amount (I have seen it written in this list before by Esther
      >> Derby iirc that the same is true for organisations, that being they
      >> can only absorb so much change at a time, making Agile adoptions a
      >> drawn-out process).
      >>
      >> Assuming that to be true and bearing it in mind: My team is very much
      >> focussed on improvements on their Agile technical practices (pair
      >> programming, test coverage, continuos integration, etc etc). I am not
      >> about to rail road their retrospectives towards what I think they
      >> should prioritise (particularly as I recognise the very pressing need
      >> for improvements in all the areas they identify anyway), so where
      >> does
      >> the time come for the kind of individual growth via retrospectives
      >> we're talking about here when my team is so busy changing everything
      >> else?
      >>
      >> S
      >>
      >> On 27 Apr 2008, at 01:25, Tobias Mayer wrote:
      >>
      >>> Hi Simon.
      >>>
      >>> Whatever it is you are looking for... affirmation, criticism,
      >>> guidance... I think you are looking in the wrong place.
      >>>
      >>> Firstly most performance reviews, even the 360 one you are using are
      >>> linked directly to salary adjustments. This is inherently flawed as
      >>> Mary Poppendieck points out (as quoted
      > here:http://runningagile.com/2008/01/22/review-process-for-agile-team-members/)
      >>> .
      >>>
      >>> Secondly, even if the performance review is decoupled from the
      >>> salary issues I still think it is a flawed and outmoded idea. Such
      >>> a review process sets up a fake environment, far removed from our
      >>> everyday work context. As a result people behave differently and
      >>> the feedback offered generally bears little relation to true
      >>> feelings and interactions.
      >>>
      >>> Chad Eaves stated: In order for feedback to be of value, people need
      >>> to feel safe in giving it. This is undeniably true. Setting up a
      >>> special feedback environment (the review process) is not going to
      >>> create that safety. On the other hand, a familiar and routine forum
      >>> perhaps will, so use your retrospectives to find what you are
      >>> looking for. Perhaps it is time to take the retrospective to
      >>> another level -- a more personal one that is born of camaraderie and
      >>> trust -- and yes, courage.
      >>>
      >>> Thirdly, I am passionately opposed to any form of anonymous
      >>> feedback. I believe it is absolutely without value. Performance
      >>> Reviews promote the idea of hiding information (i.e. hiding the
      >>> identity of the reviewer). This is destructive and causes all kinds
      >>> of unresolved, and unresolvable, bad feelings to be surfaced and to
      >>> linger. In a retrospective setting we are accountable for the words
      >>> we speak. Accountability is an essential feature of a healthy Agile
      >>> environment, and one we should always be promoting. It is, after
      >>> all, an element of transparency.
      >>>
      >>> So I want to suggest that anyone on this list struggling with how to
      >>> run performance reviews, simply throw the whole concept into the
      >>> trash (it usually represents massive waste) and use the Scrum
      >>> process to continuously provide the kind of honest and truthful
      >>> feedback we all need as workers, as humans.
      >>>
      >>> Tobias
      >>> http://agilethinking.net
      >>>
      >>>
      >>>
      >>> --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@> wrote:
      >>>>
      >>>> Hi Chad.
      >>>>
      >>>> Nice points!
      >>>>
      >>>> I find it interesting that a significant percentage of the talks I
      >>>> attended at last year's Scrum Gathering in London (Roman Pilcher's
      >>>> Product Owner talk sprints to mind as an example) had a sheet
      >>>> asking
      >>>> for explicit and immediate feedback on his course, while the
      >>> gathering
      >>>> as a whole had a wall for providing feedback on the gathering
      >>> itself.
      >>>> I'm sure that Chicago's one did, too.
      >>>>
      >>>> So maybe giving such feedback is seen as safer, in an agile
      >>> environment?
      >>>>
      >>>> I hope I've grown enough feeling of safety in the team by now, but
      >>>> it's well worth keeping in mind. Thanks.
      >>>>
      >>>> S
      >>>>
      >>>> On 26 Apr 2008, at 15:59, Chad Eaves wrote:
      >>>>
      >>>>> A big obstacle in feedback is human nature and cultural, I
      >>> believe.
      >>>>> Far too often, people are not accustomed to being asked for their
      >>>>> feedback, especially if it is directed towards a boss/employer-
      >>> type
      >>>>> person. I teach a Junior Achievement class once a week and asked
      >>>>> senior students for feedback on my presentation and they looked
      >>>>> stunned. Getting them to offer feedback is one of my goals in my
      >>>>> course. I'll let everyone know how that is at course end.
      >>>>>
      >>>>> In order for feedback to be of value, people need to feel safe in
      >>>>> giving it. Unfortunately, companies have undermined this value.
      >>>>> How often has an "anonymous" survey tool turned out not to be so?
      >>>>>
      >>>>> Unfortunately, fostering this safe feeling takes time. And as we
      >>>>> all know, that is something we usually do not have an excess of on
      >>>>> projects.
      >>>>>
      >>>>> Without surmounting the personal security issue, great questions
      >>> may
      >>>>> yield little value.
      >>>>>
      >>>>> Chad Eaves
      >>>
      >>> ---------------------
      >>>>>>> Original Post...
      >>> On Thu, Apr 24, 2008 at 6:08 PM, Simon Kirk scrum@
      >>> wrote:
      >>>
      >>> Hi all.
      >>>
      >>> We're going through performance reviews at the moment and I've been
      >>> trying really hard to move away from the traditional small-company
      >>> quick chat, pat on the back and on-you-go for another year "review"
      >>> process that has been my experience for the companies I've worked at
      >>> before.
      >>>
      >>> On the other hand I abhorred the thought of going down an ultra-
      >>> bureaucratic HR-style route such as I imagine happens in big
      >>> companies. Instead some Googling turned up this, which so far
      >>> seems to
      >>> be going well:
      >>> http://runningagile.com/2008/01/22/review-process-for-agile-team-members/
      >>> (really it's Jeff Sutherland's original posting on an Agile Team
      >>> review process, but with some additional quotes at the start and a
      >>> bit
      >>> of tidying).
      >>>
      >>> Now, I was thinking about how I as the Scrum Master could get
      >>> reviewed
      >>> by my team - if 360 degree feedback is good for them, surely it's
      >>> good
      >>> for me? One of my team also asked for an opportunity to "review the
      >>> reviewer", but nowhere can I find good examples of how a Scrum
      >>> Master
      >>> can be evaluated, let alone by his or her team.
      >>>
      >>> For instance, taking the above URL as context, I'm not sure what the
      >>> right questions are the team should be asked about me.
      >>>
      >>> Has anybody got any pointers, I'd really appreciate the help?
      >>>
      >>> Thanks,
      >>> Simon
      >>>
      >>> ps. No more yearly reviews, either: I've taken this opportunity to
      >>> move to two monthly, despite the additional overhead. If anybody has
      >>> any comments on that I'd be happy to hear them, too.
      >>>
      >>> pps. Yes, we do Sprint retrospectives: they're brilliant, but
      >>> sometimes they lack the one-on-one that people need occasionally,
      >>> ime.
      >>> Again, any comments feel free.
      >>>
      >>>
      >>
      >
      >
      >
      >
      > ------------------------------------
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
      > ! Groups Links
      >
      >
      >
    • Simon Kirk
      Hi Eb. I take your points, just a quick couple of thoughts: 1. By rail-roading their retrospective I meant that I didn t want to drive the retrospective solely
      Message 46 of 46 , May 1, 2008
      • 0 Attachment
        Hi Eb. I take your points, just a quick couple of thoughts:

        1. By rail-roading their retrospective I meant that I didn't want to
        drive the retrospective solely towards what I thought they needed to
        improve. If the team identifies something as an issues, it's probably
        best to aim to resolve that in some manner, even if I include a bit of
        a nod in the direction that I think they should improve. If I do
        decide to drive them towards something else I'd better have a good
        reason, and make the decision collaboratively with the team.

        2. A wider retrospective is something I would look for, too: I think
        there you're referring to the team providing me with change items, in
        much the same manner as Tobias suggested.

        3. My concern for the team is often not engineering related, despite
        my wont :)

        4. As for having the PO in retrospectives - well that's another thread
        that I'm about to start ;)

        Cheers for the answer.

        S

        On 27 Apr 2008, at 17:19, Eb wrote:

        > Simon,
        >
        > Thought I'd jump in here and offer a thought. I'll lead with the
        > general Lean / Systems
        > thinking viewpoint that you should avoid locale specific
        > adjustment / improvement efforts
        > and focus on tuning the whole beast.
        >
        > When you say that you don't want to railroad 'their' retrospective
        > (by adding more wider
        > change?), I think you should look to a wider retrospective format
        > that includes you and
        > maybe the wider business 'value' produced by your efforts.
        >
        > Its great that the team are keen to improve specific engineering
        > practices, I know from
        > experience how nice it is to focus your efforts on 'engineering
        > stuff' - but don't let them
        > become blind to the larger mission of delivering value to your
        > customer and business.
        >
        > The finest piece of code will not deliver value if, for whatever
        > reason it is functionally (biz
        > value) redundant. I think that's where you and the PO (and the rest
        > of your company) fit in
        > and why you need to bring that into the retrospective process.
        >
        > I don't think you need to add to the overall volume / amount of
        > change the team is
        > exposed to, but you could look at wider, smaller, incremental
        > change. I think an
        > organisation can evolve but you need 'everything' to change, a
        > little, all at once: rise,
        > repeat.
        >
        > Cheers,
        > Eben
        >
        >
        > --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@...> wrote:
        >>
        >> Hi Tobias.
        >>
        >> I thought I'd start a new thread on this riff since it's slightly
        >> departing from my original subject.
        >>
        >> Using the Scrum process as you admonish is exactly what I'd like to
        >> do. However, even when we're doing two-week sprints (thus getting a
        >> significant amount of retrospective chances), the amount of change we
        >> can come up with AND effectively act on is pretty limited. A team's
        >> "Specific Change Capacity" (to crib a physics term) is really a
        >> fairly
        >> small amount (I have seen it written in this list before by Esther
        >> Derby iirc that the same is true for organisations, that being they
        >> can only absorb so much change at a time, making Agile adoptions a
        >> drawn-out process).
        >>
        >> Assuming that to be true and bearing it in mind: My team is very much
        >> focussed on improvements on their Agile technical practices (pair
        >> programming, test coverage, continuos integration, etc etc). I am not
        >> about to rail road their retrospectives towards what I think they
        >> should prioritise (particularly as I recognise the very pressing need
        >> for improvements in all the areas they identify anyway), so where
        >> does
        >> the time come for the kind of individual growth via retrospectives
        >> we're talking about here when my team is so busy changing everything
        >> else?
        >>
        >> S
        >>
        >> On 27 Apr 2008, at 01:25, Tobias Mayer wrote:
        >>
        >>> Hi Simon.
        >>>
        >>> Whatever it is you are looking for... affirmation, criticism,
        >>> guidance... I think you are looking in the wrong place.
        >>>
        >>> Firstly most performance reviews, even the 360 one you are using are
        >>> linked directly to salary adjustments. This is inherently flawed as
        >>> Mary Poppendieck points out (as quoted
        > here:http://runningagile.com/2008/01/22/review-process-for-agile-team-members/)
        >>> .
        >>>
        >>> Secondly, even if the performance review is decoupled from the
        >>> salary issues I still think it is a flawed and outmoded idea. Such
        >>> a review process sets up a fake environment, far removed from our
        >>> everyday work context. As a result people behave differently and
        >>> the feedback offered generally bears little relation to true
        >>> feelings and interactions.
        >>>
        >>> Chad Eaves stated: In order for feedback to be of value, people need
        >>> to feel safe in giving it. This is undeniably true. Setting up a
        >>> special feedback environment (the review process) is not going to
        >>> create that safety. On the other hand, a familiar and routine forum
        >>> perhaps will, so use your retrospectives to find what you are
        >>> looking for. Perhaps it is time to take the retrospective to
        >>> another level -- a more personal one that is born of camaraderie and
        >>> trust -- and yes, courage.
        >>>
        >>> Thirdly, I am passionately opposed to any form of anonymous
        >>> feedback. I believe it is absolutely without value. Performance
        >>> Reviews promote the idea of hiding information (i.e. hiding the
        >>> identity of the reviewer). This is destructive and causes all kinds
        >>> of unresolved, and unresolvable, bad feelings to be surfaced and to
        >>> linger. In a retrospective setting we are accountable for the words
        >>> we speak. Accountability is an essential feature of a healthy Agile
        >>> environment, and one we should always be promoting. It is, after
        >>> all, an element of transparency.
        >>>
        >>> So I want to suggest that anyone on this list struggling with how to
        >>> run performance reviews, simply throw the whole concept into the
        >>> trash (it usually represents massive waste) and use the Scrum
        >>> process to continuously provide the kind of honest and truthful
        >>> feedback we all need as workers, as humans.
        >>>
        >>> Tobias
        >>> http://agilethinking.net
        >>>
        >>>
        >>>
        >>> --- In scrumdevelopment@yahoogroups.com, Simon Kirk <scrum@> wrote:
        >>>>
        >>>> Hi Chad.
        >>>>
        >>>> Nice points!
        >>>>
        >>>> I find it interesting that a significant percentage of the talks I
        >>>> attended at last year's Scrum Gathering in London (Roman Pilcher's
        >>>> Product Owner talk sprints to mind as an example) had a sheet
        >>>> asking
        >>>> for explicit and immediate feedback on his course, while the
        >>> gathering
        >>>> as a whole had a wall for providing feedback on the gathering
        >>> itself.
        >>>> I'm sure that Chicago's one did, too.
        >>>>
        >>>> So maybe giving such feedback is seen as safer, in an agile
        >>> environment?
        >>>>
        >>>> I hope I've grown enough feeling of safety in the team by now, but
        >>>> it's well worth keeping in mind. Thanks.
        >>>>
        >>>> S
        >>>>
        >>>> On 26 Apr 2008, at 15:59, Chad Eaves wrote:
        >>>>
        >>>>> A big obstacle in feedback is human nature and cultural, I
        >>> believe.
        >>>>> Far too often, people are not accustomed to being asked for their
        >>>>> feedback, especially if it is directed towards a boss/employer-
        >>> type
        >>>>> person. I teach a Junior Achievement class once a week and asked
        >>>>> senior students for feedback on my presentation and they looked
        >>>>> stunned. Getting them to offer feedback is one of my goals in my
        >>>>> course. I'll let everyone know how that is at course end.
        >>>>>
        >>>>> In order for feedback to be of value, people need to feel safe in
        >>>>> giving it. Unfortunately, companies have undermined this value.
        >>>>> How often has an "anonymous" survey tool turned out not to be so?
        >>>>>
        >>>>> Unfortunately, fostering this safe feeling takes time. And as we
        >>>>> all know, that is something we usually do not have an excess of on
        >>>>> projects.
        >>>>>
        >>>>> Without surmounting the personal security issue, great questions
        >>> may
        >>>>> yield little value.
        >>>>>
        >>>>> Chad Eaves
        >>>
        >>> ---------------------
        >>>>>>> Original Post...
        >>> On Thu, Apr 24, 2008 at 6:08 PM, Simon Kirk scrum@
        >>> wrote:
        >>>
        >>> Hi all.
        >>>
        >>> We're going through performance reviews at the moment and I've been
        >>> trying really hard to move away from the traditional small-company
        >>> quick chat, pat on the back and on-you-go for another year "review"
        >>> process that has been my experience for the companies I've worked at
        >>> before.
        >>>
        >>> On the other hand I abhorred the thought of going down an ultra-
        >>> bureaucratic HR-style route such as I imagine happens in big
        >>> companies. Instead some Googling turned up this, which so far
        >>> seems to
        >>> be going well:
        >>> http://runningagile.com/2008/01/22/review-process-for-agile-team-members/
        >>> (really it's Jeff Sutherland's original posting on an Agile Team
        >>> review process, but with some additional quotes at the start and a
        >>> bit
        >>> of tidying).
        >>>
        >>> Now, I was thinking about how I as the Scrum Master could get
        >>> reviewed
        >>> by my team - if 360 degree feedback is good for them, surely it's
        >>> good
        >>> for me? One of my team also asked for an opportunity to "review the
        >>> reviewer", but nowhere can I find good examples of how a Scrum
        >>> Master
        >>> can be evaluated, let alone by his or her team.
        >>>
        >>> For instance, taking the above URL as context, I'm not sure what the
        >>> right questions are the team should be asked about me.
        >>>
        >>> Has anybody got any pointers, I'd really appreciate the help?
        >>>
        >>> Thanks,
        >>> Simon
        >>>
        >>> ps. No more yearly reviews, either: I've taken this opportunity to
        >>> move to two monthly, despite the additional overhead. If anybody has
        >>> any comments on that I'd be happy to hear them, too.
        >>>
        >>> pps. Yes, we do Sprint retrospectives: they're brilliant, but
        >>> sometimes they lack the one-on-one that people need occasionally,
        >>> ime.
        >>> Again, any comments feel free.
        >>>
        >>>
        >>
        >
        >
        >
        >
        > ------------------------------------
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
        > ! Groups Links
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.