Organizing Agile at Scale: Feature Teams versus Component Teams - Part 3

Dean Leffingwell, author of Scaling Software Agility, recently posted a series on the ongoing debate over "Feature Teams" versus "Component Teams" in the Agile community. Over the course of three posts, Dean does a great job of digesting the underlying concepts and considerations, and he ultimately recognizes there's likely not "one right answer"... That like most things in software, we're dealing with various shades of gray, and arriving at the right answer depends on smart people with good judgment.

As he puts it:

"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, ... the answer is not that simple, and it's likely that a more balanced approach may be required."

Whichever way you slice it, make sure your teams clearly understand the results they are accountable for - be they intermediate components or full-fledged product features.

And for what it's worth, I strongly recommend you recognize the importance of organizing around the architecture. The alternative is allowing the architecture to organize around the organization, and that invariably leads to unintended consequences.

Check it out at Organizing Agile at Scale: Feature Teams versus Component Teams - Part 3