Documents Say…

The Agile and Scrum literature, including training classes, recommend a team size of “seven, plus or minus two.”  This means a Scrum team should have 5-9 members as the ideal size.  In Scrum this number includes the Product Owner and ScrumMaster.  There are many reasons for this recommendation:

• A team smaller than five decreases diversity of skills, opinion and background too much, which hurts creative capacity.
• Imagine a retrospective on a team of three people. There is a strong tendency toward either a regular complaint session or mutual admiration society.  Neither of these would lead to productive improvements very often.
• A large team requires too many relationships at once.  For example, every member of a 10-person team has nine relationships to maintain, with a total of 90 relationships in the team.  Add an 11th member and the number of relationships goes up to 110!
• The overhead of coordination grows with team size along with the difficulty in maintaining relevance between the members.

Experience Says…

I was once the ScrumMaster of a seven person team.  We were starting the creation of the base technology for a the company’s next generation of products.  Exciting stuff!  We hired or pulled people from other projects to grow the team as the work progressed.  At around twelve members I began asking about splitting the team, to keep the size reasonable.  We decided against it, that we wanted everyone to be aware of what was happening in this complex work.

And the team continued to grow.  Software engineers, hardware engineers, VHDL (embedded stuff) designers and so on were added.  Soon we had 26 on the team.  Yes, it was big, way too big.  We still held our daily stand-up meetings and kept them to 15 minutes or less most of the time.  We worked hard to keep meetings tight and relevant.  And we failed at keeping the energy up.

Splitting Is Good To Do

After several sprints we finally had consensus to split the team into three.  Let me paraphrase some things people said about their new team size after the first sprint:

• Retrospectives are better because it is easier to write items for “well” and “improve” because didn’t have to worry about boring other members with things they don’t care about.
• Daily meetings were not an interruption of hearing about things I wasn’t working on.  I could work, go to the meeting and go back to work with the same thread of thought.
• My team members are helping me more often now. I guess they didn’t really see when help was needed when we had such a large team.

Large or Small, Watch

Whether your team or teams are large or small, watch what is happening.  Pay attention to the information flowing in meetings and during the work.  Especially give a strong look at what is happening in the retrospectives.  Are things discussed shallow or repetitive?  Is there confusion when clarity was expected?  So some members feel alone in the team?  The size of the team may be something you can change to remove such doldrums and re-energize the communication!

Those familiar with Scrum and XP and other agile practices know about the daily team meeting.  Sometimes called a “daily stand-up,” this is a meeting held every day at the same location and time.  In this 15 minute meeting the team usually stands in front of the team board to discuss three questions, and three questions only:

A Simple Task Board

• What did you get done since the last meeting?
• What will you do before the next meeting?
• Do you have any impediments to your work?

The team board has story and task cards that are moved across to document the progress of each task.  Each team member owns the task he is working and signifies that ownership by moving his task cards in turn as he answers the questions.

So what is the elephant in the room?  In this team’s case, it is the table.  Yep, a simple and useful object that decreases the effectiveness of the daily team meeting.

This team does not have a dedicated team room.  This less than ideal situation is handled by using a task board on wheels that lives in the hall where the team members work for visibility throughout the day.  The board is wheeled into a conference room for the daily team meeting.  The conference room has a table in the middle.  A large one that is difficult to move.

The team board is placed on one side of the room and, due to the limited space directly in front of the board, the team groups on the other side of the room.  With the table in the middle, between the team and the team board.  Suddenly, it is too cumbersome for each team member to come around the table and move their own task cards.  The ScrumMaster stands at the board to move the cards for the team.

List the damage:

• Team disconnected from the task board
• Members disconnected from ownership of their tasks
• The meeting feels and operates like reporting to the ScrumMaster instead of reporting to team peers
• Less energy in the room
• Team is physically divided

Scrum is about people, not technology.  The subtle but real psychological effects cause by the table cut the effectiveness and communication of the team in half, or more.  It seems a small thing, it’s just a table after all.  In physical reality, perhaps it is small.  But the mental and social structure of the team is decimated.

Maybe you can think of more negative effects of this situation.  It’s all bad.  And it’s just a table.

Does your team room or meeting location have such “elephants” in the way?  Are the chairs too inviting?  Is the lighting wrong?  Assess your environment to from the team cohesiveness point of view and eliminate the physical “elephants” that distract your team from the best agile experience possible!