Agile organizations rely on the principle of subsidiarity. Decisions are always made as decentralized as possible. The next higher or next larger unit only takes action if the smaller unit is not able to solve the task alone. But even then, the objective is still to help people to help themselves. However, this only works if autonomy is given a common orientation towards a higher purpose. Constant work on and with this purpose as a guideline is thus one of the most important leadership tasks in an agile organization. And actively assuming responsibility in the sense of a common mission is the most important task of the decentralized units, by which their autonomy is legitimized.
Agile methods and especially Scrum look very simple in a small product with a single team. As soon as several teams work on one product, the work has to be split up somehow. The obvious, because well-known, approach is to break down the product more or less logically and meaningfully into components and to assign component teams to them. From the customer’s point of view, however, these components are completely irrelevant. At best, the customer doesn’t realize them. In most cases, however, he does, because there usually several component boundaries have to be crossed to realize customer’s benefits and the product’s necessary functions. This results in handovers and coordination between teams that interrupt the flow. From the customer’s point of view, it would be much more desirable if the new feature was implemented by a single so-called feature team, no matter which components are affected.