Pair Programming Compatibility

Vor einiger Zeit habe ich über einige nachteilige Effekte beim Pair Programming geschrieben. Dabei habe ich verschiedene Symptome, Personas und Verbesserungsmöglichkeiten vorgestellt.
Trotzdem hat mich Pair Programming weiterhin beschäftigt. Ich bin das Gefühl nicht losgeworden, noch nicht genug über diese Form der Zusammenarbeit gelernt zu haben. Also habe ich wieder viele Pairs beobachtet und meine Beobachtungen mit Kollegen und Freunden diskutiert. Ich habe versucht echte Indikatoren für erfolgreiche oder problematische Pair Programming Konstellationen zu finden. Im Laufe des Jahres sind mir einige zusammenhängende Faktoren und Muster immer wieder aufgefallen, die ich im folgenden beschreiben möchte. Das hier ist das Pair Programming Compatibility-Modell.

Manchmal läuft Pair Programming richtig gut und manchmal klappt es überhaupt nicht. Das eine Mal ist es sehr hilfreich zu zweit zu arbeiten und man ist richtig produktiv. Ein anderes Mal ist es ganz anders und sehr anstrengend. Jeder, der öfters im Pair arbeitet, kennt das. Doch warum kommt uns Pair Programming in manchen Situationen effektiver vor als in anderen?
Meines Erachtens kann das auf drei Aspekte reduziert werden, die ich im folgenden Schaubild als Dimensionen dargestellt habe: Leicht-Schwer, Homogen-Heterogen, Monoton-Kreativ. Nach meiner Erfahrung ist Pair Programming sehr effektiv, wenn sich Aufgabe, Team und Vorgehen jeweils in der Mitte dieser Spektren, also in Balance, befinden (grüne Zonen). Sobald sich eine Dimension einem Extrempunkt annähert, merken die Beteiligten recht schnell, dass etwas nicht ganz stimmig ist und Pair Programming irgendwie nicht funktioniert (rote Zonen). Natürlich kann man dann auch Pair Programming machen, aber meiner Meinung nach überwiegen dann die negativen Effekte, die dem Unternehmen schaden.

Die erste Dimension bezieht sich auf die Aufgabe oder Anforderung. Ist diese sehr leicht, könnte ein einzelner Entwickler die Aufgabe wegen geringer Fehleranfälligkeit genauso gut aber wesentlich schneller lösen. Ist die Aufgabe auf der anderen Seite sehr schwer, ist erhöhte Konzentration und Ruhe nötig, die Entwickler meistens nur alleine finden.

Die zweite Dimension bezieht sich auf das Team, also die zwei Entwickler, die zusammen Pair Programming machen. In einem sehr homogenen Team bleiben hilfreiche Ideen und Impulse eines Andersdenkenden aus und soziales Faulenzen entsteht. In einem sehr heterogenen Team besteht viel Erklärungsbedarf und es entstehen viele Diskussionen, die Zeit und Energie kosten.

Die dritte Dimension bezieht sich auf die Umsetzung der Aufgabe durch das Team. Wenn es sich dabei um eine sehr monotone Tätigkeit handelt, gibt es wenig Potential für Verbesserung. Die Tätigkeit kann dann schneller alleine realisiert werden. Wird auf der anderen Seite sehr kreativ gearbeitet, müssen oft viele verschiedene Dinge überlegt, recherchiert und ausprobiert werden, was zu zweit eher hinderlich ist.

Wenn Aufgabe, Team und Vorgehen sich um die Mittelpunkte der erwähnten Aspekte bewegen, ist Pair Programming meiner Meinung nach optimal geeignet. Im oberen Schaubild wäre das die Überlagerung der grünen Zonen, die im dreidimensionalen Raum eine Kugel bilden. In diesem Bereich wollen wir arbeiten. Wenn die Aufgabe aber sehr einfach, das Team sehr homogen und das Vorgehen sehr monoton ist, ist Pair Programming meines Erachtens Verschwendung von Entwicklungsenergie. Willkommen in der Zone der Verschwendung.
Wenn die Aufgabe sehr schwer, das Team sehr heterogen und das Vorgehen sehr kreativ ist, dann ist Pair Programming nach meiner Erfahrung hinderlich, störend und bremst Lösungsfindungen zu stark aus. Willkommen in der Zone der gegenseitigen Behinderung.

