For our organisation to be agile, we have an explicit need for the "Vertical slice" team. Where every team can make updates across the system, pretty much independently of other teams. Nothing, or at least no other team, gets in the way of progress of the "Vertical slice" team! But in the real world we often shy away from the Vertical team from both a line management and a technical leadership point of view and we continue to form component based teams.
The component based team:
- The most "natural" way for most organisations to setup its' teams.
- Scope of the teams' responsibility is small so they have excellent technical focus. There are a few technologies that the team works intimately with, all the time. Line mgt and developers are happy.
- Team members can become true experts in an area or technology.
- Can build out a "complex" component out of sophisticated "niche" technologies relatively quickly.
- That team only knows a small part of the system. They are effectively limited to working on that part of the system.
- The team can have the illusion of being successful in a product that is failing
- There is a big "tax" when moving people or other teams onto or off this component.
- Those people become key to the organization even though they might not be domain experts in the business. The team can make themselves indispensable to the organisation.
- Component becomes impossible to fundamentally change its technology as the business changes. A component team is loyal to the technology because they have so much expertise. The business adapts its solutions to fit the technologies employed.
- Long term waste/expense. Over medium to long term you end up building parts of a component that are "nice to have" and may never be used by the business.
- Perceived "God" complex develops over time. And Conways' Law applies.