When are component teams a better choice than feature teams in agile development?

Question

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?

Answer 1

One key point of working "Agile" means the team produces deliverables in small cycles (called "Sprints" in Scrum speech). So IMHO the only thing which really matters in this context is: can the components of a bigger system can have mostly independent release cycles, so they can be developed in individual Sprints?

If the answer is yes, there is IMHO no reason which forbids working "Agile" in component teams. Each component needs to be a "deliverable product on its own", with clearly defined interfaces, own versioning, own tests, own documentation, and a Sprint planning which does not entangle the development of different components together.

You already gave some examples where this works well: components like the operating system or other, specialized third party libraries: development of components which depend on the former is planned on top of the already available features at the start of each sprint (for example, of the Linux system or the speech recognition system or whatever). So if your team develops the new multimedia center utilizing some speech recognition system on top of Linux V123.4, it does not matter for your sprint planning when the "new release 4.0 of the speech recognition component with increased detection rate" will be available or not, or if Linux V123.5 will be available or not - your team can work on your next ten sprints of the multimedia center with or without that new version.

To give you a counter example: a multi layered web application where the development of every new feature requires always changes to the "frontend" as well as to the "backend" in parallel. When you cannot plan Sprints for the frontend team independently from the backend team, working in sprints will produce friction between the teams, because one of them will always have to wait for the other. So this kind of development will probably work better with a cross-functional team, because if the frontend activities are done before the end of the planned sprint (or vice versa), the available devs who worked on the frontend can help to finish the backend activities for the sprint (or vice versa).

Answer 2

You can be agile within each existing component team if you must. And see where that goes. Imposing agile at the top level of a honed multi-disciplined production organisation however will be disruptive, destructive, lead to chaos and bring the operation to a grinding halt.

Agile kills ownership

This is not necessarily bad in all situations, it may be the way to go to address a single point of failure. The question to ask should always be: can we afford to do this and can we afford to do it abruptly?

There will be consequences not only immediate regarding quality but socially as well. How do you figure John will like it that the component he has worked on for years, that he feels responsible for, that he is proud of, that is his baby, will suddenly be out there for everyone to mess with and pee over? How is he going to deal with the message "Well John, you may feel you worked hard and build up some expertise, but hey, we have news for you: we don't believe that, we think anybody can do your job! So take a back seat and watch how your co-workers, who you got along with pretty well so far, are going to ruin everything you did." John is likely going to have some loyalty issues.

Being sent all over the place to extinguish small fires in parts you are unfamiliar with is ungratifying, the more capable people will eventually leave. And this is what agile/scrum often deteriorates to when implemented carelessly: no one owns anything and thus no one feels responsible for anything, cares about anything or gets good at anything.

Agile/scrum is great if you come from having no process at all. If you do have a system with some history that has worked, you should be very careful not to lose more than you gain.