Today's #daretochange will be a bit less controversial. But I will recommend splitting your team (even a small - 4 people maybe?) into groups. How can you maximize its output? Today I'm asking Peter Gfader, David Sabine and Joshua Partogi 's professional opinion. My opinion can be found in the first comment below. #scrumteam #scrum #teamwork #selforganization
Scrum teams may split up during the Sprint events too. For example, I worked with a team who was responsible for developing and maintaining an app on multiple platforms (Android, iOS, and web). During Sprint Reviews, they found it very effective to set up *stations* — each station would feature many devices (e.g. Samsung, LG, Apple phones and tablets; e.g. multiple computers preloaded with various browsers (e.g. Safari, IE, Chrome, Firefox). Stakeholders would split up, visit each station (think Science fair or museum) and the team members at each station would capture feedback. Then, everyone would gather for the latter half of the Sprint Review to compile the feedback and inspect/adapt the Product Backlog together.
There are plenty good reasons to temporarily, intermittently, or permanently split a team. Thanks, Kate, for initiating this discussion. Throughout a Sprint, for example, Scrum team members morph into pairs or mobs as they conduct the work of the Sprint Backlog. In self-organizing cross-functional teams, it occurs ad-hoc and informally as people combine their attention and effort to solve problems together. With respect to planning, each ad-hoc collective plans and executes their tasks — they do so without having to gather the entire team to plan every implementation; yet, they do so with respect to the team's design patterns, architectural vision, and quality goals.
Maximising output? Is the development like factory workers whose sole goal is to generate as many outputs as possible? 🤪
My view can be found here: https://www.scrum.org/resources/blog/splitting-your-team-reduces-planning-time
Also, perhaps obvious, splitting a team may make good sense if the team grows too large. (What is "too large"?) The Scrum Guide suggests a team of roughly 9 will struggle to maintain cohesion — significant effort is required to communicate effectively and people will tend to split up naturally. Rather than fight that tendency, it may be important to have deliberate discussion during Retrospective how best to split the group into smaller, distinct and independent teams.