Das Pair Programming Experiment

Vor ein paar Wochen habe ich mit meinem verteilten Team ein Pair Programming Experiment durchgeführt: 2 Entwickler auf 2 Standorten (einer in Graz, einer in Rumänien) haben vier Wochen lang ausschließlich mittels Pair Programming entwickelt – das heißt ca. 160 Stunden Remote Pair Programming!

Ausgangslage:

Mein verteiltes Team hatte sich über die letzten Monate gut weiterentwickelt und an Professionalität gewonnen. Pair Programming war jedoch bis dato noch keine etablierte Praxis im Team. Das wollte ich ändern, da es auch gute Gründe gab die Entwickler zu engerer Zusammenarbeit zu bewegen. Es wurde bis dato nämlich bevorzugt alleine an Tasks zu entwickelt und für meine Begriffe zu wenig kommuniziert. Bei einem unserer Kollegen in Rumänien (Marius) war die Kommunikations-Situation besonders schwierig. Zum einen hatte Marius an seinem Standort in Rumänien keinen lokal arbeitenden Teamkollegen mit dem er sich vor Ort austauschen konnte. Zum Anderen hatte er häufig mit Impediments zu kämpfen, von denen er das Team selten in Kenntnis setzte und stattdessen versuchte selbst Lösungen zu finden. Die folgenden Probleme galt es in dieser Situation zu lösen:

  • Marius war als Einzelkämpfer an einem externen Standort zu wenig in das Team eingebunden
  • Marius kommunizierte seinen Bedarf an Hilfe zu spät ans Team
  • Marius versuchte aufkommende Probleme (meist erfolglos) selbst zu lösen

Idee:

In einer Retro kam mir dann die Idee für das Pair Programming Experiment. Marius solle einen Sprint lang kosequent mit einem in Graz arbeitendem Senior Entwickler (Edwin) ausschließlich Pair Programming machen. Ich wollte damit erreichen, dass die Isolation von Marius beendet und die Kommunikation verbessert wurde. In Folge erhoffte ich mir einen wechselseitigen Wissensaustausch, rasche Lösung von Marius’ Problemen und in Folge eine Leistungssteigerung des Teams. Da Marius selbst merkte, dass er mehr Hilfe benötigte als er selbst anforderte war er mit der Idee einverstanden und auch Edwin fand den Versuch spannend.

Verlauf des Pair Programming Experiments:

Nach wenigen Tagen war bereits klar, dass das Pair Programming zwischen Marius und Edwin seinen Zweck erfüllte. So konnte Edwin in den ersten zwei Tagen eine Vielzahl an Verbesserungen von Marius’ Entwicklungsumgebung und Infrastruktur identifizieren und umsetzen. Es wurde auch viel Smalltalk geführt, was die soziale Isolation von Marius aufbrach und der Motivation zu Gute kam. Durch die enge Zusammenarbeit wurde laufend Wissen zwischen Edwin und Marius ausgetauscht, was einen enormen Lernfeffekt hatte. Am Ende des Sprints konnten wir ein erfreuliches Resümee ziehen: Alle waren sich einig, dass uns das Pair Programming als Team verbesserte. Daher beschlossen wir das Experiment für weitere 2 Wochen fortzusetzen, die unsere Erfahrungen aus den ersten beiden Wochen bestätigen sollten.

Retrospektive:

Nach Ende der 4 Wochen machte ich mit Marius und Edwin eine Retrospektive über das Experiment. Vor allem deren persönliche Befinden, die erzielten Lerneffekte und die Rollenverteilung wärend des Experiments waren für mich interessant zu erfahren.

Rollenverteilung:

Im klassischen Pair Programming wechseln sich die Pairing-Partner regelmässig in den Rollen des Navigators und Drivers ab. Wärend der Driver den Code schreibt, sitzt der Navigator daneben und denkt mit, ohne selbst Code zu schreiben. Edwin sollte Anfangs als der erfahrenere Entwickler vorwiegend Marius’ Arbeitsweise beobachten und ihm Hinweise für Verbesserungen geben. Dadurch war Edwin typischerweise häufiger in der Rolle des Navigators. Durch die Beobachtungen von Edwin konnten rasch Schwächen in der Arbeitsweise und am Environment von Marius identifiziert und behoben werden. Über die gesamte Dauer des Experiments zeigte sich, dass sich Marius mit der Analyse von Problemen etwas schwerer tat als Edwin – er erkannte häufig nicht die Wurzel der Probleme und betrieb damit häufig Symptombekämpfung. War jedoch einmal klar was zu tun ist, war Marius wiederrum sehr effizient beim Code umsetzen. Die persönlichen Stärken und Schwächen der beiden Entwickler haben sich durch das Pair Programming sehr gut ergänzt.

Lerneffekte:

Die folgenden Lerneffekte wurden von Marius und Edwin genannt:

  • Gegenseitige Verbesserung der Programmierskills, durch engen Austausch und Beobachtung der anderen Arbeitsweise
  • Marius’ Schwächen in der Analyse konnte durch Edwins Analyse-Stärken kompensiert werden
  • Environment Probleme von Marius konnten identifiziert und gefixt werden, da mit Edwin’s System ein Vergleichsystem verfügbar war
  • Vor allem bei komplexen Tasks zeigte sich Pair Programming für beide effizienter
  • Kommunikations-Barriere minimierte sich durch den dauerhaft offenen Kommunikationskanal zwischen Graz und Rumänien

Persönliches Empfinden:

Marius und Edwin nannten folgende Punkte zu ihrem persönlichen Empfinden wärend des Experiments:

  • Sozial hat die Zusammenarbeit zwiscehn den beiden sehr gut harmoniert
  • Pair Programming half einen hohen Fokus auf die Arbeit zu halten
  • Durch die gemeinsame produktive Arbeit blieb die Motivation dauerhaft hoch
  • Für Marius wurde soziale Nähe zum Team geschaffen (Privatgespräche, Smalltalk,…)
  • Für Marius war die Identifikation mit dem Team höher
  • Das Dauer-Pair-Programming war für beide anstregend aber überzeugend

Conclusio:

Mein Resümee aus dem Experiment ist, dass Pair Programming verteilt mit den richtigen Tools genauso effizient eingesetzt werden kann, wie für lokale Teams. Voraussetzung ist allerdings die Bereitschaft des Teams, konsequent die Praktik umzusetzen sowie die soziale Verträglichkeit der Pairing Partner. Ein akuter Anlassfall bietet immer eine gute Möglichkeit für eine Veränderung, wie die Einführung einer neuen Programmier-Praktik. Tituliert man eine Veränderung als Experiment oder Versuch, so ist der Widerstand des Teams meist geringer, da der Versuch noch keine Verbindlichkeit erzeugt. Implizites Wissen (z.B. Erfahrung), das nicht durch Schulungen transportiert werden kann, lässt sich hervorragend über Pair Programming vermitteln.

Advertisements

Published by

Stefan Wunder

My name is Stefan Wunder and I am a passionate Agile coach from Graz, Austria. I have been working in the software industry since 2006, being an agile practitioner since 2011. I have experience with pioneering Agile, transitioning teams from waterfall to Agile, as well as working with established high performance teams within scaled agile enterprises. I worked with co-located as well as with dispersed teams, in start-ups, medium sized companies and big global enterprises in various industries. Currently I am working as enterprise Agile coach at AVL List GmbH.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s