The Ideal Scrum Team Composition for Agile Development

This article was originally published here.

In my previous blog post, I discussed the prerequisites to adopting Scrum. Once you have the basic foundation in place, the next step is to sort out your Scrum team composition. In this post, I’ll focus on the importance of having an enthusiastic Scrum team. I won’t go into depth describing the profile of each of those roles, but I’ll explain the responsibilities associated with each role.

Scrum specifies three major roles that play a part in the Scrum Team: Product Owner, Scrum Master, and Development team member. Besides these roles, you should also expect to have Stakeholders. In larger enterprises, there are usually (several) Business Analysts (BA) involved in a software implementation. I’ll describe how they all fit into Scrum. Additionally, I’ll introduce the concept of Subject Matter Experts (SME), those people who hold the key to the Scrum team’s success.

The Scrum Team

The Scrum team includes the: Product Owner, Scrum Master, and Development team. These individuals share different tasks and responsibilities related to the delivery of the product. Scrum describes this as a self-organizing and cross-functional team. But how can you facilitate this concept within your team? Here’s a list of key characteristics that are important to consider when creating your Scrum team. I’ve described these characteristics based on the ideal scenario:

1. Self-managing; Each Scrum team decides how the group will work. Within this team, each member is equally important (no-hierarchy), but responsibilities are clearly defined. This means that each team member should get equal opportunity to voice his or her opinion. Together, they can then form a solution. Ultimately, the Product Owner gets the final say about prioritization, but all other discussions are guided by the Scrum Master to a solution everybody agrees with.
2. Cross-functional; The team should possess all knowledge required to deliver a working product. This does not include business knowledge but does include sufficient knowledge about: QA, UX, integrations, etc. This does not mean that each team member should be the perfect developer and have all of this knowledge, but this knowledge needs to be spread across team members.
3. Co-located; Scrum is all about close collaboration. Ideally, the entire team would be sitting in the same room so that there are no barriers (no matter how small) to communication. When team members are spread out over different rooms, locations, or time zones, it is normal for people to postpone their interaction.
4. Dedicated; Every member of the Team should be assigned to the project full-time as any distraction will just delay work. Focused work is far more effective than switching between assignments or dividing your attention between two projects. Being dedicated to a single project is also the best way to take up ownership and responsibility, (allowing for better self-management).
5. Long-lived; Try to keep teams together. Don’t make frequent changes in teams. New Scrum teams take time to learn to work together; therefore, making frequent changes (even between projects) requires time for the team to learn to work together.

What do I mean by cross-functional?

In an ideal world, your Scrum team is cross-functional and all knowledge for all aspects is available within the team. This includes knowledge about, Testing (QA), styling and User Experience, but also sufficient knowledge about all integrations that might be necessary. However, I realize that it isn’t always realistic for Scrum team members to know especially detailed knowledge about integration with other systems. In this instance, you need to make sure that your team has access to all the knowledge they need. Depending on the size and complexity of the project, it might make sense to include the Integration expert, QA-er, UX-er as a full-time team member. But if you’re working on a small Scrum team, introducing those experts would create too much overhead. In those instances, you need a Subject Matter Expert (SME).

Introduction of an SME

When talking about Subject Matter Experts, we’re usually talking about an experienced business user whom the Scrum team engages with for questions. But from the Scrum team’s perspective, I would describe an SME as: every person that possesses knowledge the team needs for a successful product delivery. For further reference, all SMEs are also considered Stakeholders for this product (but not all Stakeholders have to be SMEs).

This allows us to classify several roles as SMEs, such as a Systems Admin (Infra SME) and UX expert (UX SME). But we can even classify developers, Scrum Masters, or Project Managers from other teams as SMEs for their respective projects. A team member of this Scrum Team can even be an SME for another Scrum Team.

But remember, an SME is not part of the Scrum Team. And as such, this person cannot be held responsible nor accountable for any work they do for the team or Product Owner. This creates some challenges, and you should not resolve this by making an SME responsible for his work. Making an SME responsible could make team members responsible for work done by multiple teams which introduces a much bigger problem because it conflicts with the earlier described team characteristics (numbers 1, 2 & 3). We’ll go into this in more detail in a later blog post. But in the meantime, you can read more in this great book: ‘Exploring Scrum: The Fundamentals’ by Dan Rawstorne.

The Scrum team might need the SMEs for different purposes and at different times, but they are all expected to answer questions and perform tasks to improve the product. During the planning meetings, you can identify when information or actions are expected from the SMEs, and a Scrum Team Member can follow up with the SME to complete the action on time to prevent delays to this product delivery.

By using this broad definition of SME, we are setting clear expectations. If the Scrum Team needs a person to help on an activity for this product, that person is seen as an SME and knows what the team expects.

The Development Team

Previously, I explained the Scrum characteristics and introduced the concept of the SME. When we look in detail into these characteristics, specifically the cross-functional requirement, we can understand the scenarios that require an SME versus an additional team member.

The cross-functional characteristics always seem to create confusion. In a perfect world, every team member knows everything about every aspect regarding the development, but realistically it would require that every necessary role is part of the development team. If certain specialized skill-sets (QA, UX) are needed, an expert with those skills should be part of the Scrum team.

Don’t decide to assign those experts to multiple teams. Always stick to the ideal team characteristics, which state that all team members should be dedicated. If for any reason this expert can’t become a full-time team member, you should consider them as an SME and engage them that way throughout the project.

Keep it simple and consistent; don’t try and start your first project inventing new roles such as temporary team members or anything similar. That only creates confusion around their expectations and responsibilities and introduces risks.

Scrum only specifies that a Scrum team (including PO & SM) should never be bigger than 9 people. For large enterprise projects, I think the ideal Scrum team size is 7 people (PO + SM + 5 Dev Team). For smaller projects, I’d recommend a minimum team size of 4 (PO + SM + 2 Dev Team). With any team smaller than this you wouldn’t really be doing Scrum, or you would be creating a lot of overhead with all activities. If you want to work with smaller teams take a look at other types of Agile development such as Kanban.

What about my Business Analysts?

Many enterprises currently work with Business Analyst to gather and clarify their requirements. They have experience and knowledge that can be extremely useful to a development project. But since Scrum is all about close collaboration between the Scrum Team and the Business, a BA in their current role would prevent that. In order to accurately describe how a BA can effectively work in a Scrum Team, we first need to understand the exact role and responsibility of the person responsible for the requirements, the Product Owner. In the next blog post, I’ll go into more detail to the Product Owner and will also explain how a BA can support the Product owner and the rest of the Scrum team.

In summary, try and keep your Scrum teams small and simple. By introducing more people in roles that aren’t specified by Scrum, you create unnecessary challenges for yourself. The easiest way to start adapting Scrum is to have all participants in the project follow Scrum by the book. This can be a difficult change, but it allows for the most clarity for everybody involved. Making changes in anything from day one is not a good idea. Change should happen based on lessons learned. Scrum works for the majority of organizations that use it so why not for you? Improving comes after trying it out first.