Domain Expertise in Roles

Problem: Matching staff (actors, people) to roles.

Context:

You know the key atomic process roles, including a characterization of the Developer role.

Forces:

All roles must be staffed.

All roles must be staffed with qualified individuals.

Spreading expertise across roles complicates communication patterns.

Successful projects tend to be staffed with people who have already worked on successful projects.

Solution:

Hire domain experts with proven track records. Any given actor may fill several roles. In many cases, multiple actors can fill a given role. Domain training is more important than process training. Local gurus are good, in all areas from application expertise to expertise in methods and language.

Resulting Context:

This is a tool that helps assure that roles can be successfully carried out. It also helps make roles autonomous.

Other roles (Architect, Mercenary Analyst, and others) are prescribed by subsequent patterns.

Design Rationale:

Highly productive projects (e.g., QPW) hire deeply specialized experts.

[Alexander 40] ``Old People Everywhere,'' talks about the need of the young to interact with the old. The same deep rationale and many of the same forces of Alexander's pattern also apply here.

The pattern Apprentice helps maintain this pattern in the long term.

A seasoned manager writes, "The most poorly staffed roles are System Engineering and System Test. We hire rookies and make them System Engineers. (In Japan, only the most experienced person interacts with customers.) We staff System Test with `leftovers'; after we have staffed the important jobs of architecture, design, and developer."

Next: Phasing it In