XP, Pair Programming – Additional Benefits vs. costs

Voraussetzungen:
Das Team muss harmonieren. Nur wenn die zwischenmenschliche Beziehung passt, sind die Grundvoraussetzungen erfüllt!

Zeit für die Einarbeitung – kalkulierbar?
Als allgemeingültig werden rund 3 bis 6 Monate an Einarbeitung in ein neues Projekt angesehen. Die tatsächliche Zahl ist natürlich abhängig von der Komplexität, den Vorkenntnissen und der Rolle, die es zu übernehmen gilt.
Es gilt: Je höher die Komplexität, desto höher die erforderliche Zeit. Je größer die Vorkenntnisse sind, desto schneller beginnt der produktive Einsatz.

Meine persönliche Empfehlung:
Gebt dem Pair rund zwei Wochen Zeit, sich aufeinander einzustellen.
Eine Vorhersage, wie lange es pro Team tatsächlich dauert, lässt sich nicht verallgemeinern. Bei dem einen Paar klappt das ab dem dritten Tag, bei einem Zweiten erst nach 10. Gebt den Teams genug Freiraum und die Möglichkeit zur Klärung der optimalen Arbeitsweise/- umgebung – vor allem bei einer Junior – Senior Konstellation. Auch ein Senior lernt nie aus.

Kleines Beispiel:
Lässt man alle anderen Faktoren weg und betrachtet ausschließlich die benötigte Zeit (netto) um eine zweite Person einzuarbeiten, kommt man – meiner persönlichen Einschätzung nach – mit rund 1/3 der durchschnittlichen Zeit für eine Einarbeitung aus. Das bedeutet für ein Unternehmen, dass beide Personen schneller produktiv eingesetzt werden können. Der Coach kann seinen eigentlichen Tätigkeiten nachkommen und die neue Person im Team wird von Anfang an stärker eingebunden, z.B. in das Tagesgeschäft. 

Weitere Faktoren:
Urlaub, Termine, Unterstützung von Kollegen verändern die Zeit (netto) natürlich, was zwangsläufig zu einem längeren Zeitraum führt.

Gefahren und Missverständnisse
Es muss immer beachtet werden, dass Pair Programming kein Allheilmittel darstellt. Auch diese Methode muss von Fall zu Fall geprüft werden, ob es dem Projekt oder dem Team den gewünschten Nutzen bringt.

Fazit:
Gehen wir aktuell von rund 2/3 der Zeit aus, die im klassischen Sinne benötigt wird, dann lassen sich immerhin bis zu 33% Arbeitszeit und somit Kosten für die Einarbeitung einsparen. Was das für ein Unternehmen in Zahlen bedeutet, lässt sich aus dieser Annahme leicht ableiten.

XP, Pair Programming – Necessary business conditions (part two)

Dieser Artikel ergänzt die weiteren erforderlichen Rahmenbedingungen. Im ersten Teil ging es um ein gemeinsames Verständnis und den Nutzen eines aktiven Vorlebens. Dieser Artikel hingegen befasst sich mit den größten Herausforderungen und Hürden, die – meiner Meinung nach – zu vermeidbaren Missverständnissen führen können. Und diese kosten nicht nur Zeit, sondern stellen auch ein Risiko dar, das nicht unterschätzt werden darf.

Missverständnisse jeglicher Art sollten natürlich vermieden werden. Das klappt aber nur, wenn der Kunde und der Auftragnehmer das gleiche Verständnis für den Umfang und Inhalt der Aufgabe haben. Solche Hürden entstehen aber meistens dann, wenn eine Aufgabe oder Anforderung nicht präzise genug formuliert ist und somit Interpretationsspielraum zulässt. Damit sind den täglichen Herausforderungen Tür und Tor geöffnet, die dann meistens mehrfach vorkommen.

K.O. Kriterien, wie lassen sich solche Probleme vermeiden?
Ganz klare Antwort: offene Kommunikation im Team.
Dazu gehören akute Probleme, Herausforderungen und Hindernisse, die beseitigt werden müssen. Jedes Teammitglied sollte idealerweise einen guten Überblick über den aktuellen Stand haben, damit bei Planänderungen durch Urlaub oder Krankheit, zeitnah agiert werden kann. Es muss nicht jeder alles wissen, aber durch regelmäßige Absprachen und Informationsaustausch lassen sich zum Beispiel Aufwände bei unvorhergesehenen Vertretungen reduzieren.

Wie erreicht man im Team diese Offenheit?
Hier bieten sich regelmäßige Termine an, um die größten Herausforderungen transparent zu machen. Durch kleinere Workshops, sog. „Lessions learnt“, lassen sich Lösungswege viel schneller erarbeiten. Ein kurzes Branstorming, eine Zeichnung oder Skizzen auf dem Whiteboard eignen sich ebenfalls bestens, um ein breiteres Verständnis und Klarheit zu schaffen. Das WIR als Team muss hier an erster Stelle stehen!
Idealerweise lassen sich aus den Ergebnissen wiederum konkrete Maßnahmen ableiten, die ggf. weiter verfeinert, eingeplant und umgesetzt werden können. Nicht alles lässt sich sofort umsetzen, aber wenn eine Aufgabe erstmal benannt ist, im Team erklärt wurde, kann diese auch besser beurteilt, eingeschätzt und geplant werden.

