Why are Agile teams supposed to be small? How big are they supposed to be? Most agilists tend to agree that a team of ten people works well.

But what is it about the number 10 that makes it the “magic” number?

Since the start of human evolution, people formed groups to be more effective. Whether it was the hunt for a mammoth or going to war, working in teams ensured a greater chance of success.

There have been various researches from Dunbar’s paper through the Scrum Guide to military formations about the ideal number of people in a team.

We’ll discuss the historical, scientific and cultural reasons why 10 seems to be the magic number of forming effective teams.

Does the number of team members really matter? Is 10 really the magic number. You will get an answer that will help you to create effective teams with the right amount of people.

 
 

Outline/Structure of the Talk

45 minute of talk covering the following topics:

  • History of teams from roman legionnaires through tea houses to modern armies
  • Anthropology and team sizes, the Dunbar's number
  • Team sports, size of teams and roles within a team
  • Religions and team sizes
  • Biology researches, how do other species team up?
  • Team sizes in modern software development. Scrum, XP, SAFe, etc.
  • Conclusion on the magic number

Learning Outcome

Create effective teams with the right amount of people.

Target Audience

Facilitators, Trainers, Scrum Masters, Agile Coaches

schedule Submitted 2 years ago

  • Alex Sloley
    keyboard_arrow_down

    Alex Sloley - The Product Owner and Scrum Master Brain Transplant! Mwuhahahaha!!!

    Alex Sloley
    Alex Sloley
    Alex Sloley
    schedule 2 years ago
    Sold Out!
    25 Mins
    Talk
    Intermediate

    Imagine you are a Mad Agile Scientist and have a diabolical experiment to conduct - what would happen if you exchanged the brains of a Product Owner and Scrum Master? Mwuhahahaha!!! How would the body of a Product Owner with the brain of a Scrum Master act? And vice versa?

    Perhaps the Scrum Master would now treat the team like a backlog? This Scrum Master would be focused on value and maintaining a coaching backlog of team and person improvements. This Scrum Master is refining the team, crafting a group that delivers value.

    And perhaps the Product Owner might treat the backlog like a team? Rather than backlog refining, they coach the backlog. They would be focused on nurturing, protecting, and empowering the backlog. The backlog might transform from an irritation into a labor of love.

    Although this experiment sounds terrible, this change of perspective might be what you need to reanimate your dead team or backlog.

    Join the fun and come learn what horrifying results await!

help