Group closely related activities into roles
Individual activities are too small, and their sequencing relationships too dynamic, to be useful process building blocks. Group closely related activities into roles.
There are several other patterns that talk about roles, and re-organizing responsibilities among roles for better communications. This pattern talks about crystallizing roles out of groups of closely related activities, and the advantages of having roles. General rules of thumb are that roles are too big if there are few people that can do all activities that fall within the role; roles are too small if it is not clear which role to consult for information about a given topic. The granularity should allow an individual to take on more than one role, but individuals that take on many roles should require exceptional ability. Certain roles provide specific benefits to the project and are fairly self-contained, see MercenaryAnalyst, GateKeeper, ProductChampion, PatronRole. Others have more nebulous boundaries such as CustomerInterface, architect, and the extremely nebulous developer and designer roles.