Why to keep teams at a small size
Just yesterday I read the article from Joel Spolsky about A Little Less Conversation. Despite it being an article from the future, Feb. 1st, it reminded me a lot of the experiences I've collected in our company myself.
In short, Joel repeats once more the sadly not-common-knowledge that the more people are on a team the slower and less effective it gets. "Adding people to a late project makes it later!". He explains this counterintuitively effect, that the number communication paths does not grow in a linear way with the number of team members. Instead it grows much faster so that on a team with 10 people you already have 45 different paths of communication which have to be managed and synchronized. And if everyone on the team has to kept up-to-date with the information-flow the overhead for managing this information (even if just sorting into relevant/irrelevant) can quickly reach nontrivial amounts.
There are two ways to soften this problem. The one with the bigger impact is to keep your teams below a certain size. In our company the experience seems to come up that our Scrum teams work best if they do not exceed eight people. If with or without Scrum Master depends on the team. The second measure which can be taken is, that not everyone is invited or updated with information which is unrelevant for his or her position. Even more so if there is no influence possible for these people. But people also have to understand that it's not out of personal dislike or conflicts that they aren't kept up-to-date with everything on the company but that this lowered information-level allows them to concentrate more on their actual stuff which they are working on and removes a lot of unnecessary interruptions.