Even in the case of Office, MS has started "eating its own dog food" - using early versions of Office in-house. So, even in the case of MS Office, internal value is increased by unbundling features, implementing them in order of utility, and frequently releasing new versions internally. Also, there is development value and decreased risk in the more frequent and more focussed feedback obtained by releasing features in smaller increments.
-----Original Message----- From: Thomas Robbs [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 29, 2004 10:34 AM To: [EMAIL PROTECTED] Subject: RE: [XP] New XPlorations article: "Customer Value: Unbundling", and some reviews Hi Bill: Thanks for the response. I've run into this situation regularly when introducing people to the Planning Game. I appreciate your explanations and have a few further questions. > From: William Wake [mailto:[EMAIL PROTECTED] > Sent: December 28, 2004 9:20 AM > > 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? 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. 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? > > If I may, when I first read the article, I drew my own conclusion that > > the prioritization process may be an exercise in bundling, unbundling, > > and re-bundling -- a careful dance between customer and development > > team. My colleague, while agreeing that there might be connections > > across the topics, he stopped me from prematurely connecting the dots. > > I might say that the "planning" process is an exercise in bundling > etc., and prioritization is part of that. And I agree that the "dance" > is often there (but sometimes there's no dance as one side can't see > the value). > > 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? > > Which brings me to the second point... > > > > How does the choice to bundle or not relate to prioritization? The > > conclusions seem after-the-fact (i.e. post prioritization) rather than > > re-focusing on the prioritization problem. > > I'd say there's two ends to it. One is just the question of what you > decide goes together in, say, a release. This may be a loose bundling > (though sometimes it's more coupled than that). > > Another issue is that the stories are not a given. Reworking a story > by unbundling its pieces can let you prioritize the whole thing > differently. (This splitting can happen during the planning > conversation.) > > Consider two stories A and B versus their "split" versions A1, A2, A3, > and B1, B2, B3. If you work with big chunks, you have one decision: "A > then B" or "B then A"? If you work with finer pieces, you have a bunch > of alternatives; A1/A2/A3/B1/B2/B3 and B1/B2/B3/A1/A2/A3 are only two > of the possibilities. If you unbundle, you may decide B3+A2 is the > most valuable piece, deliver it first, and start booking revenue > sooner. That was indeed the "careful dance" that I was suggesting, if, as you pointed out, both sides play nicely together. :) 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 have some overlap, but it's a quick retrospective of some recent projects. I've tried using the various "rules of thumb" for story/task sizes, but find that some would still like to have more women working on that baby, so-to-speak, than spending mental cycles on unbundling and, if needed, rebundling. > And I hope my reply was as clear as Virginia's bright blue sky today. > And thanks for reading! Definitely. I feel that we're on the same wave length (please advise if you feel otherwise ;). Now I'm curious about diving in further. Thanks again for the reply. 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 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/
