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.

Picture 2
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.

Picture 1
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.
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.


10 thoughts on “Organizing at Scale: Feature Teams vs. Component Teams – Part 1

  1. 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 suboptimization from the the perspective of value delivery… but not a suboptimization if the group agreed mimimizing 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

  2. > concurrent access to code,

    this cannot be a problem with frequent check-ins and code versioning systems that support merges.
    in my experience it is not a problem for groups up to 35 devs working on shared code base. my question is “who have tried this with bigger numbers? How much it scale ?”

    >shared responsibility for design and difficulties in achieving reuse and infrastructure work.

    this can be solved having a planning (design) session organizrd as a cross-team open-space and also people rotating pairs on different teams

    as before my question is “who have tried this with bigger numbers? How much it scale ?”

    > Not to mention the potential for dislocation of some team members

    this should work:

    > broader skills and product knowledge,

    imho this is the real point

    what you think ?

    • >
      > broader skills and product knowledge,

      It is a real point but actually not a huge problem. It naturally depends on the teams, but if you have build the teams correctly, they all have some variety of domain knowledge but more important, enough seniority and problem solving skills that it will not be an obstacle. A real life experience in my unit, after one year in feature teams, 5 teams are working pretty comfortably on quite a large domain set, one of them in maintenance shifts, delivering solutions to customer problems.

    • > concurrent access to code

      also google uses the approach I described for a group of 35 devs.
      at google it work for 10000 developers committing several thousand changes into the repo per day with spikes of 20+ changes per minute.
      they always release from the head and all systems are released independently.

      this info come from the keynote speech at XpDay 2009 London by Mark Striebeck, engineering manager at Google.

    • Mike,
      I’m familiar with the quote, though I’m not sure I’ve ever really understood it and people seem to use it to make a variety of different, even conflicting points. How do you think it applies in this case?

      • In many ways it’s inevitable and not something to obsess over, but I’ve seen teams whose main focus is the support for one system find it difficult to replace it, especially where that new system has a different scope (as it should if the “big rewrite” syndrome is to be avoided). I’ve also seen awkward organisations that uncomfortably span weakly-related business functions deliver equally awkward systems.

        Slightly off this subject, my most successful project had a cross-functional team, so I’m definitely in favour of those. Not sure how well they transition into maturity though.

  3. I think I prefer the idea of feature teams instead of component teams because it means that any one team has control of the whole end to end process of what they’re working on which means that it’s much easier to get things done and we are much less reliant on other people.

    On the other hand it seems like a lot of organisations choose to set up their teams in components, perhaps because this seems to make more sense because you have all the experts of a certain technology together, I’m not sure?

    Doing this increases the communication overhead and from what I’ve seen leads to duplication of code across the different layers because noone knows exactly what is being done in the other layers.

    It also seems to me that within a team you end up with a ‘us v them’ mentality which is really not helpful if you have teams as reliant on each other as you do when dividing teams by component.

    Certainly an interesting topic and some good points raised.

    Cheers, Mark

  4. While we have used feature teams successfully in some situations, one challenge I find that I don’t see here is the need for a team to provide 2nd level support and to ensure backups for team members.

    In a component team (or perhaps more appropriate from my background is a “Functional” team), you have a group of 4 or 5 people who all know a particular part of the codebase. Any one of them can provide support on that codebase or can backup someone who is out sick.

    In a feature-oriented team, while the goal is for anyone on the team to be able to work in any area, inevitably you end up with specialists. And when it comes time to deal with a support issue, or someone is out sick, you miss the specialist.

    We manage this issue by using a combination of feature-based teams that are not long-lived and functional teams that are long-lived.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s