--- In extremeprogramming <at> yahoogroups.com, Ron Jeffries
<ronjeffries <at> X...> wrote:
>
> On Thursday, October 13, 2005, at 3:23:18 PM, Dave McMunn wrote:
> 
> > One way we have found that helps prevent scope creep is to have
> > the client essentially put a value on each story.[...]It
> > helped the customer tremendously to get out of the emotion of what
> > they desired and really focus on how it moved the application
> > forward to achieving the business objectives.
> 
> Dave, I'd have said at first glance that this notion is somewhat
> counter to the whole agile notion of embracing change.

> Ron Jeffries

Ron,
Would you care to take a second glance at Dave's report and then
explain how it is that knowing what the value of the (outputs of
building) a story is works against embracing change?

A related case: I've seen an agile team cranking away, release after
relese, nice healthy "velocity", but still be the whipping-boys for
poor business performance because they were percieved as wasting time
building worthless things. Planning games became shouting matches
between proxy customers all yelling that their real customer was the
bigger and hairier, or that their strategic internal project was the
more important, and so on. No effective steering from the business.
Disaster. The developers were pulled from pillar to post, faced with
more change than they could hope to cope with, wether they embraced it
or not, as one political agenda or account manager's whim won at
successive planning games.

This was fixed almost instantaneously by requiring the proxy customers
to submit purchace orders for the cost of development of their
stories. This wasn't an ISV but a service company, so all these PO's
represented was the company moving money from one pocket to
another--but they focussed attention. 

Most importantly a proxy customer (now accountable for the cost of
developing their stories) had to obtain signoff from their
budget-holding manager to raise a PO, and in the usual business way
they could only do that off the back of a well-qualified revenue
projection or a PO from the real customer. A measure of the value of
putting their stories into production. Bang! All of a sudden planning
games were short, effective and civil. All of a sudden the priorities
for this, the next, and the iteration after that were crystal clear.
The team changed from cranking out points of "speed" to cranking out
points of velocity in the direction of ROI (unit vector: GBP). 

Real changes in business need (rather than chages in whim) still
occured, could be identified, qualified and executed in just as timely
a fashion as before. In fact, I'd estimate that the time taken to
qualify a story properly and have it scheduled at the natural point in
time was less than the time taken to bully and horse-trade it in uner
the old scheme. So change was able to be responded to faster, with
better visibility, and better control.

I don't understand which bit of this was a reduction in agility.

Keith

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/