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.

Werbeanzeigen

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)

Eine Themenübersicht – Coding Dojo bis Pair Programming

Mit den hier gelisteten Artikeln möchte ich Euch einen Einstieg in die verschiedenen Methoden der Agilen (Software-) Entwicklung geben:

  1. Coding Dojo
  2. Agil, Pairing (XP), aber was steckt dahinter?
  3. Standard Prozesse

    Glossar:

    • XP: Extreme Programming
    • Pairing: Pair Programming, ist ein Teil von XP
    • Dojo, Kata: Übung
    • TDD: Ein Methodik, die den Test-First Ansatz verfolgt
    • DevOps: Development trifft auf Operations

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 talk about Pairing

Pair Programming – aber was versteht man darunter?
Pair Programming ist nichts anderes als ein dauerhaftes 4-Augen Prinzip – und das kennt jeder.

Bereits seit vielen Jahren werden die meisten sicherheitsrelevanten Aufgaben von mindestens zwei unterschiedliche Personen durchgeführt. Ein sehr aktuelles Beispiel ist das Team rund um ein Cockpit. Als effektive Maßnahme wird seit kurzem heftig darüber diskutiert aus den 4-Augen ein 6-Augen Prinzip zu machen – zumindest solange ein Augenpaar abgelenkt ist.

Aber zurück zur (Software-) Entwicklung und den agilen Prozessen. Im Folgenden ein paar grundlegende Punkte:

  1. Unbekannte Gewässer, etwas Neues wagen!
    • Wie steigert man die Bereitschaft im Team und/oder Unternehmen etwas „Neues“ zu testen oder gar einzuführen?
    • Lässt sich eine neue Methodik / Prozess / Arbeitsweise per Fingerschnippen einführen?
  2. Erforderliche Rahmenbedingungen
    • Ist ein gemeinsames Verständnis auf allen Ebenen vorhanden?
    • Welche bekannten Herausforderungen sind zu meistern?
    • Wie schaut der Vergleich zwischen Lehrbuch und Praxis aus?
    • Gibt es K.O. Kriterien?
    • Gefährliche Missverständnisse bzw. Schlussfolgerungen vermeiden
  3. Tägliche Hürden nehmen – in kleinen Schritte denken!
    • Welche Voraussetzungen können weiter verbessert werden?
    • Welche Vorbereitungen sind zu treffen?
    • Welche Fachliteratur eignet sich für den Einstieg?
    • Was ist bei der Zusammensetzung der Teams zu beachten?
  4. Die Unternehmenssicht (Wirtschaftlichkeit)
    • Wie lässt sich mit wenig Aufwand prüfen und belegen, welcher tatsächliche Mehrwert erzeugt wird?
    • Lohnt es sich tatsächlich, zwei Personen dauerhaft gemeinsam (im Paar) arbeiten zu lassen?
    • Welche Kosten entstehen aus Unternehmenssicht?
    • Welcher Nutzen entsteht – und wie lässt sich dieser messen?
    • Belegbare Zahlen im Vergleich – Zahlen, Daten, Fakten (ZDF)
    • Welche wissenschaftliche Arbeiten gibt es?

Fragen über Fragen – nur wo bekomme ich die ganzen Antworten her? Es gibt viel Literatur rund um das Thema Agile Methoden. Durch die Entwicklung der letzten Jahre und die Tendenz alles immer schneller fertigstellen zu müssen, haben sich einige wenige Methoden als nachhaltig erwiesen – dazu gehört für mich das Pair Programming.

Es dauert einfach seine Zeit, um sich mit einem Thema näher zu befassen. Denn neben reichlicher Literatur, vielen Tools und einigen „Masterplänen a la Lehrbuch“ auf der grünen Wiese, sind auch noch die jeweiligen spezifischen Projektbedingungen zu beachten. Meistens ist der erste Schritt der Schwerste.
Mein Ziel ist es, die selbst erlebten Erfahrungen kurz zu umreißen, an Euch weiterzugeben und damit Interessierte zu erreichen. Dies ist der Einstieg in eine Artikelserie, durch die ich sicherlich bei dem einen oder anderen etwas Licht ins Dunkle bringen kann.