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

[faithbolliger.sanfran]

Hi,

As a product owner, do you have advice on illuminating or correcting teams that have a
tendency to low-ball their overall expected velocity and/or throw bad (high) estimates at
work they don't want to do?

I am working on a project with all contract developers, some on and some offshore.  This
team has been working together since the beginning of the year so I feel that I have come
to understand them very well.  Also I have worked with some individuals on other projects
over the past couple years and have gotten to know them & their behaviors well.  

It has become clear through many conversations that they like to work at a certain
comfortable velocity and will do anything to maintain it.  A short while ago we released a
product and have entered a new year long phase of enhancements -  6 week releases to
further build out the product.  It was decided that the team should reconsider their
velocity and ended up planning for a much lower velocity going forward.  I agree with
some of the reasons cited, such as personal and national holidays.  But in general -  I am
confident that expectaitions are significantly lower that what they should be.  I would be
fine with as long as if/when they finish work early they continue to pick up more work.  
This is not the case.  Moreover, I believe they intentionally discouraged doing more work
because they will only estimate sprint stories until they reach their expected velocity and
we only pick up work that has been estimated?

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.  Typically this has the effect of
discouraging the sponsor to prioritize this work and/or we are forced to look for less
optimal experiences that are technically easier to develop.

I feel like this team is steering to product not to deliver value but to maintain comfort.

Suggestions?
fb

[Jon Kern]

Wow. I am sure it is hard to describe an entire team culture and
experience in an email. But it sure sounds like you have quite a fun
challenge. Gulp.

Developers challenging the value of a business request?
- maybe your requests are too solution-oriented (versus business) and
the developer has a valid point?
- maybe the developer needs to be sat down and told to fly right or get out?
- somewhere in between?

Plan for a lower velocity?
- because you routinely over-chose issues and always have 50% completion
rates?
- because you worked them to the bone, requiring 60 hour weeks for 12
months and they are burnt out?

Why do you think they are "low-balling" their estimates? How do you
measure whether something seems out of whack?

Let's assume you have a dysfunctional team... you could
- raise it in a team setting and have a group discussion to get to the
bottom of the issue
- bring in some new blood that you trust to be exceedingly competent
- bring in an outside observer to go through the various "sides" and
gather intel
  (I always love conducting these sorts of "software therapy" sessions.)
- fire/reassign one or two posers and see if the others snap to attention

Could you be misconstruing their "push back?" Maybe it is justified
because of aspects they have not been able to properly share with you?

Maybe you could try to do more group estimating... so others might
challenge estimation assumptions -- not just you.

All I can say is that what you experience sounds real. I wouldn't put up
with it. I would either figure out if it was me, the business, the
process, or the developers -- and try to resolve the issues. Otherwise,
nobody is having that much fun...

jon


blog: TechnicalDebt.com <http://technicaldebt.com>
     View Jon Kern's profile <http://www.linkedin.com/in/jonkern>


faithbolliger.sanfran said the following on 10/6/08 2:47 PM:

>
> Hi,
>
> As a product owner, do you have advice on illuminating or correcting
> teams that have a
> tendency to low-ball their overall expected velocity and/or throw bad
> (high) estimates at
> work they don't want to do?
>
> I am working on a project with all contract developers, some on and
> some offshore. This
> team has been working together since the beginning of the year so I
> feel that I have come
> to understand them very well. Also I have worked with some individuals
> on other projects
> over the past couple years and have gotten to know them & their
> behaviors well.
>
> It has become clear through many conversations that they like to work
> at a certain
> comfortable velocity and will do anything to maintain it. A short
> while ago we released a
> product and have entered a new year long phase of enhancements - 6
> week releases to
> further build out the product. It was decided that the team should
> reconsider their
> velocity and ended up planning for a much lower velocity going
> forward. I agree with
> some of the reasons cited, such as personal and national holidays. But
> in general - I am
> confident that expectaitions are significantly lower that what they
> should be. I would be
> fine with as long as if/when they finish work early they continue to
> pick up more work.
> This is not the case. Moreover, I believe they intentionally
> discouraged doing more work
> because they will only estimate sprint stories until they reach their
> expected velocity and
> we only pick up work that has been estimated?
>
> 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. Typically this has
> the effect of
> discouraging the sponsor to prioritize this work and/or we are forced
> to look for less
> optimal experiences that are technically easier to develop.
>
> I feel like this team is steering to product not to deliver value but
> to maintain comfort.
>
> Suggestions?
> fb
>
>  

[William Pietri]

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]

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

[Alistair Cockburn]

Fabulous answers, William --- much better than I could have
come up with!
 - cheers -
Alistair

[Dave Rooney]

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.  

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

[Marjorie H Pries]

--- In agile-usability@..., "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 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
>
>
>
>