see also
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?CaseTeam and 
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?HolisticDiversity
-----
'''HolisticDiversity'''

'''Thumbnail: ''' Development of a subsystem needs many skills, but people specialize, so.. Create a single team from multiple specialties. 

'''Indications: '''
Complaints that "we are doing 'throw it over the wall'" development.  Complaints of a bureaucratic process. Inter-team communication breaking down. Teams are structured by specialty or phase deliverables. People pass work to each other by written, required deliverables instead of visiting each other. Teams are structured by specialty or by phase deliverables. Teams are not able to get their discoveries incorporated into connecting teams' work patterns. Lack of respect of one team for another. Overgeneralization: each person is assigned to do everything, resulting in waste from changing mental gears. 

'''Forces being balanced: '''
You want fast feedback, with fast, rich communications, on decisions. You want to be able to hire people with the skill sets you specify. ... ''Factors affecting the balancing of the forces: '' ...
Feedback is fastest and within one person's head, then slows with distance (room / floor / building/ city) and medium of expression (interactive spoken face-to-face / video / written). Multiple skills are needed to develop a piece of the system, particularly the user functions; it is hard to hire people with those multiple specialties. People specialize. People protect their specialties against other specialties. People within a team are more likely to help each other. 
People in different teams blame each other. You cannot always put the entire team in one room. Everyone "designs" in some way. 

'''Recommended action: '''
For each function or set of functions to be delivered, create a small team (2-5 people) which is responsible for delivering that function. That team can be given or can evolve specialists in requirements gathering, user interface design, technical design and programming, databases and testing. Evaluate the team as a single unit, so there is no benefit to hiding within a specialty. Arrange the team size and location so they can communicate directly with each other, instead of by writing. They have no internal documentation requirements, although they do have documentation requirements responsibility to the rest of the project. However they choose to split up their work is their choice. 

'''Resulting context: '''
You will have to coordinate the teams to get consistency of deliverables (requirements document, user interface design, software architecture, etc.) across teams. 

'''Overdose effect: '''
If the team size is one person, that person will have difficulty mastering all the specialties, and changing mental context to perform well in the different specialties (meetings take quite a different temperament and more concentration than designing OO frameworks). 
If the team size is large, the communications will lag. 

'''Related patterns: '''
OwnerPerDeliverable ensures that somebody owns each function, class, and required deliverable. CaseTeams.
NeilHarrison (Harrison 95) wrote DiversityOfMembership to ensure that requirements gathering teams include users. 
Jim Mc''''''Carthy (Mc''''''Carthy 95) wrote FeatureTeams as a best practice, with much the same intent.