On Wed, 29 Dec 2004 12:33:30 -0500, Thomas Robbs
<[EMAIL PROTECTED]> wrote:
> > Well, in the case at hand, the customer proxy was bundling things that
> > would be better left unbundled. ("I won't release unless I get all
> > this stuff: they're all equally important.")
>
> How/When were you able to determine that the "things" would be better
> left unbundled?
In the case I mentioned in the article, some features were needed
because of a regulatory deadline, others were "just" good ideas. It
was an easy call to me: why risk making the regulatory part late?
> I've heard the "it's all important" statement numerous times. I usually
> see a small light go on when I ask pointed questions about why they
> choose to wait for X iterations (X being the number of iterations
> required to deliver all things that are equally important) before
> beginning to realize a return on their investment.
Yes.
> Sometimes I do not. This seems to be more apparent in product-based
> development, i.e. say Microsoft releasing a new version of Office - they
> don't actually release until it's "complete" (settle down with the
> tomatoes, I'm just using an arbitrary example :)
>
> How would you explain the benefits of unbundling to the Customer in that
> context?
There's complete and there's complete. "Joel on Software" has a nice
article about all the features they wanted to squeeze into Excel, but
went back later & realizing they were mostly dogs. (Sorry, can't find
a link.)
But let's say we think Office has new, good things to add. I think
they're making conscious decisions about what to bundle or not. (They
make these decisions both sequentially - for a product over time - and
as a block - what goes in the Office bundle.)
> > I have on occasion heard (from both the customer side and the
> > development side) that they don't see the value in breaking something
> > up. But the ability to unbundle can unlock extra value and reduce
> > risk.
>
> How would you try to explain the value, if indeed it is there?
The two things I tend to focus on are early returns and lowered risk.
I'd welcome other things to talk about though:)
> But further, what warning signs do others see when things were:
>
> a) not unbundled when they should have been,
> b) bundled incorrectly, and
> c) unbundled too much?
>
> ... if such scenarios have manifested themselves for you.
>
> Below are some signs that I have recognized:
>
> a) - stories aren't being completed within the iteration
> - stories are being split frequently
> - during implementation, deep dependencies are uncovered that weren't
> previously obvious
>
> b) - stories are being split frequently
> - pairs are working a story in completely different directions and
> rarely find a need to collaborate regularly
I don't think I've seen things "too unbundled"; I guess if I saw a lot
of fiddly overhead and teensy stories I'd worry. But I think we
actually have a bit to learn about splitting more rather than less.
I've certainly, as you have, seen stories that didn't get done in an
iteration, or ones where I felt more valuable parts were mixed with
less valuable ones. But I have more to learn here too.
--
Bill Wake [EMAIL PROTECTED] www.xp123.com
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
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:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
