Black Belts Train White Belts

Long-lived software development teams often tend to develop a static "core" and a dynamic "periphery". The core developers stay with the project, but the periphery changes: developers are "borrowed" from other projects, short-term contractors are hired in as needed, and new hires are added. Core developers know the project and have internalized it; new periphery developers need time to come up to speed on the lingo, culture, and environment of the project.

But, core developers have a tendency to cluster. Core developers need other core developers as sounding boards, because experience with a system helps a developer determine the feasibility of changes or new ideas without going back to the design or the code. If core developers cluster too exclusively, their productivity is enhanced at the expense of the periphery developers, who may tend to "thrash" without a solid feel for the system.

Therefore, pair core developers with the newest periphery developers. In the short term, the core developers will take a productivity hit, but the periphery developers will come up to speed faster, and the overall team productivity will increase more rapidly. Additionally, the core developers can gain insight from periphery developers' difficulties, and avoid getting into a design rut.

This pattern was inspired by a common practice in some Aikido dojo. Most Aikido schools make a stronger distinction between yudansha (students who have achieved BlackBelt? rank or above) and mudansha (those who have not). Many dojo have a rule that WhiteBelt?s (the lowest of the mudansha ranks) must train with yudansha, rather than other mudansha of any level. The WhiteBelt?s don't get an opportunity to learn bad habits from other juniors, and the yudansha are forced out of the rut they can get into when they're at the stage of continual refinement, rather than raw learning.

Note the distinction between "core/periphery" and "senior/junior". Both junior and senior developers benefit from being paired with a senior developer who knows the project and its history cold.

"Pairing" doesn't necessarily refer to PairProgramming, although if you PairPromiscuously, you get BlackBeltsTrainWhiteBelts as a side effect.

Pairing in non-ExtremeProgramming environments can range from simply telling the periphery developer, "if you need a hand ask $(CoreDeveloper)", to physically locating people's desks near each other, especially in TwoPersonOffice?s.

In fact, many Aikido dojo - at least in Europe - don't distinguish mudansha at all with colored belts (like done e.g. in Judo). This has the effect, that there is not only one teacher but many of them. Transferred to software development, this could mean: don't use one explicit coach, but create a collaborative atmosphere, where everyone is everyone's coach.

(I'm learning Aikido since 28 years, and find myself pretty often learning from WhiteBelt?s - and the same happens from time to time in software development, where I'm looking back to only 18 years of practice, when I'm finding myself learning from people in a class I'm giving from time to time...)

-- ChristianMann

CategoryPattern