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.
Everyone who has built or renovated a house is familiar with this. You really “only” want to have sun protection attached to the windows. Unfortunately, this often does not come from a single source, but requires not only the craftsman who actually installs the sun protection, but also an electrician who lays the power cables, a bricklayer who plaster everything and a painter who paints everything again. The value stream from the idea to the benefit is interrupted several times by handovers and must be more or less extensively planned and coordinated (by the client). How much easier and quicker it would be to order the sun protection with everything you need from a single craftsman! This is exactly the difference from the customer’s point of view between component teams (the specialized craftsmen with their respective subcontracts) and feature teams (a team that completely processes the order, no matter what skills are required).
Since customer orientation is an essential principle of agility, component teams may be the simpler, but only the second best solution to split work on a large product. No matter how the components are cut, there are still handovers and coordination between the components to offer the customer their benefit. Some cuts are certainly better than others. The frequently used slicing in horizontal layers like frontend, backend and database in software products may be quite convenient for the respective experts. But from the customer’s point of view this design is extremely unsatisfactory, because any non-trivial feature will pass through all layers, resulting in slow and error-prone handovers. Better are vertical slices that break the product down into logically self-contained sub-products. For example, an enterprise resource planning system will consist of at least the components purchasing, warehousing and sales. Nevertheless, there will still be features that span more than one component and thus require coordination.
Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.
Melvin E. Conway
Regardless of the component design, component teams lead to silos, because each team will feel responsible only for its part of the product. This effect is reinforced by the Conway’s Law according to which “the software interface structure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult” (Wikipedia). Organizations tend to design software systems in a way that resembles the organizational and communications structure. If the vertical component slicing follows this organizational structure and is staffed by teams of the respective organizational units, this only cements the walls of the already existing silos.
Feature teams, i.e. teams that can implement a customer’s requirement from the idea to the actual use, no matter in which component of the product, are certainly the better choice. From the customer’s point of view anyway, but also from the organization’s point of view. Since component teams can only work in their components, it always requires a great deal of planning to ensure that these teams are always optimally utilized because not every requirement will have the same amount of work per component. However, feature teams require a high degree of maturity of the organization, because the product is jointly designed and owned by everyone. Organizations that were used to break work down into small steps and force people into rigid roles in defined processes will have great difficulties in the first place. Following the principle of Shu-Ha-Ri, it is recommended to start with small products with a single team and to internalize the stance and principles of agility. Then you can take on larger products with vertical component teams and let them gradually develop into feature teams.
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?