How to organize Scrum teams

Agile, Microservices, Scrum

Read the Article on Medium published in the Serious Scrum publication

What Scrum suggests

Company products can vary in complexity. To manage them may be required from groups of 2-3 people to groups that can involve more than 100 people. The Scrum guide suggests to have teams composed from 3 to 9 members;  The Product Owner and Scrum Master should not be counted in the group size, unless they implement the backlog items themselves. As the complexity of the product starts to increase and the number of people involved in development begins to grow, there is a need to make decisions about how to divide groups.

Division by business initiative

Some Agile coaches suggest dividing the teams by business initiative. It means that for each initiative sponsored by the portfolio management is formed a team that is in charge of the initiative. The main reason for proposing this kind of organization is that the team has all the needed competencies to complete the initiative. A Business initiative can be any new requirement or improvement to be added to the product, for example:

  • Integration with a new external system
  • Software architecture change to improve performances
  • Creation of an analytics platform

The main drawbacks of this kind of organizational approach are:

  • Duration of the business initiative can vary a lot, from a few weeks to years: it could be needed to change the members of the Scrum team after a few weeks, this is not in line with Scrum best practices that suggest having stable teams over teams that change frequently. Moreover, there could be not even the time to arrive at the performing stage of team development.
  • The business initiative can have impacts on multiple functional areas of the program: the teams can end up working on the same functional modules, creating dependencies among the teams’ implementations that generate conflicts on the source code that will slow down the development phase. Moreover, if these dependencies are overlooked there will be issues on merging the features that can have conflicting business logic.

Division by technology expertise

This is the worst case, when the teams are divided by technology expertise there will be dependencies among the teams to implement a part of a software module:

  • GUI experts
  • Back end experts
  • DevOps experts

with this kind of organization, it will be very difficult to coordinate the teams to have a working product at the end of the Sprint. The new functionalities will be implemented dividing it in front-end, back-end, infrastructure. This is not in line with the idea of having a complete functionality that is demonstrable to the Product Owner and the other stakeholders at the end of the Sprint.

Division by functional areas

The sharing of the responsibilities of the groups involved in product development is linked to product architecture. You can’t just create groups and assign the implementation of the requirements as soon as they’re ready for development, without being clear which area or functional module the requirement belongs to. This behavior creates conflicts and dependencies during development that is a waste of time both in the implementation phase of the requirement and in the merge phase.

The first important thing when deciding how to split groups is to be clear about what business features the product offers. This allows you to assign a group responsibility for one or more business features that do not overlap. For example, systems that support a telecommunications company’s business include the following business features:

  • Catalogue Management
  • Order Management
  • Inventory Management
  • Charging
  • Billing

So you can have a team of 3-9 people for each functional area. Where the functional area is still too large to be managed by a single team, it can be further divided into functional modules so that the team can manage it. For example, the functional area of Catalogue Management might be divided into Commercial Catalogue Management and Service Catalogue Management.

Defining the business capabilities of a product is not always trivial and is usually an iterative process. The boundaries and responsibilities of each module are refined with experience. The process of defining and refining business capabilities requires a good understanding of the structure, area of expertise, and business processes of the business organization.

Microservices

The decomposition of the product into business capabilities is also a necessary step to move towards a microservices architecture. In a microservices architecture, each service must be small enough to be developed by a single team. In addition, each service must respect the single responsibility principle. That is, it must have only one reason to change, and the functionality implemented by the service must be fully encapsulated in the service itself.

Scrum Self Organization

Scrum suggests having self-organizing teams. Once that the roles are defined and the functional areas identified it will be possible to adopt some strategy to help the teams in self-organizing. I strongly suggest having the product split into functional areas, each functional area can have its Product Owner; if the organization is going through a transformation towards Scrum it could be adopted the Marketplace strategy described in the post linked. Instead, if the product is growing and more people are needed to develop it, the team can grow until it reaches 9 team members; when a larger number of team members is needed, involve the team members in the decision on how to split the teams to have a shared agreement on the new organization and a positive feeling about the needed change.

If you liked the article you can share it using the social bar. Thank you for reading!!!