When it comes to organizational structure in an agile context, many people claim that feature teams are generally a better choice than component teams. This at least is what I find when discussing with colleagues, both in my current as well as in my previous position. Also, Larman and Vodde argue vehemently against component teams (Practices for Scaling Lean & Agile Development), and have brought that position also into the Scrum Primer (http://scrumprimer.org).
There exist, however, sources that indicate that the choice between feature and component teams is not an "all or nothing" decision, and that there are criteria which can make having (at least a few) component teams a wise choice. For example, in https://www.scaledagileframework.com/features-and-components for example the authors indicate that a high degree of re-usability and high degree of technological specialization are criteria that make component teams for that respective part of the system favorable. Mike Cohn and Ken Rubin in their books also take a more balanced view.
In my professional environment (automotive suppliers) there are traditionally a lot of component teams. When doing the transition to an agile way of working, many colleagues feel that, when staying with a component team structure, the management would be doing something fundamentally wrong. I don't see it this way for several reasons:
- First, what an automotive supplier delivers as their product is, from the perspective of the vehicle, just a component. The actual customer features are on vehicle level. So, consequently and ideally, feature teams would have to work cross vehicle (across supplier and OEM boundaries). That, however, is never even discussed as a possible way of working.
- There are lots of components in use, like, operating systems (Linux, QNX, AutoSar, ...), standard libraries, third party libraries (navigation, speech recognition), open source libraries, ... And, for most of these libraries nobody has the expertise to improve the library's internals anyway. To phrase it a bit sarcastically: Having other teams develop components to use comes handy, but developing components in the own agile organisation is a bad choice?
- And, certainly, there are many areas where people and teams have developed deep expertise over years, and, where this expertise is truly essential to avoid costly field returns. Developing a software update strategy that works in all circumstances in the field with power-drops happening at arbitrary times is something that only a few can do. Thus there is a high risk if everyone in a larger project can make modifications to that source tree. Similarly, security features are everywhere, but only few understand the details, also the vehicle specific communication protocols etc.
Now my question: What other criteria (except for degree of re-use and technical expertise) do you see that could make component teams in certain software development scenarios favorable while working in an agile context?