Feature Teams Vs. Component Teams (continued)

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).

Resource Flexibility in The Agile Enterprise

I received this interesting email from a colleague (who allowed me to share it) a few days back.

“I currently lead a project on how to increase our resource fluidity so that we can effectively assign sufficient manpower to where it matters the most, e.g. working on the highest priority items on the backlog. We acknowledge the need for deeply specialized teams in certain areas and that drastic competence shifts are unrealistic, so the change project aims at finding out how many scrum teams do we need to make more fluid? What competences should these teams have, if they are to be deployed on a wider range of tasks? We also need to address change resistance such as designers or managers being protective of their work domain.

I wonder if you have any advice on how to increase resource fluidity and thereafter managing it.”

Best regards,

— Dr. Mikkel Mørup, Nokia Mobile Phones, Experience Portfolio Management

The email also reminded me of a visual on the same topic that I saw recently as well, which went something as follows:

Matching project backlog to team competencies

Even if we have driven the excess WIP out of the system, even if we can match capacity to backlog, even if we have shorter queues, even if we can build working software in a short time box, we still have to rapidly adjust resources to match the current backlog; that’s a big part of what makes us agile after all. But of course, it never really matches. So we constantly struggle to make the best of the situation, and yet who wants to be the epic owner (or project manager) for Epics (epics 7&8 above) or a team member for Team 4 or 5? A number of awkward conversations and suboptimal economic solutions are likely to develop.

To address this problem generally, we need two things:

1)   Feature teams, which have the ability to work across the domains of interest (See feature teams/component teams category)

2)   Individuals with “T Skills”, i.e. people who are deep in one area and broad in many. (See Reinertsen: Principles of Product Development Flow, W12).

As agile as we hope to be however, this is a journey often measured in years, not weeks or months, and it is sometimes met with resistance from the enterprise, as Mikkel notes above. Resistance can come from:

–       individuals who are highly specialized experts,  and who may even see their knowledge of a domain and specialty as a form of job security

–       managers who control resources associated with a domain and who can be reluctant to share their resources (and implied base of power)

–       Individuals or managers who may have lost their technical thirst for “life long learning” and are comfortable in their existing skills and knowledge

–       Logistics and infrastructure (CI and build environments, branching structures, etc) that make it difficult to share code bases across teams

I’m posting this as I would like to hear some other opinions on the topic. As a kickstart, however, my initial response to Mikkel went something as follows:

1)   Make the objective clear. It is product development economics that drive us to this particular change vector, and in the end economics wins (or loses) the game for every enterprise. Make the business case based on economics of agility and flow.

2)   Make the value system clear. We value feature teams and T skills the most highly (yes, we value component teams too; but even there T skills are an asset). Embed the value system in the performance review/appraisal system to eliminate ambiguity about our expectations for individual career growth and advancement.

3)   Adopt XP like practices and values (simplicity, pair programming, collective ownership, single code line, etc.). Hire people with experience in these areas.

4)   Attack the infrastructure unremittingly. The technical blocks must be eliminated or the rest of the change program will far less effective.

For you other enterprise agilists out there, do you have thoughts and experiences that you can share?

Feature vs. Component Teams: Another Perspective

Hiren Doshi is doing a good job of describing various considerations around the feature vs. component teams discussion and on the practical  application of the three tier Big Picture model for larger and distributed enterprises, at his blog at www.practiceagile.com. His ongoing, experience-based perspective is lucid and practical so I’ve added his blog to the blogroll. For those interested in this thread, check out these posts on the feature vs component teams debate.

Organizing at Scale: Implementing Spanning Features

Prompted by the discussion of feature and component teams, a reader recently sent in the following question:

“I have a user story, that on its face, appears to have been structured in such a way that it simply cannot be independent.  That is, the story itself cuts across teams, and even across product lines.  If the story were to be broken down any further, it would only be into its constituent tasks.  Moreover, it appears the cross cutting nature of this story will lend itself to the necessity of creating a virtual team of sorts as it will take individuals from many teams to coordinate.  Moreover,  we have identified many new stories of this nature.

