When starting development of a brand new product with fifteen developers, forming effective teams is a critical early decision that significantly influences the success of product development. From a Scrum Master’s perspective, multiple approaches are commonly used in practice. Each approach offers distinct benefits and drawbacks when evaluated against Scrum principles such as self-organization, cross-functionality, and value delivery .
1. Facilitating Teams to Self-Organize
One common approach is to facilitate the developers in forming teams themselves . This approach aligns strongly with Scrum, as the Scrum Guide states that Scrum Teams are self-managing and decide internally how best to accomplish their work.
Benefits:
Allowing teams to self-organize promotes empowerment, ownership, and accountability . Developers can use their existing knowledge of each other’s strengths, weaknesses, and working styles to form balanced teams. This often increases motivation and psychological safety, both of which support high performance.
Hindrances:
For a new product, this process can be messy and time-consuming , especially if developers lack experience in forming effective teams. Teams may optimize for comfort or familiarity rather than cross-functionality, potentially leading to skill gaps or imbalanced teams.
2. Forming Two or Three Cross-Functional Feature Teams
Another common approach is to deliberately form two or three cross-functional feature teams , each containing all the skills necessary to deliver working product increments.
Benefits:
This approach closely matches how Scrum describes teams. Cross-functional feature teams can independently deliver integrated, “Done” Increments of the product, improving flow, reducing dependencies, and supporting empiricism. All necessary skills are available within the team, enabling faster inspection and adaptation.
Hindrances:
In the context of a brand new product, teams may not yet know which skills are actually required , making it difficult to form truly balanced teams upfront. Additionally, specialists may feel isolated and lose regular interaction with peers who share the same expertise across teams.
3. Forming Teams Based on Specialization (Component Teams)
A third approach is to organize teams according to technical specialization , such as front-end and back-end teams. These are often referred to as component teams .
Benefits:
This structure allows specialists to work closely together, enabling fast knowledge sharing, technical consistency, and deep expertise in specific components of the system. It can feel efficient, especially in the early stages of development.
Hindrances:
From a Scrum perspective, this approach significantly hinders value delivery . Component teams struggle to deliver complete, integrated features independently and introduce dependencies and handoffs. This makes it harder to produce a usable Increment each Sprint and is not how Scrum describes teams , even though it remains a commonly used strategy in many organizations.
Scrum Master Perspective and Conclusion
As a Scrum Master, my role is not to mandate a single team structure, but to coach and facilitate the organization toward structures that best enable Scrum. While all three approaches are seen in practice, Scrum clearly favors self-organizing, cross-functional feature teams because they maximize learning, transparency, and the ability to deliver value each Sprint.
