According to The 2020 Scrum Guide, a Scrum Team should contain members with all the skills necessary to create an Increment of usable product each Sprint. Teams that approach their work from a product perspective find this cross-functionality easier to achieve than teams that organize around the technologies required to deliver the product. Although having some technology teams in your organization might be necessary, product teams should be the default because of their many advantages. This article will discuss the five benefits product teams have over technology teams.
Defining our terms
Before we get to the product team benefits, let’s define our terms. What is a product? And what is a product team vs. a technology team?
According to Marketing, 7th Edition by Kotler, Brown, Adam, Burton and Armstrong, a product is anything that can be offered to a market that might satisfy a want or need. A product can be an internal or external article/object or service.
When defining your team’s product, start with the customer. Who is the consumer, and who is the buyer?
For example, if the customer is a car manufacturer, the product might be the tires or the window glass. If the customer is a consumer who needs a vehicle, then the product might be the car. If the customer is a new car dealership, the product might be a floor plan or fleet of vehicles.
The definition of the product determines the degree of the team’s cross-functionality. For example, if you define your product as moving data from one internal team to another at a particular company, you may only have data developers on your team. If your product is building a website, your team likely includes web developers, graphic designers, content writers, usability experts, SQL developers, and anyone else necessary to deliver an Increment of usable product each Sprint. All teams in Scrum should be cross-functional, but if you define your product too narrowly, it will limit your team’s cross-functionality.
Product teams define their customer more broadly and, therefore, might have multiple technologists and other specialists working together to deliver the product to the customer.
Technology teams define their products narrowly; therefore, the team might consist of a single technology or specialized skill set. These teams often regard internal teams as their “customers.”
5 benefits of product teams
Cross-functional product teams deliver at least five benefits that technology teams don’t.
1. Product teams accelerate value delivery
Because product teams define their products more broadly, they organize around having all the skills necessary to deliver their product to the customer who will ultimately use them. Team members work together from the same Product Backlog and collaborate with a single Product Owner. Product teams don’t have to hand their work off to a different team in order to deliver value to the customer.
When teams self-organize around a product, they can avoid the handoff downtime that comes with the receiving team having to learn what the previous team did before embarking on their own work. Defining a product team based more broadly accelerates value delivery by reducing handoffs and decreasing wasted time.
Also, due to a narrow product definition, technology teams are likely to have frequent dependencies on other teams. A technology team that only focuses on one aspect of a website such as the back-end functionality, for example, might have to rely on another team to deliver the graphics and one more to build the database table for the contact us form. Technology teams spend significant time requesting work from other technology teams, slowing delivery.
2. Greater customer focus delivers a better product
When teams form around the customer rather than around technology silos, they focus on customer needs. They are constantly assessing the most valuable thing they can do next for the customer rather than responding to the requests from the various internal teams. The entire product team focuses on brainstorming ways to maximize value for the product as a whole.
Unlike technology teams, product teams following the Scrum framework are closer to the customers and their stakeholders, getting feedback regularly through the Sprint Review or customer-focused market research.
3. Single prioritization streamlines value delivery
Product teams work together on items from a single Product Backlog. In contrast, teams organized based on technology each have their own backlog, and the top priority of one technology team might be at the bottom of the list for another. These sorts of discrepancies invariably slow the delivery of value.
4. Skills growth and job satisfaction
Product teams require members who can work in more than one technology area or specialization. As a result, individuals working together on a product team have more opportunities to develop new skills because they can learn from each other and work on different types of problems. This opportunity to build and use new skills often results in increased work satisfaction.
5. Coordination is done by the Product team
Narrowly defined products mean more siloed teams and a higher number of Product Owners than necessary. These Product Owners spend more time coordinating amongst themselves and aligning Product Backlogs than if they were part of a single product team. Instead, developers on the Product team coordinate amongst themselves to find the best way to deliver value to the customer.
How big do you draw the product box?
The size of your product box depends on the needs of the team. Leadership often expresses their concern that defining products more broadly could result in inefficiency because individuals with highly specialized skills are not required as frequently. For example, a team might not need database developers for a website product every Sprint. As a result, if database developers are assigned to a single website product, they may have some — or even a lot — of downtime. This potential imbalance is a consideration. I suggest thinking carefully about how frequently the team needs each skill set. If it needs a database developer every Sprint, then make that specialization part of the team supporting that product. If a database developer isn’t required each Sprint, perhaps the person can be available upon request. Just be aware of the cost of having handoffs as outlined above.
See our recent article, What to Consider in your Transition to Scrum for a step-by-step guide on what to do once you’ve defined your product.
Conclusion
How you define a product profoundly impacts the structure of Scrum Teams within an organization. A thoughtful approach to defining products can help ensure that Scrum delivers the maximum value to your organization. There is a place for both product and technology teams, and your organization may have a mix of both. How big you draw the “product box” will depend on your organization's unique needs.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.