Feature Teams vs Component Teams
There is an alternative to this, which is to use "component teams". For example, each team might be responsible for architectural components, and thereby act as interface guardians and as the guarantors of component quality.
Now, I've noticed that as agile teams move to scale, the "feature team" model can increase certain technical risks, and become rather attenuated. The issue is that in order to deliver features, each team must own the entire codebase, and their work will typically cross-cut many components. There is a real danger of entering a "code merge hell" where instabilities are inadvertently introduced and the quality of the deliverables suffers. I'm sure many of you will have seen this. A move to "component teams" theoretically minimizes such risks, albeit at the cost of increased business risk as teams become more technically focused.
At least one framework (yes, it's SAFe) provides for the use of "component teams" at scale. Then again, Larman and Vodde have indicated that "feature teams" should remain viable. What are other people's thoughts on this matter?
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:
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:
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:
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:
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.