Who decide team size?

Vinh,

The SM can certainly recommend an ideal team size (according to the Scrum Guide, the Development Team should be between 3-9 members). However, the SM does not have any decision-making authority on this.

The team size should be based around skill set, communication, and coordination considerations. Complexity of projects and technology specialization are considerations for identifying a team that is cross-skilled as a team in order to deliver value to the business.

Mature Agile organizations can promote the self-organization of teams along these guidelines. Otherwise, it is my experience that organizations usually decide on team rosters, and their decisions are not always wise or well-informed. That is why it is critical for a SM to communicate clearly the benefits and negatives around team size, skill, and experience.

A Development Team should have enough people with the right skills, between the limits of 3 and 9 members, to create an increment of release quality as per that team's Definition of Done.

Only the team itself can determine if it has the right membership and appropriate cross-functionality to do so.

Absolutely to both previous responses! Often management dictates Development Team size, contrary to the ideal of a self-organizing team. In general trust the Development Team; they will know when the team is too large to coordinate efforts effectively or too small to meet the cross functional needs. An organization that truly supports the Agile philosophy will trust and empower the team to do so. And allow them to learn from their mistakes when first embarking on work within the Scrum framework.

Hi everybody,
Scrum recommend a team size between 3-9.
What should I do as a SM if I join to a new project and the team is going to be of 13 (without SM, neither PO)?

Should I have 2 teams?

Thank you.

> What should I do as a SM if I join to a new project and
> the team is going to be of 13 (without SM, neither PO)?
>
> Should I have 2 teams?

Why is this decision yours? Shouldn't the team be encouraged to self-organize and to determine the optimal arrangement for themselves? Wouldn't it be better for a Scrum Master to coach and facilitate that?

Posted By Camilo Acosta on 02 Aug 2016 06:39 PM
Hi everybody,
Scrum recommend a team size between 3-9.
What should I do as a SM if I join to a new project and the team is going to be of 13 (without SM, neither PO)?

Should I have 2 teams?

Thank you.

As others have mentioned, you should facilitate a discussion with the team about team size and ask them what they think would be the best way to organize themselves with the constraint that they need to have a done, potentially-releaseable increment at the end of each Sprint. The existing team might organize into as many as 4 Scrum Teams or as few as 2.

Also, explain the "whys" behind the recommended Development Team size for Scrum to your Scrum Team. Scrum recommends a Development Team size of 3-9 people because a Dev Team of 2 people is typically too small to be cross-functional and to justify the overhead of the events and roles in Scrum. When there are more than 9 people on the Dev Team, communication usually starts to break down because there are too many people to work closely with.

For a sprint, when is a team composition decided ?  In the sprint planning meeting, product owner discusses the backlog. But who are the development team members attending that meeting ? Only after you know the backlog can the appropriate skill required for the development team be determined. 

So does that mean all developers available in the department joins it,  and after listening to what needs to be done they determine the individual developers for that sprint goal ? 

or

Randomly 7-9 people join the sprint planning and based on their skill set they decide what is the best product backlog they can cover in the sprint and go ahead.

> For a sprint, when is a team composition decided ?

Based upon your understanding of the Scrum Guide, how useful might it be to have a stable team membership over multiple successive sprints?

Shouldn't the team be encouraged to self-organize and to determine the optimal arrangement for themselves? Wouldn't it be better for a Scrum Master to coach and facilitate that?

Have anyone had a chance to facilitate such a process, where some of the Scrum Team members removed other ones with respect to self-organization? Could you share such an example?

I'm specifically interested in a case where those removed members didn't form another team. To me it is a very delicate matter that might be even considered as an ostracism, hence am curious if anyone went through it successfully (or not).

hi,

Have anyone had a chance to facilitate such a process, where some of the Scrum Team members removed other ones with respect to self-organization? Could you share such an example?

yes we had this before. I myself as a scrum master facilitated the discussion in the retrospective. the member in discussion mentioned himself, that he felt he didn't bring enough value to the team and was, with his knowledge and responsibilities, not overlapping enough with the goals of the team. (of course there has been feedback from other team-members before. I might have sparked the discussion by asking a general question about team efficiency). Afterwards I took the decision of the team to our department head and he took it on himself to find a more fitting position for (and with) the member elsewhere + made sure the team could still rely on getting future cooperation with  him if need be (however not highly synchronized as a team-member)

I have a question myself:

Our department head needs to allocate resources to different projects. Most of them are organized in scrum teams. If each team decides they need support by a person from our production planning (and synchronization) - but we only have one person available - there is an interest in conflict. Recruiting 3 more production ppl is not be the answer (costs and splitting of responsibility would be counter-productive). Of course the development head feels responsible (and in authority) for this. 

Whose responsibility is it to allocate the scarce resource in this case?

In Scrum, it ought to be the responsibility of Scrum Teams to self-organize their membership in the optimal way. A Scrum Master may facilitate that process, and explain the available options with their pros and cons, but no-one should organize teams on their behalf.

"For a sprint, when is a team composition decided ?"

I guess this question is not yet answered.

Sprint Planning of 1st sprint is attended by SM, PO and DM. Organization will decide who will be SM and PO. But who decides the initial composition of DM? Further analysis of who all will continue in Sprints among them or any new person needed in DM will be done during 1st Sprint planning, but what about initial composition of DM?

As per my understanding of Scrum Guide, the initial composition of DM will be decided by PO post guidance from SM. This is because PO is responsible for maximizing the value of the product.

Please correct me if I am wrong.

what is the accountability of product owner in sprint 0? Is PO responsible for composition of scrum team or is it gathering requirements for building product backlog?

