Even the manager pulls his weight in this small team cooking up some new concoction.
...during the course of a project, groups of people begin to specialize. Teams are structured by specialty or by phase deliverables. This leads to bureaucratic processes, lack of inter-team communication, and a "throw it over the wall" style of development. As a result, teams don't trust each other, and product quality and efficiency suffer.
✥ ✥ ✥
Development of a subsystem needs many skills, but people specialize.
Project development demands fast feedback, with fast, rich communications, on decisions. 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 find people with those multiple specialties. In addition, people tend to specialize, and even protect their own unique skills against others; it's a natural self-preservation mechanism. This leads to teams that tend to specialize.
So a project requires multiple skills, that tend to reside in separate teams. But this is not optimal. People within a team are more likely to help each other. People in different teams blame each other. Communication across teams tends to be inefficient and incomplete.
The obvious approach is to create one giant team for the project; this should solve the problem, right? But if the team is too large to put in one room, it tends to fragment naturally — along lines of specialization.
Therefore:
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. The team has 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.
Note that this leads to organizing teams along architectural lines, namely ConwaysLaw. This means that it is necessary to coordinate the teams to get consistency of deliverables (requirements document, user interface design, software architecture, etc.) across teams.
Beware of making teams too small. 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). (See SoloVirtuoso) On the other hand, if the team size is large, the communications will lag.
See also OwnerPerDeliverable, that ensures that somebody owns each function, class, and required deliverable.
This is similar to DiversityOfMembership [BibRef-Harrison1996], to ensure that requirements gathering teams include users.
Jim McCarthy [BibRef-McCarthy1995] wrote Feature Teams as a best practice, with much the same intent.
✥ ✥ ✥
Try to create one person with several bodies. It is hard to find single individuals who can master the needed specialties and change work contexts as needed. Creating a small, co-located, mixed-specialty team with no written deliverables between them increases the communication bandwidth between people, while letting the individuals develop their strengths. Rewarding them as a team keeps them motivated to help each other deliver, rather than hide behind their specialty.
There is a tight connection between the specialties. A designer or programmer may discover something that reveals that the requirements are more difficult that thought. The analyst may have a flawed view of the business. The final code must be a valid business model. The suggested user interface may be impractical to implement, or perhaps the user interface designer knows best how to implement it. Putting the people on the same team speeds the feedback from programming back up the chain to requirements. Separating those same people and putting written deliverables between them slows that feedback.
Alistair Cockburn tells of experiences with a project:
Project Winifred was initially structured by function, which produced the trouble that many people were altering one class at any moment in time (see Function / Component Owners).
It was next structured by phase deliverables, requirements/analysts separated from designers and programmers. The analysts produced ineffective models, communications between the people became sluggish, the analysts and programmers looked down on each other, and the analysts' designs did not match the final system design (the programmers ended up designing it as they needed to make it work).
There was a very brief period of "everyone does everything". It did not last long because the mental load was too great on each person trying to do everything, and people rapidly fell into the specialties they could handle.
The fourth, and successful arrangement, was HolisticDiversity. Those who could do the requirements gathering and analysis went to meetings, interviewed people, and investigated interfaces and options. They communicated the results rapidly, face-to-face, with the people who navigated the class library and designed classes and frameworks. A function team consisted of a combined requirements gatherer / analyst with two to four programmer designers.
The team used JustDoIt to move rapidly through the design. They had no internal deliverables, but created the deliverables as required by the project for interteam communication and maintenance. Most of the communication within the team was verbal. They talked several times a day, either in one-hour mutual-education sessions, or in small, several minute interchanges to mention a recent discovery. This amount of communication could not have been handled through formal deliverables.
See also DiverseGroups.
This pattern was originally written by Alistair Cockburn [BibRef-Cockburn1996].