I have been working in Agile Scrum teams all my career. I have worked in scrum teams sizes of two, three, four, eight, twelve and twenty. I have even worked in geographically distributed teams. It has been quiet an experience to work in teams of these flavor.
The team dynamics basically decided the team’s productivity. Here we measure productivity by the number of user stories burnt, the health of the code, the distribution of business/technical knowledge among the team members, the ease with which the team works with each other and the inverse of amount of discussion that happens before implementing things.
Larger Team Size
While working with teams of sizes greater than four-five, I found out that it was quiet difficult for every developer in the team to know about all the code written. This is a great drawback in Agile teams. Generally there is no or very little documentation about the architecture/design of the code.
Pair programming is the way by which the developers share knowledge. In a large scrum team, people generally continue to work on the domain/module they start working with as its very difficult to switch contexts in a big project. So, developers generally form pairs with other fellow developers with whom they are comfortable working with. This also prevents them to cross pair with each other.
All these factors finally hamper the knowledge transfer process within the team. Dependency on developers for technology/module starts originating which is a serious problem in Agile projects.
Its also not possible to listen to all in a team with large size. Generally, I have experienced that the meetings become useless if you have a team of large size. As it is very difficult to moderate such a large audience. Its also quiet tiring and irritating to listen to all views on all topics. There might be some differences in thoughts which need to be sorted out. All this results into meetings with no outcomes. There is always time needed to end up on some decision after meetings. This certainly hampers productivity.
Their are behavioral aspects of people which also affect the team’s performance quiet severely. There are always big mouths in team who try to speak a lot and overpower other mild speakers. This prevent other people to be open enough to share their ideas. So, the outcome of the discussions might not result in the best decisions.
All these lead to the feeling of disassociation from the project. The developers don’t feel any control over the projects and everyone shrinks in their own world.
Smaller Team Size
When the scrum team sizes are small, say four to five developers, then every developer is aware of almost every part of application. The code or at least the design/architecture is known to all the developers.
This is a great phenomenon as this knowledge empowers the developers to think over the application. This leads to better solutions and ideas being generated by the developers.
Being a small team, almost everyone pairs with everyone. This leads to knowledge sharing. The team has the complete picture of project. The developers feel associated with the project in this way. The dependency on any one developer is no or very little.
Everyone’s points/thoughts can be listened in this case. So, the meetings are meaningful as the team discusses on everyone’s thoughts. The decisions made in meetings are accepted by everyone. As everyone’s points are listened, chances of big mouths hijacking a discussion is very less.
Geographically Distributed Teams
The main problem that I face in geographically distributed teams is the lack of pair programming among differently placed teams. This can be due to the timezone difference of the geographical places. This leads to many more problems. The dependencies are created on different geographical teams. The different geographical teams claim ownership on different modules of the project and feel comfortable to work on that.
One team is not aware of the pressure conditions of the other team. The motivation levels of different teams can also be different. All this results in less productivity.
Conclusion
To conclude, I will say that always go for scrum teams of four five developers. If the project is very big and requires more developers, the form several scrum teams of this size. Never go for a large scrum team. This will lead to chaos and loss of productivity.