Deswegen an dieser Stelle meine klare Empfehlung:
Sprecht die Punkte offen an, die Euch am meisten stören – sachlich, objektiv und mit Fakten hinterlegt.

Eine Buchempfehlung (neue Perspektiven und Sichtweisen)

XP, Pair Programming – Necessary business conditions (part one)

Als nächstes widme ich mich den erforderlichen Rahmenbedingungen. Die hier aufgezeigten Punkte sind Schlussfolgerungen aus meinen persönlichen Erfahrungen und stellen natürlich kein Allheilmittel dar. Trotzdem bleibt jeder der folgenden Punkte – meiner Meinung nach – zwingend erforderlich und sollte nicht ohne wichtigen Grund über Bord geworfen werden. Was als wichtiger Grund zu verstehen ist, muss jedes Team innerhalb eines Unternehmen projektabhängig für sich selbst entscheiden.
„It depends.“

Gemeinsames Verständnis:
Zu den zentralsten Rahmenbedingungen zähle ich in einem Projekt das gemeinsame Verständnis. Nur wenn jedes Teammitglied inkl. Projektleitung, Management und Kunde von ein und demselben Aspekt, Punk bzw. Aufgabe sprechen, kann das gesamte Team als Einheit gemeinsam an einem Strang ziehen. Ansonsten entstehen ungewollte Wechselwirkungen, die sehr schnell zu Missverständnissen führen können. Diese gilt es dann zeitnah aus dem Weg zu räumen, um unnötige Termine zur Klärung zu vermeiden. Aber auch hier gilt: Es gibt keine falschen Fragen!

Bekannte Herausforderungen erkennen und meistern:
Darunter verstehe ich die Erzählungen. Projektbeschreibungen oder Anekdoten, die einem auf Konferenzen oder Fortbildungen wie User Group Treffen zugetragen werden. Zusätzlich helfen hier die selbst erlebten Erfahrungswerte, um aus ihnen zu lernen. Projektinhalte lassen sich nicht 1:1 vergleichen, aber die Prozesse zur Durchführung sind doch meistens sehr ähnlich aufgebaut.

Vergleich zwischen Theorie und Praxis – Zwei völlig unterschiedliche Welten?
Das Lehrbuch verspricht uns die schöne grüne Wiese.  Dort finden wir viele gute Empfehlungen und Vorschläge rund um den Einsatz von Agilen Methoden – sei es SCRUM, XP, Kanban o.ä.  Die Praxis schaut hier meistens etwas anderes aus. Die täglichen Herausforderungen bestehen darin, dass einem immer genau die Situationen über den Weg laufen, die nicht im Buche stehen. Wichtig ist aus meiner Sicht zu lernen, was beide Welten miteinander verbindet, um daraus einen Mehrwert für das aktuelle Projekt, sein Team und natürlich die Firma zu generieren.

Mein erstes Fazit: Und täglich grüßt das Murmeltier – oder wie war das gleich nochmal? Aber im Ernst – mit dem gemeinsamen Verständnis als Fundament lässt sich viel effizienter ein tragendes Gerüst zur Überwindung von Vorbehalten bauen. Aktives Vorleben und gemeinsames Erleben sind für mich von größter Bedeutung. Aha Effekte erzeugen, Lernen und lernen lassen nehmen einen ähnlich großen Stellenwert ein. Auch hier gilt der Klassiker – Übung macht den Meister – egal ob bei Naturwissenschaften oder Sprachen.

Literaturempfehlung:

Coding Dojo – Let`s do it

Was ein Dojo ist und was bei den ersten Schritten zu beachten ist, habe ich bereits hier beschrieben.

Wenn sich die Gruppe auf die grundlegenden Sachen geeinigt hat, kann es auch schon losgehen. Der erste Schritt ist hier meistens der Schwerste – wie fängt man denn am besten an?
Ein kleiner Tipp: Lest Euch die Aufgabenstellung erneut durch und zerschneidet sie in kleinste Teile mit dem Ziel pro Aufgabe mehrere Tests zu erstellen.

Nehmen wir beispielsweise das Kata FizzBuzz – hier geht es darum eine Zahlenreihe von 1 bis 100 auszugeben.
Bei jeder Zahl, die durch drei teilbar ist, soll Fizz ausgegeben werden. Bei jeder Zahl, die durch fünf teilbar ist, soll Buzz ausgegeben werden. Und wenn die Zahl durch drei und fünf teilbar ist, soll FizzBuzz ausgegeben werden.

Wie sieht dann der erste Test aus? Ganz klar. Nimm die erste Ziffer, die Du prüfen willst, und stelle fest, ob eine der Regeln angewendet werden kann. Danach nimm die zweite Ziffer, usw. Sobald sich die Kombination aus mehreren Regeln ergibt, wird es interessant, da hier auch die Reihenfolge relevant sein kann. Ganz wichtig bei den ersten Schritten – geht streng nach dem Test Driven Prinzip mit Red – Green – Blue vor. Ob ihr lieber Design oder Development nutzt, ist Euch überlassen
Red, d.h. Euer Test muss fehlschlagen.
Green, d.h. Euer Test hat funktioniert.
Blue, d.h. Refactoring – Zeit, um den geschriebenen Code zu verbessern.

Danach geht es mit dem nächsten Test (Red) weiter. Nehmt Euch die Zeit und probiert es aus.