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

Re: I smell a rat! Or is it just stinky cheese?

Expand Messages
  • faithbolliger.sanfran
    Hi William Thanks for your thoughtfulness. ... We do use planning poker, although the team does not like Fibonacci count and have settled on a system of .5, 1,
    Message 1 of 10 , Oct 8, 2008
    • 0 Attachment
      Hi William
      Thanks for your thoughtfulness.

      You said:
      > I think the bad estimates should be pretty easy to fix. There I'd use
      > one of the Delphi method variants:
      >
      > http://en.wikipedia.org/wiki/Delphi_method
      >
      > The one I normally use is Planning Poker:
      >
      > http://www.planningpoker.com/detail.html
      >
      > In particular, I'd require that the team come to consensus on an
      > estimate. If after a few rounds they can't, then have them explicitly
      > identify the core of the disagreement, and give them explicit research
      > time to resolve the difference. If everybody has to agree, they'll
      > challenge one another's estimates, and I'm sure you won't be the only
      > one to catch onto this pattern.

      We do use planning poker, although the team does not like Fibonacci count and have
      settled on a system of .5, 1, 2, 3, 4, 5

      On a side note: I continuously struggle to understand this in terms of real time, it's total
      felt experience for me. Particularly towards the end of the release when there are scraps
      of work to be done I feel as if our units of measurement are unhelpful. My lead tech will
      talk about the need to give each individual story a measurement even if it doesn't seem
      worthy of say .5 because the sponsor needs to know there is a "cost".

      This perspective of everything having a cost, feels more like stick than carrot (value).

      Back to issue at hand: So the dev team collectively throws estimates in our planning
      sessions, but as a rule of thumb we take the highest estimate. I do see devs challenge
      each other occasionally but not often. In cases of one specific tech lead, if this person
      doesn't like a story he will continue to throw high numbers. I have noticed a pattern that
      kills further discussion, the dev will say "well it still think there is complexity we aren't
      seeing and therefore I am not comfortable with anything lower than X pts".

      I would like to change this rule of thumb that we go with the highest estimate. Do others
      have this policy?

      fb
    • faithbolliger.sanfran
      William - More great feedback on co-location, sprint cycle, hours, business expectations and shared team goals/motivation. Unfortunately our teams are not
      Message 2 of 10 , Oct 8, 2008
      • 0 Attachment
        William - More great feedback on co-location, sprint cycle, hours, business expectations
        and shared team goals/motivation.

        Unfortunately our teams are not co-located, we are in 4 different locations. And there is
        no actual daily overlap between 2 of those locations, except for sprint planning.

        We are on a 2 week sprint cycle, we used to do 1 week sprints which I liked but the devs
        felt it required too much work to get build stable, too much time required to prep for the
        demo and hence we had loads of hangover. To some degree we have less hangover. And
        we have worked hard to get the team to understand the demos need not be so formal, etc.

        The devs are working 40 hours if not less. We are a team of outsourced and offshore
        partners plus some onshore distributed contractors. I know the contractors have other
        clients and am confident this is some of the drain on velocity at times. I have traveled to
        work at our offshore partners location and know they keep 40 hours plus time during the
        day is playful. I don't think we are overworking them.

        Business expectations are probably misaligned. Although after 9 months now with this
        team, expectations have been significantly lowered. In my opinion, to the detriment of the
        team.

        How do others get outsourced, offshore, distributed teams to motivate? I could get better
        at motivating!

        What is the success rate for a distributed, outsourced team models?

        fb
      • marjoriepries
        ... terms of real time, it s total ... release when there are scraps ... unhelpful. My lead tech will ... even if it doesn t seem ... a cost . ... Everything
        Message 3 of 10 , Oct 8, 2008
        • 0 Attachment
          --- In agile-usability@yahoogroups.com, "faithbolliger.sanfran"
          <faith.bolliger.ny@...> wrote:
          >
          >

          > On a side note: I continuously struggle to understand this in
          terms of real time, it's total
          > felt experience for me. Particularly towards the end of the
          release when there are scraps
          > of work to be done I feel as if our units of measurement are
          unhelpful. My lead tech will
          > talk about the need to give each individual story a measurement
          even if it doesn't seem
          > worthy of say .5 because the sponsor needs to know there is
          a "cost".
          >

          Everything that takes time to do, does have a cost. I'm guessing
          these things you call "scraps of work" are tasks necessary to
          get "release-ready" but maybe task lines are being drawn too finely
          in order to have something that looks like a "story." If so, then
          perhaps certain things could be grouped together under traditional
          PMO-sounding tags so that they have more weight and visibility.
          Without hard examples of these things you call "scraps" I'm not sure.
          Maybe even some old-fasioned bug logging and tracking would resolve
          it.


          > This perspective of everything having a cost, feels more like stick
          than carrot (value).
          >
          > Back to issue at hand: So the dev team collectively throws
          estimates in our planning
          > sessions, but as a rule of thumb we take the highest estimate. I
          do see devs challenge
          > each other occasionally but not often. In cases of one specific
          tech lead, if this person
          > doesn't like a story he will continue to throw high numbers. I
          have noticed a pattern that
          > kills further discussion, the dev will say "well it still think
          there is complexity we aren't
          > seeing and therefore I am not comfortable with anything lower than
          X pts".
          >
          > I would like to change this rule of thumb that we go with the
          highest estimate. Do others have this policy?
          >
          > fb
          >

          We don't go with the highest estimate. We go with the consensus or
          most frequent estimate. That means we have a discussion about the
          extremes. Can your tech lead get more specific, in a general way,
          about his/her concerns? That is, can they enumerate aspects of the
          card and relate them to previous examples or projects where surprises
          happened? Perhps a trained facilitator could help with that.

          And is it important that they get more specific? What I mean is, if
          the track record for every card where they've voted high has
          generally proven to have hidden complexity, then as a member of the
          team, I am going to stop niggling over every card where this happens
          and vote with the expert knowing that in time I'll experience what
          he/she suspected and be better able to smell the smells and
          articulate the concerns myself.

          A lot of times, teams that have been together long function this way
          because it's just more efficient to stop talking and start working.
        • William Pietri
          Hi, Faith. Great questions. Do you have any data handy? For example, I d love to see the velocities in each of the iterations for the last release. And maybe
          Message 4 of 10 , Oct 8, 2008
          • 0 Attachment
            Hi, Faith. Great questions.

            Do you have any data handy? For example, I'd love to see the velocities in each of the iterations for the last release. And maybe the individual story estimates from a typical iteration and one you think was off, like that bit right before release?

            Thanks,

            William

            faithbolliger.sanfran wrote:
            Hi William 
            Thanks for your thoughtfulness.  
            
            You said:
              
            I think the bad estimates should be pretty easy to fix. There I'd use 
            one of the Delphi method variants:
            
                http://en.wikipedia.org/wiki/Delphi_method
            
            The one I normally use is Planning Poker:
            
                http://www.planningpoker.com/detail.html
            
            In particular, I'd require that the team come to consensus on an 
            estimate. If after a few rounds they can't, then have them explicitly 
            identify the core of the disagreement, and give them explicit research 
            time to resolve the difference. If everybody has to agree, they'll 
            challenge one another's estimates, and I'm sure you won't be the only 
            one to catch onto this pattern.
                
            We do use planning poker, although the team does not like Fibonacci count and have 
            settled on a system of .5, 1, 2, 3, 4, 5
            
            On a side note:  I continuously struggle to understand this in terms of real time, it's total 
            felt experience for me.   Particularly towards the end of the release when there are scraps 
            of work to be done I feel as if our units of measurement are unhelpful.  My lead tech will 
            talk about the need to give each individual story a measurement even if it doesn't seem 
            worthy of say .5 because the sponsor needs to know there is a "cost".  
            
            This perspective of everything having a cost, feels more like stick than carrot (value).
            
            Back to issue at hand:  So the dev team collectively throws estimates in our planning 
            sessions, but as a rule of thumb we take the highest estimate.  I do see devs challenge 
            each other occasionally but not often.  In cases of one specific tech lead, if this person 
            doesn't like a story he will continue to throw high numbers.  I have noticed a pattern that 
            kills further discussion, the dev will say "well it still think there is complexity we aren't 
            seeing and therefore I am not comfortable with anything lower than X pts". 
            
            I would like to change this rule of thumb that we go with the highest estimate.  Do others 
            have this policy?
            
            fb
            
            
            
            
            
            ------------------------------------
            
            Yahoo! Groups Links
            
            <*> To visit your group on the web, go to:
                http://groups.yahoo.com/group/agile-usability/
            
            <*> Your email settings:
                Individual Email | Traditional
            
            <*> To change settings online go to:
                http://groups.yahoo.com/group/agile-usability/join
                (Yahoo! ID required)
            
            <*> To change settings via email:
                mailto:agile-usability-digest@yahoogroups.com 
                mailto:agile-usability-fullfeatured@yahoogroups.com
            
            <*> To unsubscribe from this group, send an email to:
                agile-usability-unsubscribe@yahoogroups.com
            
            <*> Your use of Yahoo! Groups is subject to:
                http://docs.yahoo.com/info/terms/
            
              

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