One of the discussions that comes up in many of the companies that I work with is the scope of feature teams. Although most companies are still struggling with moving from component teams to feature teams, the increasing prevalence of continuous integration infrastructures makes it easier to move to shared code ownership and teams that can change any code they need to in order to build their backlog item.
Although there still are a few engineers and managers out there that prefer component teams, my experience is that most of us have experienced the disadvantages of component teams, such as complex break down and integration of functionality, difficulty to ensure that teams are working on the most important items and the creation of small kingdoms in the organization. Feature teams address many of these challenged and provide a superior alternative in most situations. However, in virtually all conversations the scope of the feature team, as in the set of components that a feature team can change, is brought up and companies are looking for guidelines.
The traditional view of a feature team is that it can make changes and add code to any component that needs to be changed in order to build the feature that my team and I are responsible for. Using feature teams has many advantages, not the least to avoid the situation where component teams working on commodity components find ways to keep themselves busy even if their functionality does not provide any business value.
At the same time, there is a limit to the scope a feature team can cover in terms of the breadth and depth of functionality of a large and complex system. Some organizations associate a “skills needs” profile to items on the backlog and only teams that have the right skill profile can pick those items from the backlog. Similarly, I often advice companies to maintain part time component experts that can coach feature teams to make changes in the component in a sustainable fashion. These approaches allow for better scalability of feature teams across a large and complex system.
The challenge still is that when we scale to complex and large systems, there is a point where we need to draw a boundary and interface that indicate the end of the scope of these feature teams. The question is how to determine at which point this boundary is best established. There are at least five approaches that one can take, i.e. architectural, deployment-driven, skills-driven, organizational and 3LPM-driven. Below we discuss each of these in more detail.
The system architecture breaks the system in high level components and subsystems. Here these components and subsystems provide a first indication of where to draw the line. Many architectures exhibit a layered architecture and depending on the content of typical work items on the backlog, it may make sense to constrain a feature team to one layer of the architecture. This has to be carefully evaluated, though, as I have experienced many architectures where virtually every new feature of functionality cross-cut the architecture and required changes across multiple layers. If it matches the work, though, following the architecture may help to reduce the amount of hidden and complex dependencies between components and subsystems.
The deployment-driven approach assumes that different parts of a system deploy at different time scales. In a typical embedded system, the mechanical parts of a system evolve on a multi-year time scale, hardware and hardware-close software on a yearly or half-yearly time scale and more independent software releases every sprint, monthly or at most quarterly. In this case, teams operate only in the part that deploy with the same deployment frequency.
The skills-driven approach is especially used in situations where the company offers highly specialized functionality in one area and the rest of the system provides the necessary support functionality that is not (nearly) as specialized. The subsystem that contains the expert knowledge is managed by one set of teams and the rest of the system by another set of teams. It is important to realize that in most organizations, there is a overestimation of the complexity of software and an underestimation of the ability of feature teams to operate across the architecture. This may easily lead to a situation where the feature teams have such a narrow scope that these de-facto become component teams.
Especially in distributed organizations where development teams are located in different parts of the world and work in different time zones, there often is a desire to allow for as much local autonomy as possible. Teams from different locations touching the same code can easily lead to complications, especially if the continuous integration environment is not very mature. Although this approach breaks the BAPO principles (see here for a description of BAPO), if the allocation of responsibilities can be organized this way, it may positively affect the productivity of the organization.
Finally, in an earlier blog post, we introduced the Three Layer Product Model (3LPM) where we organize functionality into innovative, differentiating and commodity functionality. Each type of functionality is assigned to a layer and each layer has its own focus. Teams working on the commodity layer focus on reducing the total cost of ownership for the commodity functionality by standardizing, removing variants, replacing bespoke functionality with COTS or OSS components, etc. Teams working on differentiating functionality focus their energy on maximizing customer value through experimenting with alternative implementations, offering variants for specific customer segments, etc. Finally, teams working on innovation are expected to test as many innovative ideas with customers as possible against the lowest cost and effort per experiment in order to find the future differentiation. In this case, constraining teams to one layer of the 3LPM allows these teams to focus on their own target.
Concluding, determining the scope of feature teams in R&D is, for most companies, a non-trivial problem. In this post, we identified five different approaches to defining the scope and scale of feature teams. However, although I work with dozens of companies, the number of cases that I have access to is still limited. Please share your experiences and learnings in the comments!
Follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch)! And you might like www.software-center.se!
