TL;DR
Don't create a false dichotomy by confusing the organizational choice of how to structure teams with the mechanism for scaling the Scrum framework up within the enterprise. The team structure you choose will impact your level of integration effort, but does not ultimately affect the scaling mechanism itself.
Regardless of how you form your teams, each team will work from a single Product Backlog for a given project. However, the enterprise can also have a Product Backlog, and delegate sub-projects to different teams in order to operate at scale.
A Project Has Exactly One Product Backlog
By definition, each project has exactly one Product Backlog. Likewise, each team works from exactly one Product Backlog per Sprint.
What you're describing sounds like a situation where you may want more than one team to work from a single over-arching Product Backlog managed at the enterprise level. There are a number of ways to solve the problems involved in scaling Scrum for the enterprise, including:
Most of the complexity comes from the fact that your organization is not currently aligned with the way your projects are staffed and work is distributed. This is largely a process-engineering issue, although you may find that some changes need to be made to your organizational charts, too.
Two Short Examples
If you have a new product that will span multiple teams across the enterprise, you already know your organizational choices:
- Teams formed to deliver a specific feature or project.
- Teams formed as cross-functional units, to which features or products are delegated.
There are organizational pros and cons to each approach, but that is outside the scope of the original question. Let's look at two examples of how the project might be scaled.
Feature/Project Teams
The enterprise backlog is formed, and themes and epics are carved out to define the sub-projects that you will form Scrum teams to deliver. Each team is given a single Product Backlog that is composed of the themes and epics that define the team's objectives.
The Product Owner and the Scrum Master for each Scrum team then participate in the Scrum-of-Scrums (or your scaling framework of choice) where the enterprise-level Product Backlog is coordinated.
Because the team is often feature-focused, there is often more coordination required at the Scrum-of-Scrums level, and lot more inter-team dependencies will need to be managed at all levels. However, the team's narrow focus may make it possible to work with teams that are less cross-functional, because the cross-functionality exists between teams rather than inside each individual team. This is one of the many trade-offs you must make at the enterprise level when you plan the top-level project.
Cross-Functional Teams
This is actually very close to the previous example, except that the teams aren't formed around specific features. Instead, the team's Product Backlog is composed of vertical slices that leverage the cross-functional nature of the team to deliver functionality to the Scrum-of-Scrums.
This approach reduces interdependency between Scrum teams within each Sprint, but still requires active coordination at the enterprise level to ensure the work integrates at the end of each iteration. In addition, by ensuring the teams are fully cross-functional rather than specialized, there is more flexibility to move enterprise-level Product Backlog items between teams as capacity, requirements, or priorities change.
