Diff for "OrgPatterns/Size the Organization"

...within a larger organization, usually that of a sponsoring enterprise or company, there need to be smaller organizations capable of creating large software systems (greater than twenty-five thousand lines of code) that meet competitive cost and schedule benchmarks.

This pattern shows how the proper sizing of an organization is vital to the health of the project and the productivity of its people.

✥ ✥ ✥

Large software projects (greater than twenty-five thousand lines of code) are seldom delivered on time and within budget when the development team is too large or too small.

There are two arguments that have led us to this conclusion:

1. There are limits to the size of software development teams that allow them to work effectively. A team can handle a larger problem than an individual can ([BeyerHoltzblatt1998], p. 4).

2. Adding people late to a project rarely helps complete that project on time and within budget.

1. If a software development team is too large, you can reach a point of greatly diminishing returns. We have found empirically that an organization’s size affects a 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.

In addition, if the organization is too small, the team won’t have critical mass and productivity will suffer. Projects larger than 25KSLOC can rarely be done by a SOLO VIRTUOSO (4.2.5) and overly small organizations have inadequate inertia and can easily become unstable.

However, experience has shown that a suitably selected and nurtured small team of around 10 people can provide a suitable critical mass with a capacity to develop a 1,500 KSLOC project in 31 months, a 200 KSLOC project in 15 months, or a 60KSLOC project in 8 months.

Keeping the organization small makes it possible for everybody to have knowledge of how the project works (“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).

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 De Marco has noted that everybody who is to benefit from process should be involved in process work and process decision-making.

Further study might evaluate the relationship between this pattern and Alexander’s THE DISTRIBUTION OF TOWNS ([Alexander1977], ff. 16) and related patterns. Here, we stipulate that the social organization must be small; it reflects a SUBCULTURE BOUNDARY ([Alexander1977], ff.75) and IDENTIFIABLE NEIGHBORHOOD ([Alexander1977], ff. 80). 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 ROLE (4.2.15).

2. Adding people late to a project rarely helps complete that project on time and within budget.

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.”

Many software development cultures support technical manager groups up to around 10 people. Adding more people would force a group split, which can cause a large decrease in productivity, all other things being equal. We have also found that 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.

Therefore:

By default, choose about ten people to establish critical mass in the development of large software systems and avoid adding individuals late in the game, or trying to work backwards from a completion date.

Experts vary on the exact number; the number 10 has a bit of tradition associated with it, but numbers like 6 or 7 are also common. Two is too small, and 13 is too big.

✥ ✥ ✥

Having 10 people at the start of a large project can be overkill, but it avoids the expense and overhead of adding more people later. However, once a core team establishes an identity, it can grow graciously by PHASING IT IN (4.2.3) or using APPRENTICESHIP (4.2.4). The organization can generate knowledge early on by building and throwing away a prototype (see BUILD PROTOTYPES (4.1.7)). To decide whom to hire into the nascent organization, use patterns like DOMAIN EXPERTISE IN ROLES (4.2.22) and ARCHITECTURE TEAM (5.2.4). SMALL WRITING TEAM (10.5.27) [Bramble2002, p. 31] suggests that two or three people be used to write the use cases; others will be in other roles.

Astute readers might consider this pattern and remark, “You have a strange idea of what constitutes a large project! I can see this working for projects that will grow to thirty or forty people and maybe a few tens of thousands of lines of code. But how about for really large projects?”

First, it’s important to understand that there are few real software development teams that are larger than a few dozen people; larger projects almost always self-organize into subcommunities (DIVIDE AND CONQUER (5.1.6)). But even the largest projects start with an idea, and an idea starts with an individual or a small group of people. This pattern says that a small group should take the project as far as they can before other staff are actively engaged. One of course must anticipate the point of diminishing returns for the seed team and seek people early enough so they will be available and ready when they are needed. And of course people should be brought on gradually (see PHASING IT IN, DAY CARE (4.1.23), etc.) But start small, and stay as small as possible as long as possible. Large systems grow from small systems that work.

Second, remember that it is imperative to have FEW ROLES (5.1.2). With ten people, it is easy to define and fill half a dozen or so roles. But with a large initial team, people will at first be at a loss as to what to do, until they receive assignments (and you can’t give everyone an assignment all at once.) So they will find something to do, and will tend to invent roles for themselves. It’s a good way to create deadbeat roles.

Joe Walters said that a project shouldn’t grow larger than the size of the auditorium of the building where the project is centered. Staff sizing complete, the project can SIZE THE SCHEDULE (4.1.2).