Wenn ein Projekt durch den Ausfall einer einzigen Person zum Stillstand gebracht werden kann, spricht man vom Busfaktor 1. Weil sich im Laufe der Zeit die Leute immer mehr spezialisieren, geraten Projekte immer leichter in eine Situation, wo ein Einzelner zum Flaschenhals wird. Also gilt es, bewusst gegenzusteuern.

Beim Pair Programming arbeiten zwei Entwickler zusammen an einer Aufgabe, dabei sitzen sie beide an demselben Computer. Während einer direkt Code schreibt, behält der Partner das “Große Ganze” im Auge, hinterfragt Annahmen, erkennt offensichtliche Fehler usw. So stehen sie beide im ständigen Austausch über die Aufgabe, über mögliche Lösungswege und Konsequenzen. Das führt zu höherer Qualität, weil immer zwei Leute involviert sind, und weil sie ihre Überlegungen gegenüber einem Partner ausformulieren müssen

Da die Paare meistens täglich neu zusammengestellt werden, verbreitet sich das Wissen automatisch im Team. Sowohl das Wissen über die zu lösenden Aufgaben (“Fachlichkeit”), als auch die technischen Aspekte der Lösung.

Pair Programming ist nicht immer und überall umzusetzen, schließlich braucht es auf den ersten Blick die doppelte Kapazität (im best-case werden nur 15% statt 100% overhead berichtet). Dann gilt es, andere Gelegenheiten für die Verbreitung von Fähigkeiten und Kenntnissen zu schaffen.

So kann man etwa eine Aufgabe bewußt von einem weniger “passenden” Teammitglied bearbeiten lassen. Der “Experte” steht dann im Hintergrund zur Verfügung, falls es schwierig wird. Das ist, wenn Sie so wollen, eine Job Rotation im Kleinen, auf der Ebene einer einzelnen Aufgabe.

Egal ob Pair Programming oder Job Rotation, es ist erstmal etwas mühsam und dauert vielleicht ein bisschen länger. Sehen Sie es einfach als Risikomanagement und lohnenswerte Investition in den zukünftigen Durchsatz des Projektes.

Matthias Berth