First, thanks to Ron, Bill, and Jim for the feedback. I'll address Bill's specifically here.
> From: William Wake [mailto:[EMAIL PROTECTED] > Sent: December 29, 2004 11:27 PM > > 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? My bad. That was obvious to me, but I wanted to dig further to see if there were any common signs that things would be better left unbundled. As you mentioned, your scenario had more obvious signs. > > 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.) Product "Road-maps" aside, how would you work with a product-based customer that is without a hard and fast road-map? To me, it is not necessarily that uncommon for a product-based company working in a world of changing requirements (external and internal) to not have a product road-map passed the current release. More common is a dot on the horizon which is the overall "vision" for the product, but I find that the placement of that "dot" will vary as feedback is received on the last release and thus the road-map will only become visible by driving through the fog. I like the idea of trying internal "betas", but this is not always feasible for employees. Perhaps the software is boring or not applicable for internal use. I have had experience working for these types of software companies -- I looked forward to getting home to use / work on other software. :) Examples can be found in most back-end enterprise systems. Thanks again for the feedback. Cheers and Happy New Year, Tom 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/
