Context:
The development organization is embedded in the context of a larger organization, usually that of the sponsoring enterprise or company (see the Rationale).
This applies specifically to organizations that create software, and may not as directly apply to organizations whose job is integrating existing software, for example.
Forces:
Too large, and you reach a point of greatly diminishing returns.
Large organizations are ships that are hard to steer.
Too small, and you don't have critical mass.
Overly small organizations have inadequate inertia and can become unstable.
Size affects the deliverable non-linearly. Communication overhead goes up as the square of the size, which means that the organization becomes less cohesive as the square of the size while the "horsepower" of the organization goes up only linearly.
New people interact much more strongly with others in the organization, and interact more broadly across the organization, than mature members of the society who have assimilated its context.
Solution:
By default, choose 10 people; experience has shown that suitably selected and nurtured small team can develop a 1,500 KSLOC project in 31 months, and a 200 KSLOC project in 15 months, or a 60KSLOC project in 8 months. Do not add people late in development, or try to meet deadlines worked backward from a completion date.
Resulting Context:
An organization where nearly everyone can have "global knowledge." We have found empirically that most roles in a project can handle interactions with about six or seven other roles; with 10 people, you can almost manage total global communications (and a fully connected network may not be necessary). On the other hand, 10 people is a suitable "critical mass."
This pattern is closely coupled to the patterns that support organizational growth below, Phasing it In and Apprentice. This pattern also interacts with Prototype.
Design Rationale:
Keeping an organization small makes it possible for everybody to know how the project works. Projects that do well have processes that adapt, and processes adapt well only if there is widespread buy-in and benefit. The dialogue necessary to buy-in and benefit can accrue only to small organizations. Tom DeMarco has noted that everybody who is to benefit from process should be involved in process work and process decision-making.
Having 10 people at the start is probably overkill, but it avoids the expense and overhead of adding more people later.
This pattern is for large projects. Projects larger than 25KSLOC can rarely be done by an individual (see Solo Virtuoso).
Different management styles (leadership-based, manager-based) lead to the success or failures of different organization types (democracy, republic, oligarchy). Leadership-based management styles help these organizations work; the compelling need for a democracy is less felt, because project members feel they are well-represented under an appropriate management style. [This may be a new pattern about management style.]
A single team is better than a collection of sub-teams. The faster a team breaks up into sub-teams worrying about their own responsibilities rather than those of the larger team, the less effective the enterprise will be as a whole.
Many software development cultures support technical manager groups up to this size. Adding more people would force a group split, which can cause a large decrease in productivity, all other things being equal.
Further study might evaluate the relationship between this pattern and Alexander's "The Distribution of Towns" [Alexander 2] and related patterns. Here, we stipulate that the social organization must be small; it reflects a ``Subculture Boundary'' [Alexander 13] and ``Identifiable Neighborhood'' [Alexander 14]. Alexander emphasizes the grander architectural context that balances support for the ecology with the economies of scale that large towns can provide, while supporting the xenophobic tendencies of human nature. Small organizations like that being built here rarely exist in isolation, but in the context of a broader supporting organization. This relationship to the larger organization invokes Patron.
As to adding people late in development, staff-month myths abound. One manager writes: "On [one] project, I grew from 10 to 20 people to meet a customer contract....with new people, [I] wound up three months late because of `absorption' of new folks into the organization."
Next: Self-selecting Team