also is it mandatory that product backlog items should be refined enough to fill first 3 sprints?

what is the accountability of product owner in sprint 0?

The purpose of a Sprint -- any Sprint -- is to produce a Done increment. Why would any of the Scrum accountabilities change?

is it mandatory that product backlog items should be refined enough to fill first 3 sprints?

Does the Scrum Guide stipulate that this is a  mandatory practice?

I know this is already an older question, but it's still a very valid and interesting one. 

I have this problem myself as Scrum master in a team that is to large. more than 14 people. this is coming from higher up. 

In this setup I encountered some problems that is keeping me from having real self-organizing teams. Some of the blockers I encountered: 

1. Working with suppliers where Hiërarchie has a big influence on how teams are orginized and created.  

2. "Used to working like this" ... mentality, where it's easier to keep working how it was before. 

Basically you already see, where is the Agile part? 

But this is not why I came here for this question, but it gives a more clear idea on the problem I'm facing if we have an agile mindset and let the teams decide on what needs to happen. 

If hiërarchie and "used to work" like this is overruling the mindset of the people, or has higher impact, It's not very valuable if team won't say it, even if they know it. Or they don't see it as a problem, because they where used to work like this in the past. 

So my solution was as Scrum master to have 2 subteams. Do an experiment and see what comes out of it. Is there more psychological safety? is there more collaboration? Do the meetings feel more valuable than before. and basically Yes to all those questions. It came from me, but I know the team themselves wouldn't come up with this solution, because of point 1 & 2. 

The questions I asked myself where: 

- is it possible to have a split so it's valuable for the teams. 

- How is the best way to do the split, is the knowledge enough in both teams to have a valuable outcome at the end of the sprint. ( that teams aren't blocked because there is no knowledge )

- What is the actual reason why management want to have so much people in a team. ( more people = faster delivery ? ) 

If a scrum master's job is removing blockers, and based on the observation of the Scrum master, if they think this could remove the blocking on some items, wouldn't they be allowed to do so. ( In case you are in a agile transformation period in a very big company and not everyone is open to the agile mindset ) . 

For me the biggest challenge is to help other people understand the value of smaller teams, have higher management to understand it, and to actually feel 

So my solution was as Scrum master to have 2 subteams.

This sounds very much like a manager making decisions for people that work for them.  Not like a servant-leader that helps empower people to do their jobs efficiently.  

I have this problem myself as Scrum master in a team that is to large. more than 14 people. this is coming from higher up. 

When the "higher up" told you that, you missed an opportunity to be a Scrum Master and help them understand how letting the team self-organize, self-manage can yield better results.  Were I in your place, I would have suggested that the "higher up" meet with the Scrum team and discuss why they feel it is too large and then let the team decide if they agree and how to proceed.

In this setup I encountered some problems that is keeping me from having real self-organizing teams. 

No, you became aware of impediments that the team is facing in becoming self-organizing.  As a Scrum Master, your focus should be on helping the team and organization remove those impediments or agree to a solution that is satisfactory to everyone.

The questions I asked myself where: 

These are questions that you should have posed to the Scrum Team and the "higher up" in order to help them become self-aware of the impediments that are prohibiting teams from being self-organizing and self-managing.  

For me the biggest challenge is to help other people understand the value of smaller teams,

Small teams do not always make things better.  If the team is small but does not have all of the necessary skills, access, experience, etc then the small team actually adds negative value.  Instead of trying to solve problems that you think are present, spend time discovering if there are problems.  In this case, if the team is consistently delivering high quality increments of value in a timetable that the stakeholders can absorb, is there really a problem?  Sure it could be against "conventional wisdom" but that doesn't mean it is a problem.  

I know that I've been critical of you but in this case, I really couldn't come up with a more friendly way to express my opinion.  And it is just that...MY OPINION.  Opinions are based upon knowledge.  Empiricism says that knowledge can only be obtained by learning.  You stated that your "solution" was going to used as an experiment.  I think that is great but the people doing the experiment have to understand the reasons for it.  Also the people that support the team doing the experiment have to understand.  Most importantly, everyone has to be willing to inspect, learn and adapt based upon the results of the experiment. I've been in your position more than once and nothing I ever decided turned out well.  However, every time that everyone involved in the situation was involved, a solution was reached that worked really well.  

What is the actual reason why management want to have so much people in a team. ( more people = faster delivery ? ) 

Why not ask them? They aren't implementing Scrum in this company -- instead, they appear to be imposing something else. What outcomes do they hope to achieve by doing so? A Scrum Master ought to be good at wondering.

Hi Daniel, Ian. 

Thanks for your answers. I agree with you both, and in theory it sounds easy. Just be there for the team and support them. This will work if you have teams that actually want to improve. 

Team is now used to micro management, where everything came from a higher level. The mindset was more in sync with: developers are lowest, and everyone who has a higher function, or works longer in the company you need to listen to. They know best, and they should come up with examples/ answers / solutions. For me this is the biggest bottleneck if we want to go to an Agile environment where everyone's opinion is taken into account, and people don't just wait for someone else to give an answer. 

So asking the team won't get you far, because everything is "ok". Asking about improvement is seen as "you don't work well" . So my opinion was, let them experience the difference. Is there a difference, do they talk more, are they more open in smaller teams. 

And as you mentioned about "higher up". This is the support you really need from your line managers. If you don't have it, is it even worth to try? Because hiërarchy is still such a big part, that sometimes as scrum master it feels more like trying to go over a big wall. 

If I understand correctly it is the Developers who decide who will be in the team. Is is also them who decide to remove a team member if he or she is not functioning well (of course after the SM encourages the team to work together to get the work done)?