My friend and agile “ninja” Chad Holdorf (http://www.scaledagiledelivery.com/about/) just put up a nice post with a video and graphic explanation of the value of organizing around Features, rather than Components. For context, Chad is using the Agile Enterprise Backlog Model (and the Big Picture: Scaled Agile Delivery Model) as his organizational model for scaling agile, so the many of the terms and graphics he uses come from there. In addition, Chad has worked with Kenny Rubin on this topic and Kenny provided some nice slides to support the verbal explanation as well.
Chad’s new post is here: http://www.scaledagiledelivery.com/2011/04/28/component-vs-feature-team/
In this post, Chad does a great job of describing the complexities of delivering value when teams are organized around the components of a larger system, as opposed to the features or value streams that deliver the end result to the customer.
In my view, Chad correctly describes that its not an “either/or”, rather it’s a mix and Chad recommends that an agile enterprise should run about 70-30 or 60-40 of feature teams to component teams. I generally agree with this rough heuristic. Certain components are highly complex in nature, some perhaps use different technologies than the rest of the system, (typically lower level languages and protocols) and some can provide substantial economies of scale with reuse across the organization. Those components are best handled by small teams dedicated to building the most robust and scalable component they can. However, every interface to a component creates a dependency, so MOST of the agile enterprise should be organized to rapidly deliver feature value to the customers, and Chad describes why these efficiencies are so much greater with a feature team approach.
As I described at length in Agile Software Requirements, (Chapter 4: Agile Requirements for the Program), this is a nontrivial topic and I suggested that the discriminator should be along two axis, 1) complexity and uniqueness of the component technology, and 2) degree of reuse. This is illustrated by the following figure.
Feature Team vs. Component team Discriminator
For the area above the curve, component teams can be the most efficient, but MOST teams should fall below the curve, and that’s the area that Chad highlights for fastest value delivery.
Thanks Chad (and Kenny).
Scaling Software Agility 
This model / mixture seems notional. Do you have any studies showing correlation between the two variables in the graph and the ‘optimal’ mixture of component and feature teams…and then how that affects productivity and quality of team output?
Yes, its notional and only a heuristic. But in my project base, I have seen large programs that run as much as 60-40 component/infrastructure vs features, and at least one that runs more like 80-20 feature teams/programs. Planning and execution in the latter case is just easier, for the reasons Chad and Kenny describe. One recent agile enterprise reorg was a major realignment into 12 vertical value streams, with only three horizontal/component/programs. This is intended to accelerating delivery velocity and it obviously creates a far lower number of dependent stories (less work); not to mention more facile end to end feature testing. It’s the simple physics of fewer dependencies plus increased value delivery focus that drives improved results in a feature team/program.