Man rechnet ja gerne mit der doppelten Bearbeitungszeit im Worst Case, wenn man eine Aufgabe zu zweit bearbeitet. In der Zone der Verschwendung ist das auch so. In der Zone der gegenseitigen Behinderung kommt zu der doppelten Zeit durch zwei Bearbeiter noch der Effekt dazu, dass die Arbeit durch gegenseitige Behinderung ja auch noch langsamer erfolgt. Und wenn die Bearbeitung dann nur noch halb so schnell erfolgt, dann dauert sie doppelt so lange. Es wird also im Durchschnitt die vierfache Zeit gebraucht. Die Implementierung wird aber nur marginal besser. Das danach eine vergleichbare Aufgabe bearbeitet werden muss, die auch parallel hätte bearbeitet werden können, verdoppelt die Durchlaufzeit nochmal.

Nachteile vs. Vorteile

Es gibt natürlich viele Gründe, warum man Pair Programming macht. Mehr Qualität, man lernt dazu, man fühlt sich nicht so einsam bei der Arbeit oder weiß nicht an was man arbeiten soll. Alle diese Gründe sind gut und wichtig, aber nicht alle sind in einem professionellen Umfeld auch angemessen. Um das Ziel, das hinter diesen Gründen steht, zu erreichen, müssen bestimmte Voraussetzungen erfüllt sein. Qualität ist wichtig, aber nach meiner Erfahrung arbeitet nicht jedes Pair qualitativer. Nur Pairs, die sich gegenseitig ergänzen und ersetzen können, also nicht zu homogen und nicht zu heterogen sind, erreichen gemeinsam mehr. Zu ungleiche oder zu gleiche Pairs erreichen sogar eher das Gegenteil. Genau wie die Leistungsfähigkeit nimmt auch die Konzentrationsbereitschaft im Team durch Social Loafing ab, sodass komplizierte Aufgaben nicht geeignet umgesetzt werden können. Lernen ist auch sehr wichtig und wenn es nur um Know-How-Transfer gehen würde, wäre das auch kein Problem. Aber es geht ja noch um viel mehr: Guten Code, Inhalte, Funktionen und Termine einhalten. Know-How-Transfer durch Pair Programming ist möglich aber nach meiner Erfahrung ineffizient und uneffektiv. Es gibt didaktisch sinnvollere Methoden um zu lernen, wie beispielsweise Coding Dojos und Supervised Learning. Wenn man dennoch mit Pair Programming lernen will, müsste man konsequenterweise Themen-spezifisch pairen: Für Domänen-Know-How mit Domänen-Experten, für Architektur-Know-How Pairing mit den Architekten und für Coding-Know-How mit den Entwicklern. Je ungleicher die Wissensstände der Personen sind, desto mehr lernt die Person beim Pair Programming auf Kosten der anderen Vorteile von Pair Programming, was die Umsetzung hindert und in der Regel zu schlechteren Lösungen und längerer Bearbeitung führt.

Die negativen Effekte von Pair Programming in den roten Zonen, wie beispielsweise wenig Konzentration, anstrengende Diskussionen, soziales Faulenzen und vierfache Bearbeitungszeiten, sind nicht zu unterschätzen. Deswegen müssen wir lernen zu erkennen, ob wir uns gerade in der Zone der Verschwendung oder in der Zone der gegenseitigen Behinderung befinden. Wenn wir uns in einer dieser roten Zonen wiederfinden, ist es unsere Verantwortung als professionelle Entwickler gegenzusteuern und Pair Programming vielleicht sogar abzubrechen. Weiterhin ist es eine große Gefahr, sich an Pair Programming zu gewöhnen, da uns die beschriebenen Zonen nicht mehr auffallen oder, noch schlimmer, egal werden. Abhängig von Aufgabe, Team und Vorgehen macht manchmal Pair Programming und manchmal alleine arbeiten Sinn. Wenn wir dann zu zweit arbeiten hilft uns das Wissen über die Zonen des Pair Programming Compatibility-Modells um Effizienz- und Effektivitätsverluste rechtzeitig zu erkennen und auszugleichen.

 

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

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

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s