1. Staffing and Team Organization

1.1 Brook’s Law

"Adding manpower to a late software project makes it later. – Fred Brooks, _The Mythical Man-Month, 1975

• Complex projects cannot be decomposed into subprojects that can be solved independently without communication.
• Essential versus accidental complexity
  • irreducible number of errors
• More personnel => more communications paths
  • n staff have \( \frac{n(n-1)}{2} \) potential communications paths.

Reducing Communications Costs

• Keep teams small, or
• Structure the communications paths

2. General Organizations

2.1 Hierarchical Team Organization

• One team per major subsystem
• Teams report to managers
• Managers report to one or more levels of higher managers

Dangers of Hierarchical Teams

• Distance between teams (where real work is done) and higher mgmt may hide problems.
• Level in hierarchy often equates with rank / rewards
  • Engineers either cannot rise in level or are forced to abandon their primary skills to be managers

2.2 Matrix Organization

• Staff are assigned specialized roles
  • e.g., architects, designers, analysts, testers
  • Team managers address general ability of team to perform role
• Subprojects identify required role players
  • Teams with commonly required roles move among multiple subprojects
  • Project managers oversees specific project

Dangers of Matrix Organization

• Restricted inter-role communication
• Management clashes

3. Software Team Organizations

3.1 Chief Programmer Teams

Mills (1970)

• Motivated in part by studies showing vast differences in productivity between different individuals within an organization
• Aims to allow the potentially most productive people to work unhindered

Organization of the Chief Programmer Team

• Chief programmer is team leader
  • responsible for design and critical parts of the implementation
• Assistant programmer assists chief and does rest of the implementation
• Librarian handles documentation, deployment, code management, etc.
• A few specialists can augment the team

Observations

• A very coding-centric view
• High stress on chief
• Low level of satisfaction for remainder of team
• Does not scale well to large projects.

3.2 SWAT Teams

SWAT == Skilled With Advanced Tools

A team organization for iterative process models

• Small team, sharing a common workspace
• Heavy tool support
• Team leader is “first among equals”

3.3 Agile Teams

• Small teams, often sharing a workspace
  • May work in pairs
    • Pairs self-assign but rotate frequently
• One team manager
• Team sets best practices
  • selects tools
• Emphasis on self-management, self-motivation
  • Professional pride

3.4 Distributed Teams

Common in open-source development

• Small core team responsible for project “vision”
• Associated developers submit patches, changes, etc.
  • Must be approved by core team to be merged into official project
  • A pull requests is a request for others to check out a proposed change.
• Users submit bug reports and feature requests
  • May be prioritized by core team.
  • But an associated developer is not prohibited from working on a low-priority request.

Total team can be huge and diverse.