The team involved is rather large (300+) and spans several countries.  So I suppose what we may be looking at is one very large project team with many sub-teams and that many stories may impact many teams.  My first inclination is to suggest that if a story such as the one above exists, then it should be decomposed into smaller stories that each team can work towards.  However, I’m struggling with the lack of delivering anything tangible on a per story basis.”

Here was my response:

=============================================

Drew,

Your first inclination is generally the best one.  At enterprise scale, many features span teams. This is indeed the common case, especially as the customer value stream pile moves up the stack to where they are using multiple products, web services, or whatever, in new and innovative manners.  However, there should be no reason to create new teams, or programs, just to coordinate content of this type.

Don’t worry so much about the fact that each team-level story doesn’t appear to deliver user value by itself, (although you should take every opportunity to see if you can define team-level value stories that deliver value to their users too)  as that is taking the user value story metaphor too far. Since you can be dang certain that the bigger feature is delivering value to your customer, it doesn’t matter that some team is having to build an adapter-API –widget-whatever, or has to refactor some code that they wouldn’t otherwise have to refactor. It’s just part of what they do to deliver larger end-user value.

Indeed, this is such a common occurrence in the enterprise that the Big Picture was designed in part to address it: Here’s how it’s handled.

Big Picture

1. A Product Manager or program manager who understand the need for the bigger feature expresses it to the teams at the release planning boundary
2. During release planning, teams break the feature into smaller stories that that they deliver to the baseline in the iterations. (Note: In the lean and scalable agile requirements model, I don’t call these breakdowns tasks, as tasks are reserved for the individual activities to coordinate completion of a story).
3. A scrum of scrums, a release management team, the system team, or the program or product manager, helps coordinate the delivery of the feature over time. The system team, or some like construct, performs end-to-end level testing of the new feature.

If you are organized this way, you should be able to handle any number of larger spanning features. In the Big Picture, features and stories are just “content” to the teams prioritized backlog. The process just runs and runs, without the necessity for reorganization.

Whether currently organized by feature, component, product or service, if you attempt to reorganize every time a cross cutting feature comes along, everyone will spend too much time figuring out where their desk is or who the product owner is, and too little time cutting code.

Note: also see the following post on the same topic.

Organizing at Scale: A Basic Scrum Framework for Enterprise Teams

Recently, I was working with a smaller, but distributed, team that was trying to establish a basic framework for working together in a lightweight, Big Picture, enterprise pattern. We were rolling out a basic scrum practice for the individual teams, but one that lends itself to scaling well into enterprise release planning, and is also based on sharing and communicating sprint objectives, rather than just a prioritized backlog . (After all, what team or stakeholder wants to sort through another teams backlog just to understand what they are doing in a sprint?).

Based on a little background with the team, I assumed we were all working from the same playbook. Well surprise, surprise, there were many misunderstandings about the basic practices I thought we had standardized. That led to a variety of interesting conversations.  To clarify intent, I put this brief framework together and thought perhaps others might be able to use it as well.

One caveat though, while this is what I use to good effect, I make no claims that it would be a perfect fit in any other “Scrum team in the enterprise” context. Your mileage will vary, but here you go:

Sprint Pattern

Sprints are two weeks in length. Sprints for all teams start and stop at approximately the same day. Each sprint has a standard pattern. Plan the Sprint. Execute the Sprint. Demo the Sprint. Retrospective.

Plan the Sprint

1)   Presentation of objectives and stories by the product owner.

2)   Breakout. Team members work independently or in collaboration to understand intent and draft an acceptance test for each story. Teams use task/hour breakdown, or not, at their discretion.

3)   Commitment. Teams reconvene and commit to negotiated objectives and supporting stories for the Sprint. Commitments are made only by the team. Final objectives are stated in a sentence or two, in plain English, and are communicated to all stakeholders.

Execute the Sprint

Teams collaborate on achieving the objectives of the Sprint. Stories are discussed, elaborated, completed and demo’d to the product owner as available. Story (not task) status is maintained in “big visible chart”. Typical story states Backlog, Defined, In Progress, Complete, Accepted).
However, the objectives for the Sprint trump any particular story. Team (but not management) may refactor, add, or delete stories where necessary to achieve the Sprint objectives.

