Scrum Teams & Product Teams
A Scrum team takes a problem and solves it end-to-end into the hands of the user or customer. A Product team is very similar, it is a team that is given a set of problems to solve and desired outcomes to achieve, and they then come up with a solution.
How do teams know which problem to solve? In a product team, a set of problems is given, whereas a Scrum team creates a vision and selects problems it deems valuable to address. This selection process involves creating a Product Backlog rather than receiving one.
In Scrum, the team manages all product-related tasks, including stakeholder collaboration, verification, maintenance, operation, experimentation, research, and development. The specific nature of these activities varies depending on the product being developed. For instance, a team focused on a mobile app is likely to engage deeply in end-user product discovery. Conversely, a team working on a Global Positioning System (GPS) infrastructure may have less direct interaction with end-users.
Basically, to me Scrum team is like a chef who’s given the freedom to roam a farmer’s market, pick whatever ingredients catch their eye, and then whip up a dish. A product team to me is like a chef who’s handed ingredients and told to make a dish that the people will love. They know what they need to cook and the flavours they need to achieve, but they’re constrained to the received problems.
Multiple Teams on a Product
When working with multiple teams for a product, enabling each team to independently solve any user problem can significantly enhance flexibility and efficiency. Imagine the potential, if any team could autonomously solve end-user problems. The LeSS (Large-Scale Scrum) framework offers insightful ideas for establishing such teams in the Scrum framework, known as Feature Teams. Achieving this level of agility, however, is quite a challenge, and organizations specialize teams in certain parts of the product. This specialization shifts the team’s focus inward, away from the ultimate goal of serving the end user.
Now, if you worry about how each team performs individually then you are likely solving the wrong problem. Why? Because by improving the teams independently you will likely not improve the performance of a product group. The CAO approach, unlike team-structured approaches which focus on individual teams, focuses on improving the performance of the product group as a whole, even at the cost of the performance of individual teams. This is ‘101’ systems thinking.
Operating Model & Organization Design
In the field of organization design, the term “operating model” mostly refers to the policies, processes, information flow, and management style within a (part-of)organization. An organisation structure defines the various units such as departments or teams, detailing their functions, roles, and responsibilities. In larger organizations, which consist of multiple units, it becomes necessary to allocate work across various units. The critical question then arises: how can these units be integrated to ensure alignment, control, and knowledge sharing? Well, that depends on the organization’s strategic focus, which is reflected in its operating model.
Now, My approach to Agile and Scrum emphasizes outcome-oriented actions, discovering effective methods, and prioritizing product-focused leadership. You likely share this perspective as well.
So, you might ask then why there are all these bad Scrum implementations with so-called features teams focusing on outputs working in a feature factory. Well, the reason is not the ideas of Scrum or feature teams, but the lack of a supporting organization design. You see, the operating model that is required for your organisation to get the benefits from Agile working comes from an organisation design that enables it to work. To achieve this, it is essential to design your organizational structure, processes, reward systems, people practices, and leadership styles to ensure they are all aligned.
Concluding
Agile organization design, centred around Scrum and Product teams, is about an outcome-driven approach to product development. Scrum teams & feature teams enjoy the autonomy to select and address problems creatively, akin to chefs exploring ingredients at a market, while Product teams work with predefined problems. Successful scaling of Agile requires an organizational design that aligns the operating model with Agile principles. This alignment ensures that the organization’s structure, processes, rewards and culture collectively support effective problem-solving and product innovation.