Having two daily standups for large teams
Our team, including development and test comprises 1 system architect, 10 devs and about 10 testers. Every member of this 21 person team participates in the same daily standup. Even though we complete the standup in about 20 minutes, I am starting to wonder if this is too big a group to be engaging in a single standup.
What I am actually noticing as one of the scrum masters, is that some members of the group take this opportunity to engage in personal egotistical battles and this typically ruins the moral, making standup go longer.
I will like to propose to my manager and partner scrum master on splitting the daily standups into two separate groups, with a mix of dev and testers or some other reasonable composition. I usually though that when scrum teams exceed a certain number such as 10, they need to be split.
What are your thoughts or experiences?
Thanks,
Klaus
An interesting experiment after a daily stand would be to ask some random team members if they could comment on the progress toward the Sprint Goal, done by an individual team member or for the team as a whole.
My bet would be that nobody has any glue for nobody shares or receives any useful information about how you are doing as a team. Maybe except these guys that are going into battle for they are at least frank and open in communicating something is dead wrong.
It is your responsibility as a Scrum Master to resolve impediments, and one of the simplest impediments to recognize is a violation of the basic Scrum rules, in this case team size and number of Scrum masters per team.
The Scrum Guide will tell you about optimal team size, and the roles and responsibilities of a Scrum Team.
When splitting a large team, think about:
- how the dependencies between teams can be minimized
- how each Development Team can provide feature-complete deliverables
- how these deliverables will be integrated into a potentially releasable increment at the end of each Sprint
- how the teams will self-organize when drawing work from the same Product Backlog
- how Sprint Planning, Reviews, and Retrospectives will be co-ordinated
- how the Development Teams will self-organize and replan during the Sprint to ensure the Sprint Goal is met
- how the Definition of Done will be improved and jointly observed by the teams