Demo the Sprint

Results of the Sprints for each team are demo’d to all team-aligned stakeholders. In the larger enterprise, an additional, aggregate, higher-level demo or “Feature Progress Review” may be necessary for program stakeholders.

Retrospective

Team conducts a short retrospective in two parts:

Objective (metrics) Review: Determine whether or not the team met the objectives of the sprint (yes or no). Collect any metrics team has agreed to, but teams must understand velocity, both for new development and that devoted to maintenance.

Subjective (process) Review. A typical format is: What Went Well? What Didn’t? What One Thing Will We Do Better Next Time?

Typical Sprint Ceremonies

In a two-week sprint, a typical meeting (ceremony) set is as follows:

Standard meeting set

Release Cadence

Releases (or Potentially Shippable Release Increments) are at approximately 90 day intervals (approximately 6-7 sprints per Release Increment). Teams may include stabilization (hardening sprints) or not based on quality, system level integrations, continuous integration capability and technical debt issues.

Release Planning

Release planning occurs at the beginning of every 90-day cycle. Release planning is typically one or two days, face to face wherever possible. All team members participate. A standard format is as follows:

• Review and retrospective on accomplishments of prior release.
• Executives communicate current business context
• Management presents solution Vision, including a prioritized list of features
• Teams break feature into stories, plan the Sprints based on known velocities, negotiate commitments with stakeholders.
• Teams identify risks and impediments. Each is discussed and addressed into categories as follows: (Resolved, Owned, Accepted, Mitigated.
• Teams (including management) restate (in plain language) team and aggregate objectives for Release, so that all stakeholders understand all objectives
• All present commit to release objectives, or planning continues until a commitment can be achieved.

Release Planning Output

The output is a set of clear objectives, along with a prioritized feature list, for the upcoming release increment.

Organizing at Scale: Feature Teams vs. Component Teams – Part 3

As the title indicates, in the last two posts (Part 1 and Part 2 – and also be sure and check the comments from others) I’ve described the conundrum of organizing agile teams at scale, and said I’d provide some additional input from others along with some recommendations.

Should the Agile Enterprise Lean to the Feature Team Approach?

Given the advantages and disadvantages to each approach – essentially the balance of immediate-value-delivery vs. architectural focus and potential for reuse, the agile enterprise clearly leans towards the feature team approach, as there can be no question on the immediate value delivery velocity benefits and the focus of the teams.

However, as we’ll see below, the answer is not that simple, and it’s likely that a more balanced approach may be required.

Mike Cottmeyer opined:

” Our first really important decision when thinking about how to scale agile is determining if the feature team approach will work or if we should consider a component team model.  Feature teams are THE starting place for agile organizations.  They are loosely coupled and highly cohesive and their inherent independence from the rest of the organization makes product development significantly faster and easier to forecast.

That said… many organizations are dealing with issues that make the feature team approach difficult to implement at scale.  These companies are developing products that are actually systems of systems.  Integrating disparate systems… disparate technologies… disparate build environments… disparate locations… disparate cultures… and disparate organizational politics into a single integrated feature team is not always advisable for even a moderately sized development shop.  For these organizations… the component team model represents a viable scaling alternative.

Yes, there are increased coordination costs associated with running large projects through component teams. Hopefully those costs are offset by the value of multiple products leveraging those commonly shared components.  Many organization will have to take a hard look at the feature team approach and examine at what scale the feature team approach will break down… because at some scale they WILL break down. “

Even then, the Line is Blurry

Even in light of this advice, we must also recognize that features and components are both  abstractions and the line is not so clear. One person’s feature may be another’s component.

For example, TradeStation Securities builds an on-line trading system where “charting market data” is a key capability for the trader. A few collocated agile teams work together on the charting function. They are some of the world’s foremost experts in charting real time data of this type. On the surface, that looks like an excellent example of a feature team, as charting certainly is a major feature of the system.

However, when new online trading capabilities are developed, such as “trading foreign exchange currencies (Forex),” new chart functionality must be added. However, driving this new chart functionality are major components such as streaming data, account management and interfaces with Forex exchanges. Is the new feature value stream described as “trading Forex all the way through the specialty chart function?” If so, that would make an obvious vertical feature stream and the teams might reorganize by taking some members of each component team and create a new vertical feature team for Forex trading.

Or,  is the feature “trading of Forex” plus “charting Forex”, in which case the charting team is already organized appropriately? Is the charting capability a feature set or a component? Both? Does it matter what you call it?

Even in the case where it is clear what you call it, is a feature team always the best choice? Keith Black, VP of TradeStation Technologies, notes:

“When we first interviewed Scrum coaches their view of Agile was solely focused on feature teams, this threatened to kill the initiative. Online trading requires a great depth of expertise and industry knowledge at many different levels. We could not reasonably form feature teams that included members from every component area. For one we’d have to increase our staff, and secondly the feature teams would be too large if they covered every facet of the trading process end to end.

Therefore, for our transition to Agile we organized around component teams and through maturity we are now in special cases putting together feature teams where it makes sense. This works for us because feature teams are excellent at driving an initiative through completion.

However, in some cases they still don’t make sense. For example, if you have twenty feature teams and they all rely on a common component, such as a time-critical online transactional processing engine, it may be inadvisable to have 20 different teams sticking their hands into this critical component. Rather, you might choose to have these changes controlled by a single Agile component team that can broker the needs of the 20 teams and make sure they don’t step on each other’s toes, or jeopardize areas they don’t understand by making changes for their particular features.”

So The  Answer is Likely a Mix

In the larger enterprise where there are many teams and many, many features, and systems that are in turn composed of system, the answer will likely be a mix of feature teams and component teams. Indeed, even in the modest-sized agile shop, a mix is likely to be appropriate.  Ryan Martens, founder and CTO of Rally Software (as agile as an organization as any that I am aware of) sketched the following, five-agile-team org chart and its “feature paths” for me:

Figure 1: Five-team agile organization with various feature paths noted.

Ryan went on to note:

“While we don’t think of it in these terms as such, three of these teams (ALM1, ALM2 and PPM in the top) would be readily identifiable as feature teams. One, (Infrastructure and Ops,  on the bottom)” is clearly a component team. I don’t know what you’d call the one (Platform and Integration) in the middle, because it sometimes originates it’s own features, and sometimes is simply a supportive component for other features.”

He concluded with some sound advice:

“What I would recommend is that you don’t get too hung up on the labels and the organization at the start. We think of maturity in stages: Flow, Pull and Innovate. In Flow, it’s about getting organized into agile teams and getting the value stream flowing in an agile manner. For Pull, its about leaning the work in process and having backlog maturity so that teams can pull from the backlog and implement in an order that makes the most technical and value sense. In Pull, I’d think a feature team could be a logical evolution for many. However, it’s getting started in Flow that is most critical and hardest step, and if you have to reorganize the enterprise before you begin, you may never begin at all.”

Recommendation: Lean to Features, Accept a Mix and Optimize Near Term for Collocation

Based on all this input and well-articulated arguments from both sides of the feature teams vs. component teams debate, what is my recommendation?

Interestingly enough, at real scale (think 30-40-50 teams), features are such spanning items, that this whole argument can become almost silly, and those cases, a broader “program based” (groups of teams collaborating) organization model (not unlike the charting teams feature/component pod above) must be considered.

But in the more typical, modest size enterprise or business unit (5-10 teams),  my recommendation is to apply feature teams wherever practical, but to optimize neither for features nor components per se, but to optimize around collocation. Pick feature teams if they are already collocated. Pick component teams if they are already collocated. The communication, team dynamics, continuous integration support,  and velocity benefits of collocation are likely to far exceed the benefits of the perfect theoretical organization, especially when the benefits of one approach vs. the other are not always so clear, as the various opinions indicate.

As your agile organization matures, you’ll be so competitive that you’ll have lots of opportunity to inspect and adapt your model and evolve your organization in a way that makes sense to you. But in the meantime, maybe nobody will have to move!

Organizing at Scale: Feature Teams vs. Component Teams – Part 2

In my last post, I reintroduced this topic, describing the conundrum of organizing large number of agile teams to better address value delivery for new end user features and services. I described two basic approaches, feature teams and component teams, and some arguments for each.

I’m still waiting for some feedback from a couple of others before I conclude with my personal recommendations, which I’ll post in the next day or so. In the meantime, Craig Larman courteously responded with his comments on my comments on his work in Larman [2009]. Since wordpress, as a capable (and free!) as it is, tends to bury comments at a level where you really have to want to see them to find them (not sufficiently “in your face” from my perspective), I thought I’d elevate Craig’s comments to this post, as he provides some clarifications on his work and my interpretation, as well as some more expansive thinking on the topic. Craig’s Comments from the prior post below are verbatim below.

Note: please also see additional comments from others on this and the prior post.

========================

“hi dean,

(someone pinged me that this topic was under discussion). thx for raising the topic.

bas and i did not write or intend to write that feature teams are the only rational way to organize teams. rather, the choice of any organizational design (including team structure) can be evaluated in terms of the global goal for optimization (e.g., maximizing fast value delivery, minimizing disruption, etc). from a toyota or lean perspective and the first agile principle, the global goal relates to early/fast delivery of value to real customers.

in the context of that measure, if one has design 1 with more delay and handoff and design 2 with less delay and handoff, design 2 is ‘better’ — with respect to that particular measure.

the ideal cross-functional cross-component feature team minimizes delay and handoff, whereas (not an opinion, just by pure systems logic..) component teams (which per definition are doing only part of the work for a customer feature) have more delay and handoff and create mini-waterfalls with single-specialist groups passing WIP items to each other (analysts, architects, programmers, testers, …).

but feature teams are only the ‘better’ model depending on the global goal — which is worth identifying in any discussion. and as you point out, we note that an org design such as feature teams may optimize flow of value, but it raises other problems (which are solvable). from a systems thinking perspective however, optimizing around addressing one of the other issues (e.g., minimizing org disruption) is a sub-optimization from the the perspective of value delivery… but not a suboptimization if the group agreed minimizing disruption was the system’s global goal.

if one visits an org that was organized around component teams and then they successful transition to feature teams, and then one asks if delivery of value is faster, the answer will be “yes.” it is also common when investigating such an org that they will say that planning and coordination are simpler, and that the multi-skilled learning that arises when working in feature teams has been useful to increase their degrees of freedom and to reduce the “truck number” of bottleneck specialists.

i look forward to your future comments, and those of others.

regards, craig

=============

===================
References:
Highsmith, Jim. Agile Project Management. 2004. Addison-Wesley.
Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. 2007. Addison Wesley.
Larmon, Craig and Bas Vodde. 2009. Scaling Lean and Agile Development. Addison Wesley.

Organizing at Scale: Feature Teams vs. Component Teams – Part 1

While continuing my work with a number of larger enterprises facing the cultural change, new practice adoption and organizational challenges of a large scale agile transformation, the topic has again come up as to how to organize large numbers of agile teams to effectively implement agile and optimize value stream delivery.

For the smaller software enterprise, it’s usually no issue at all. Teams will naturally organize around the few products or applications that reflect the mission. The silos that tend to separate development, product management and test in the larger enterprise  (hopefully!) do not exist. The teams are probably already collocated, rather than being distributed across disparate geographies. Creating an agile team is mostly a matter of deciding what roles the individuals will play, and rolling out some standard training.

At scale however, like most other things agile, the problem is dramatically different and the challenge is to understand who works on what and where. How do we organize larger numbers of teams in order to optimize value delivery of requirements? Do we organize around features, components, product lines, services or what? While there is no easy answer to this question, the question must be explored because so many agile practices – how many backlogs there are and who manages them – how the vision and features are communicated to groups of teams – how the teams coordinate their activities to produce a larger solution  – must be reflected in that decision.

Organize Around Components?

In Scaling Software Agility,  I described a typical organizational model whereby many of the agile teams are organized around the architecture of a larger-scale system. There, they leverage their technical skills and interest and focus on building robust components – making them as reliable and extensible as possible, leveraging common technologies and usage models, and facilitating reuse. I even called the teams define/build/test component teams, which is (perhaps) an unfortunate label. However, I also noted that:

“We use the word component as an organizing and labeling metaphor throughout this book. Other agile methods, such as FDD, stress that the team be oriented around features, still others suggest that a team may be oriented around services. We use component rather liberally, and we do not suggest that every likely software component represents a possible team, but in our experience, at scale, components are indeed the best organizing metaphor.”

I wasn’t particularly pedantic about it, but noted that a component-based organization is likely to already exist in the enterprise, and that wasn’t such a bad thing, given the critical role of architecture in these largest, enterprise-class systems.

In any case, in a component-based approach, development of a new feature is implemented by the affected component teams, as the figure below illustrates.

In this case, the agile requirements workflow would put backlog items for each new feature on each of the affected component teams. They minimize multiplexing across features by implementing them in series, rather than parallel. Moreover, they are able to aggregate the needs of multiple features into the architecture for their component and can focus on building the best possible, long-lived component for their layer.

Perhaps this is reflective of a bias towards an architecture-centric view of building these largest-of-all-known software systems. For there, if you don’t get the architecture reasonably right, you are unlikely to achieve the reliability, performance and longer-term feature velocity delivery goals of the enterprise. If and when that happens, the enterprise may be facing a refactoring project that could be measured in hundreds of man-years. A frightening thought for certain.

In addition, there are a number of other reasons why component teams can be effective in the agile enterprise:

1. Because of its history, past successes and large scope, the enterprise is likely already organized that way, with specialists who know large scale data bases, web services, embedded operating systems and the like, working together. Individuals – their skills, interests, residency, friendships, cultures and lifestyles – are not interchangeable. It’s best not to change anything you don’t absolutely have to.
2. Moreover, these teams may already be collocated with each other, and given the strong collocation benefits in agile, organizing otherwise could potentially increase team distribution and thereby lower productivity.
3. Technologies and programming languages typically differ across components as well, making it difficult, if not impossible, for pairing, collective ownership, continuous integration, testing automation, and other factors critical to high performing agile teams.
4. And finally, at scale, a single user feature could easily affect hundreds of practitioners. For example, a phone feature like “share my new video to utube” could affect many dozens of agile teams, in which case organizing by feature can be a nebulous and unrealistic concept.

Organization Around Features?

However, our current operating premise is that agile teams do a better job of focusing on value delivery, and this creates a contrary vector on this topic. Indeed, as traditionally taught, the almost universally accepted approach for organizing agile teams is to organize around features.

The advantages to a feature team approach are obvious: teams build expertise in the actual domain and usage mode of the system, and can typically accelerate value delivery of any one feature. The team’s core competence becomes the feature (or set of features), as opposed to the technology stack. The teams backlog is simplified, just one or two features at a time. That has to promote fast delivery of high value added features!

Other authors support the Feature-focused approach as well. For example, in Agile Project Management, Highsmith [2004] states:

“Feature based delivery means that the engineering team build features of the final product.”

Of course, that doesn’t mean to say that the teams themselves must be “organized by feature”, as all engineering teams in the end build features for the final product, though perhaps that is a logical inference. Others, including Larmon and Vodde [2009] have more directly (and adamantly) promoted the concept of feature teams as the only rational (well, perhaps, see Craig Larman’s comments below) way to organize agile teams. They note:

“a feature team is a long lived, cross-functional team that completes many end-to-end customer features, one by one.. advantages include increased value throughput, increased learning, simplified planning, reduced waste…”

Larman and Vodde state specifically that you should “avoid component teams” and indeed, spend an entire chapter with good coverage of the aspects of the  topic. However, the authors also point out several challenges with the feature team approach, including the need for broader skills and product knowledge, concurrent access to code, shared responsibility for design and difficulties in achieving reuse and infrastructure work. Not to mention the potential for dislocation of some team members as the organization aligns around these boundaries.

So What is the Conclusion?

So what is an agile enterprise to do in the face of this conundrum? I’ve asked a few additional experts for their opinion, and I’ll be providing my opinion as well, in the next post.
===================
References:
Highsmith, Jim. Agile Project Management. 2004. Addison-Wesley.
Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. 2007. Addison Wesley.
Larmon, Craig and Bas Vodde. 2009. Scaling Lean and Agile Development. Addison Wesley.