Introduction
According to the scrum guide, scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. This process framework is used and has proven its value since the early 1990s.
The basis of the scrum framework is the scrum team. The scrum team consist of the product owner, the scrum master and the development team. According to the scrum guide the optimal size for a development team is three to nine members.
With less than three members there is a decrease of interaction and there is a high change of skills constraints. This can result in smaller productivity gains and being unable to deliver a potential releasable increment every sprint.
A few of the businesses we provide application development and operations services to, only have small applications which do not have the need for a large development team. Providing a complete service with two or less people in the development team is very risky and expensive.
So what are your options when the work for a product doesn’t justify a development team of 3 or more members?
We implemented a multiproduct team. One scrum team that develops and supports multiple products. This is not a perfect or fit for all approach. In this article the disadvantages of this approach will be described as well as the advantages which led us to implement this approach.
Disadvantages of a multiproduct team
Focus
The most important disadvantage for the multiproduct approach can be found in the scrum values. The value “focus”. With multiple products in the sprint and multiple products with support issues, focus is much harder. Switching between products means switching between functional context and sometimes switching between technological stack.
This context switching results in productivity loss. Starting with tasks of another product takes more time for a team member than continuing working on the same product.
Demanding for team members
Working in a multiproduct team demands additional skills from the team members. The multiproduct environment demands a level of seniority of the team members. They should be able to work on different technological stacks and understand different functional contexts. In addition working in a multiproduct team is a personal preference of the team members. Not everybody can handle the context switching.
Increased complexity
The implementation of the team process based on the scrum framework can differ between products. For example the Definition of Done can differ from product to product. And every product has a product backlog and own increment. Having multiple Definitions of Done and multiple product backlogs and increments increases the complexity in an already complex environment.
These disadvantages can be addressed by the team itself. By creating a minimal base as Definition of Done and only expand from this basis for the different products reduces the complexity.
With the correct tool, combining and ordering multiple product backlogs is possible. Ordering multiple product backlogs for one team will still require additional focus.
Advantages of a multiproduct team
After summarizing the disadvantages of a multiproduct team, why would we still consider this approach?
Wider knowledge base
Not all products require the same size of development team. With only one or two people working on a product the knowledge base for the product is very slim. With a multiproduct team workload and thereby the knowledge for a product can be divided over more people. This way the product is less dependent on a single person.
Better quality and learning opportunities
The quality and effectiveness of team members is increased when developers have access to peer review and collaboration. Discussing solutions, architectures and problems helps when a team member is stuck and assures the combination of the knowledge of multiple team members which is beneficial for the quality. Another advantage of having multiple team members working on a product is the peer review, this prevents faults and favours the use of code standards.
By working together team members get more opportunities to learn from each other and develop their skills.
Combining product owner role
Besides having team members working on multiple products, having a product owner working on multiple products can be beneficial as well. The product owner role for a small product with only a few stakeholders and users or for a product that has only sporadic development activity doesn’t consume a lot of time or attention. Being a product owner is in this situation with only a small part of the activities, makes it hard to provide the responsibilities of a product owner with the necessary priority and attention. When the roles of product owner for multiple small products are combined in one person the availability of the product owner for the development team is increased and the focus of the product owner stays on the responsibilities of the role and on the products.
Ease of adding products
When a multiproduct team is implemented, upscaling the team with new products is fairly easy. The processes and systems are already in place.
Adding team members to an existing team will impact the dynamics of the team and will reduce the productivity slightly. But in comparison to creating an entire new team and implementing their own process, adding a product and thereby new team members to an existing multiproduct team will cost less time.
Conclusion
The benefits of implementing a multiproduct team are related to having a too small basis for a specific product team. Where the disadvantages apply to every situation. So when the product allows for a development team of at least more than three people implementing a product specific team is the most obvious and sensible choice. This will result in the best implementation of the scrum framework and the most optimal advantages from using the framework.
But there are situations where the advantages of implementing a multiproduct team will outweigh the disadvantages relative to a single developer working on a product.
In our case by implementing a multiproduct team we can provide a total service to businesses with relative small applications. We can take control and responsibility for an application now and in the future at an acceptable rate. This would not be possible or would lead to great risks if this would not be implemented in a multiproduct team.
The scrum guides states: “Parts of scrum can be implemented, the result will not be scrum.” The result of our implementation of a multiproduct team may not be completely scrum. But it results in being able to provide businesses with a total service by an Agile team with most advantages of using the scrum framework.
