This is the third in the list of agile limitations:

1. A team of stars
2. Fit with organizational culture
3. Small team
4. Collocated team
5. Where's my methodology?
6. Team ownership vs. individual accountability

Agile teams are restricted in size for several reasons:

• The team has to self-organize, implying an efficient order emerging from temporary chaos. Obviously this process would be too long for larger teams.
• Team members have to be able to communicate spontaneously with each other and with other stakeholders (i.e. without setting up meetings, sending emails, etc.).
• All team members participate in the day-to-day management (tasks, changes, impediments, etc.).
• Team members need to understand what others are doing (cross-functional perspective, team ownership), help each other with ease, and collaborate without centralized control.
• The team has to be co-located (this limitation will be examined in a separate post).

As you can see, agile is a highly participative style of software development. Therefore, the number of participants significantly affects the efficiency of the process.

The daily scrum of the Scrum agile methodology perfectly illustrates this limitation. The daily scrum is a 15 minutes meeting involving the whole team. The ScrumMaster (Scrum word for team leader) goes around the table and each team member mentions the status of tasks and other issues such as impediments or changes. I managed Scrum teams of sizes varying from 3 to 8, and I must admit that in my opinion 8 is about the upper limit. Beyond this size, communication becomes inefficient.

Assuming that large projects tend to require large teams, this restriction naturally extends to project size.

Fortunately, there are solutions to somewhat alleviate this limitation. If a large project can be divided into a number of relatively independent smaller subprojects then each part can be implemented by an agile team. However, this solution is not without its own quirks:

• There has to be a "higher-level" project management to coordinate the teams. This higher-level can be managed with a more "traditional" methodology. Note that we see here a situation where combining agile and traditional methodologies makes sense.
• When dividing the project into agile-manageable subprojects, we minimize dependencies through architecture. However, agile measures progress based on working software, i.e. delivering features. Dividing a complex project based on architecture yields a very different result than dividing it according to features. Therefore, the agile definition of "progress" - one of the agile cornerstones - has to be adjusted.