A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

The problems with having a large Scrum team – say more than 10-11 people (especially when more people are added to the team)

In the past, when our teams have been experimenting with how to breakup the overall size of the team into Scrum teams, and we were trying to break the teams up into sizes of 7-9 people (excluding the Product Owner and the ScrumMaster). However, since there were times when there was an effort to accommodate more people (for example, if 2-3 more people joined the product team), there was a lot of queries about whether there is a problem if we increase one of the Scrum teams by 2-3 people, to make a 11-12 member Scrum team. However, this came with its own set of issues, and here is some of our feedback from working with a larger Scrum team.
– As you increase the size of the Scrum team, you get into issues with the Daily Scrum meeting starting to become less of a group and more of a meeting run by the ScrumMaster. You need some regimentation and discipline (to ensure that the meeting runs on time, people make it to the meeting, and so on), but that makes the meeting start to feel a bit more stiffer.
– From the above point, the team stops losing the huge power of empowerment and self-organization; and you need to start getting more documentation and notes of the Daily Scrum meeting to track progress and action items
– One concern that a team has is in terms of splitting an existing Scrum team into multiple teams is about having the same ScrumMaster and Product Owner to handle these additional teams. However, this should not be a blocker since the existing ScrumMaster should be able to handle a new team, and the same with the Product Owner (if it turns out that the ScrumMaster and the Product Owner are over-loaded, then that is a bigger problem that needs to be handled).
– Once you start having more Scrum teams, with them working on the same product or on the same area, then you should consider using a Scrum of Scrums (read more on Scrum of Scrums here) to do more effective coordination and resolving dependencies
– Consider that when the number of teams increases, there is a slight hit since the new team has to start getting into the Scrum cycle and there is some learning and some amount of time before the team start getting into an efficient mode
– However, if you decide to split the team with the addition of new members, then you need to consider the point that splitting teams (especially if you have only 1 Scrum team that now splits into 2 teams), there can be a feeling among team members that they are not getting all the information that they require. This will need more communication and information sharing for some time, before the team feels comfortable again.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>