Description

Roles

Attributes

Steps

1. Decide Organizational Structure:
   
   Work groups can be organized around one of two basic philosophies: customer requirements (deliverable value), or architectural components (layers). Both organizations make sense under appropriate circumstances.
   
   Choose to organize around deliverable value and customer requirements when a domain has a high degree of uncertainty particularly in the target market and the go-to-market strategy, or when a domain is suffering from discontinuous innovation which is rapidly changing the go-to-market strategy for the business. A good example of this would be the arrival of the low cost, point-to-point carriers in the air travel business. These new airlines introduced great uncertainty into the business models of the incumbent traditional airlines. Also choose this organizational strategy when a team is immature in terms of architecture, analysis and design discipline, or inter-team communication.
   
   Choose to organize around architectural components or layers in a more mature organization where there is a strong culture of good architecture, analysis and modeling, and when it is possible to engage stakeholders in building a model of the domain and the go-to-market strategy or business rules. Organizing teams around the architecture, generally leads to a more cohesive set of components, with more loosely coupled interfaces. This leads to longevity of the architecture over time and minimizes the need for large regressions due to architectural refactoring. This is a strategy for larger projects, with longer life spans executed by more mature and experienced teams.
2. Allocate Personnel to Teams:
   
   Allocate members to teams based on balancing skills and resources required against the skills and resources required by the team's responsibilities to develop a set of valuable customer requirements, or to develop a particular component or layer of the architecture. For example, a team building the persistence layer would need a database administrator or data modeler. It would not be wise to assign such an individual to the user interface layer team.

Predecessors

Type	Name	Dependency Type
	Plan Iteration Resources	Finish-Start
	Plan Knowledge and Skills	Finish-Start

Successors

Type	Name	Dependency Type
	Define Iteration Roles and Responsibilities	Finish-Start