Team Design Patterns – Feature Teams and Component Teams

I spent time outlining the guiding principles for organizing agile teams in my last article. With the challenge of delivering business intent where changes to 10’s of platforms / components are needed and we only have developers and testers who specialize in singular platforms / components - how do you organize? There have been many books, whitepapers, and blogs (see here, here, here, and here). talking about the tradeoffs of feature teams (which can also be referred to as business vertical teams or product-aligned teams) and component teams. A feature team spends their days delivering user stories that are highly reflective of needed business intent whereas component teams spend their time delivering user stories that are generated by the feature teams because they need components outside of their scope of knowledge or responsibility modified to deliver the overall solution.

Much of the writing on feature and component teams puts feature teams in the “good” camp and component teams in the “bad” (and sometimes “evil”) camp. With the challenges outlined above, to some degree, component teams might be a necessary evil. The key is that your initial organizational design has feature teams as well and that you are creating an obvious maturity path towards possibly eliminating the component teams by pushing that component skill and knowledge towards the feature teams through knowledge sharing and architectural simplification. Ultimately, the goal is to create feature teams of generalizing specialists, living and collaborating right with the BIG’s (Business Intent Generators), and able to create and modify 100% the system components needed to delivery that business intent – the Ideal Team Structure (ITS).