Feature Teams vs Component Teams

There's a very good article on the Scrum Alliance website that covers this topic in some detail...

Working with Component Teams: How to Navigate the Complexity:
http://www.scrumalliance.org/community/articles/2012/september/working-…

The contention is that component teams are indeed a problem, and they should be replaced as soon as practicable by feature teams.

This article also looks at Mike Cohn's idea of having component teams fulfil a Product Ownership role. I have to confess that I've tried that in the past without much success...the ownership was too weak, essentially because it did not represent business interests in a direct enough manner.

My thought is that component teams are generally a dysfunction. Larman/Vodde cover the pitfalls of component teams very well in this book:
http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/…

I think Cohn covers them well in his book too, though I wish he would go further in pushing for Feature teams.

One of my problems with SAFe is that it condones component teams too much in its graphics and elsewhere. IF you have fairly permanent component teams, then it's going to be hard to Agile, since it makes it hard to deliver end to end features every couple/few weeks.

Some other comments:
> The issue is that in order to deliver features, each team must own the entire codebase,
I'm not sure that this is true. In any product, the entire product group (all Scrum teams working on that product) collectively own the entire code base, and collectively share the same Definition of Done.

> idea of having component teams fulfill a Product Ownership role
This gets ugly quickly and has one major, fatal flaw. For any given product, there is only one Product Owner or one "Chief Product Owner" if you prefer that term. That person has final say on the order of the single product backlog, including any "component team's" backlog items. The entire product group shares the same product backlog, and the same Chief PO. Now, if you wanted a team level PO for the component team, that might be ok, so long as that person answers to the Chief PO on ordering of the backlog.

Another fatal flaw of this approach is that the Product Owner is one person, not a team. This is a very strict rule in the Scrum Guide. My preference, if you must go down this road, is that the consuming teams be treated as important stakeholders, and help negotiate with the producer team to define interfaces to the components. But alas, remember, for a component team, the PO gets to control the "what" (likely this is interfaces -- inputs, outputs, exceptions, etc), and component team gets to control the "how" (how everything works below the interface level).

My strong preference is to use only feature teams, move teams towards feature teams, and teach feature teams how to co-operate to achieve shared goals. Larman has some good stuff on all of this in the book above and in this one:
http://www.amazon.com/Practices-Scaling-Lean-Agile-Development/dp/03216…

I should mention that Larman's books are not for Scrum newbies, but scaling Scrum is not for newbies either.

> For any given product, there is only one Product Owner or one "Chief Product Owner" if you prefer that term.

This is important because the only way a Chief PO can effectively manage total ROI for the product is if he/she also has the last say on the order of the single, unified, product backlog.

Perhaps a good concrete example for this topic is how Spotify put Scrum into practice internally:
https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.pdf

I think both Feature Teams and Component Teams can be used, and both are described in "Scrum and the Enterprise". If you have Component Teams, you will probably have an integration team which integrates and tests the components and reports found bugs back to the Component Teams where they are fixed with high priority. The point is that you need an integrated increment which fullfills a common definition of done each sprint. If you can manage that, I don't see a dysfunction in Component Teams per se.

I am strongly in favor of Feature team as with multiple component teams you are not sure of getting a shippable product to customer after every sprint. I agree that it adds some overhead in terms of dependency but those can be managed with the help of tools and processes such as SoS.

Cheers
Sanjay

Ian can you please confirm how "SAFe provides for the use of "component teams" at scale". My understanding was that SAFe doesn't infer to either.

It was over 6 years ago, but I may have been referring to: https://www.scaledagileframework.com/features-and-components/

I am favourable on the "feature team" approach as the essence of Scrum is to deliver the releasable feature(s) at the end of the Sprint. This reflects the progress of evolution of a product and how it fulfills the user requirements. Having said that, I agree with Ian on the "code merge hell" as a inevitable issues when we are adopting feature team approach and multiple people are working on the same piece of code. I believe what Ian is trying to highlight is the pros and cons and these 2 models and how to actually manage the cons so that the delivery of the product is not jeopardized whereas in quality or customer satisfaction.

To add on Ian points, it can be even more worried regarding whether you have team members with adequate knowledge to work on each of the different components. Let's say component A is developed in Java while component B is developed in LINC. Do you have a developer that master these 2 languages at the same time in the market?

Thus, it boils down to the point of how to manage the cons of the approach in the scaled product delivery. Probably you need to ask yourself whether the multiple teams are able to sustain with the "feature team" concept given the knowledge, tools and capabilities you have on hands. "Code Merge Hell" can be a relatively small problem as we have automated version merging tools (Git, SVN, etc) and alerts can be sent to the developers so that they tackle the issues and react to them earlier. The same point has been highlighted in the hyperlink given by Ian as well.

Thus, I am more inclined to go with "feature team" approach to preserve the essence of the Scrum. I admit in reality there is limitation but it should not bend too much until the essences are lost.

Component teams create unsolvable dependencies of other teams.

Feature teams will resolve dependencies with technical solutions: conways law will typically result in microservices architecture.

I would argue that it's crystal clear what is in line with agility, because I think dependencies are it's evil twin brother.

> My thought is that component teams are generally a dysfunction. Larman/Vodde cover the pitfalls   of component teams very well... 

I totally agree with Charles that Larman/Vodde describe it well. Their chapter on Feature teams is online available:

https://www.craiglarman.com/content/feature-teams/feature-teams.htm