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

Re: [agile-usability] I smell a rat! Or is it just stinky cheese?

Expand Messages
  • William Pietri
    Hi, Faith! Good to hear from you. Let me answer your two questions in separate posts. ... I think the bad estimates should be pretty easy to fix. There I d use
    Message 1 of 10 , Oct 6, 2008
    • 0 Attachment
      Hi, Faith! Good to hear from you. Let me answer your two questions in
      separate posts.

      faithbolliger.sanfran wrote:
      > Further, if there is a known feature that a particular dev does not like he will first
      > challenge the heck out of it's value. In general I am fine with this, kicking the tires is
      > good. However when the value to the user is demonstrated, I am guaranteed in the
      > estimation and planning meetings he will continue to throw high numbers, just change his
      > argument. On our team, we always plan with the highest number thrown. It's obvious his
      > are high because on average he is lower than others and usually when he throws a high
      > number relative to the others it is notably high.
      >

      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.


      William
    • William Pietri
      ... I m sure there are a lot of approaches to this, but here are the ones that occur to me. I m sure there will be plenty of answers here, but I can think of
      Message 2 of 10 , Oct 6, 2008
      • 0 Attachment
        faithbolliger.sanfran wrote:
        > [...] do you have advice on illuminating or correcting teams that have a
        > tendency to low-ball their overall expected velocity [...]



        I'm sure there are a lot of approaches to this, but here are the ones
        that occur to me. I'm sure there will be plenty of answers here, but I
        can think of six actions to take:


        The first thing I'd look at is the physical arrangement of the people.
        Put the product manager(s) and the developers (at least the local ones)
        all in the same physical space. Everybody should be able to see
        everybody else, and be able to get attention with little more than a
        wave or a slightly raised voice.

        Then I'd consider shifting to using relative estimates and Yesterday's
        Weather as a technique for deciding how much work to take on. Keep an
        estimated backlog of at least two iterations worth of work, and feel
        free to ask for more estimates as needed to have a clear plan.

        Third, I'd use short iterations. With a six-week release cycle, I'd go
        with one- or two-week iterations. Preferably one.

        Fourth, I'd look at why they might be sandbagging. That can be an
        adaptive behavior in many circumstances. If they are in one of them, you
        have to fix that first. And if they just picked the habit up elsewhere,
        they may need support in unlearning that.

        Fifth, consider whether business-side expectations for the team's
        productivity are too high. Maybe 80% of the teams I evaluate have a
        business-side fear that developers aren't productive enough, and the
        number one response to that is to get people to work more hours. This is
        rarely effective, and usually counterproductive, sometimes drastically so.

        And lastly, find ways to get developers to share your motivations. If
        they're doing work just because somebody tells them to, they won't be
        fully engaged. Instead, get them interested in solving the problems you
        want to solve. Help them to care about the things you care about. Then
        they'll be looking for ways to be more productive on their own, without
        external prodding.


        Feel free to ask if you'd like more detail on any of these.


        William
      • aacockburn
        Fabulous answers, William --- much better than I could have come up with! - cheers - Alistair
        Message 3 of 10 , Oct 6, 2008
        • 0 Attachment
          Fabulous answers, William --- much better than I could have
          come up with!
          - cheers -
          Alistair
        • Dave Rooney
          William Pietri wrote: [snip] ... At one client, the effect of having the business people co-located with the developers resulted in a business analyst
          Message 4 of 10 , Oct 7, 2008
          • 0 Attachment
            William Pietri wrote:

            [snip]

            > Fifth, consider whether business-side expectations for the team's
            > productivity are too high. Maybe 80% of the teams I evaluate have a
            > business-side fear that developers aren't productive enough, and the
            > number one response to that is to get people to work more hours. This is
            > rarely effective, and usually counterproductive, sometimes drastically so.
            >

            At one client, the effect of having the business people co-located with
            the developers resulted in a business analyst commenting on just how
            much work went into implementing a single story. She knew there was
            work, but when the developers enumerated the tasks required she was
            quite surprised at just how much.

            Yet another reason to co-locate - TRUST! :)

            Dave Rooney
            Mayford Technologies
            "Helping you become AGILE... to SURVIVE and THRIVE!"
            http://www.mayford.ca
            http://practicalagility.blogspot.com
          • 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 5 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 6 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 7 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 8 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.