Wer kennt es nicht?

Ich arbeite im TEAM (Toll, ein Anderer macht’s)!

Warum sollte man zwei oder mehrere Leute auf ein einzelnes Problem packen, wenn diese Leute auch alle jeweils ein Problem für sich lösen könnten?
Und wie soll man sich überhaupt konzentrieren können, wenn einem permanent jemand über die Schulter schaut?
Hier decken sich meine persönlichen Erfahrungen mit den Studien zu dem Thema.

Der Skeptiker

Ich erinnere mich noch gut an den Tag, an dem ich zum ersten Mal von Pair-Programming gehört habe.
Zu der Zeit war ich noch ein Junior-Entwickler und ich saß in einem komfortablen Zweierbüro, zusammen mit meinem damaligen Mentor. Der hatte gerade einen Artikel gelesen, in dem Pair-Programming erwähnt wurde.
Er machte sich darüber lustig und sagte: „Kennst du Pair-Programming?“
Ich verneinte.
„Da setzt sich der eine Entwickler bei dem anderen auf den Schoß und der eine benutzt die Maus, der andere die Tastatur“, lachte er.
Damit war das Thema dort erst einmal gegessen.

Der erste Kontakt

Erst Jahre später kam ich bei meinem nächsten Arbeitgeber wieder mit dem Begriff in Berührung.
Ich war in einer Position, in der ich eigentlich einen überforderten Entwickler unterstützen sollte, der aber kurz vor meinem Arbeitsantritt bereits das Handtuch geworfen hatte.
Zwar hatte ich mich gut eingearbeitet, aber es gab einfach zu viel zu tun und ich brauchte nun selbst Unterstützung. Nach längerer Suche bekam ich tatsächlich sogar einen Kollegen mit mehr Erfahrung als ich, der ganz selbstverständlich sagte, dass er die Einarbeitung im Pair machen wollte.
Ich sagte ihm wahrheitsgemäß, dass ich das noch nie gemacht hatte, aber das war kein Problem für ihn. Er hatte bereits sehr gute Erfahrungen bei einem ehemaligen Arbeitgeber sammeln können.

Kein leichter Start

Offen gestanden empfand ich den Anfang zuerst eher als anstrengend.
Ich war daran gewöhnt größtenteils komplett eigenständig zu arbeiten und wurde schnell nervös, wenn mir jemand bei der Arbeit über die Schulter guckte.
Natürlich habe ich mich auch schon mal mit einem oder manchmal auch mehreren Kollegen zusammengesetzt, um sich ein Problem gemeinsam anzuschauen, aber das war eher die Ausnahme als die Regel.
Nun hatte ich plötzlich jemanden neben mir sitzen, der immer wieder Fragen stellte, warum ich das so machte, wie ich es tat.

Das war erst einmal nervig und so haben sich einige Fragen zuerst angefühlt wie persönliche Angriffe.
Natürlich war keine davon so gemeint, aber wenn man zu viel für sich alleine gearbeitet hat, dann fällt man leicht in diese Falle.
Allerdings habe ich auch schnell gemerkt, wie viele Fortschritte wir plötzlich machten.
Während ich meinem neuen Kollegen das bestehende System erklärte, lernte ich gleichzeitig diverse Konzepte von ihm.
Besonders interessant fand ich dabei, wie sehr es dem eigenen Verständnis hilft, wenn man etwas jemand anderem erklärt.

Erklären, um zu verstehen

Tatsächlich ist das eine Methode, welche ich bereits seit Langem für mich selbst nutze.
Wenn ich spazieren gehe, Sport mache, mich um den Haushalt kümmere oder während sonstiger Tätigkeiten, bei denen ich nicht viel nachdenken muss, erkläre ich mir in inneren Dialogen gerne Dinge selbst. Ich weiß nicht, seit wann ich das tue oder wie ich darauf gekommen bin.
Das ist einfach etwas, was ich schon sehr lange tue, und es hilft mir dabei, mein Verständnis von bestimmten Konzepten zu vertiefen.
Beim Pair-Programming gehört das Erklären einfach als essenzieller Bestandteil dazu.
Und natürlich ist es deutlich effektiver, wenn man einen echten Gesprächspartner hat, der idealerweise auch Rückfragen stellt oder – noch besser – Einwände und Gegenargumente einbringt.
Wenn man für sich selbst arbeitet, dann passiert es schnell, dass man etwas tut, ohne groß darüber nachzudenken.
Aber durch die Regel des Erklärens des eigenen Gedankengangs lernt man recht schnell, dass man über das Problem erst einmal laut nachdenkt, bevor man voranprescht.
Gleichzeitig bekommt man direktes Feedback, insbesondere wenn man etwas vergessen hat oder der Partner eine alternative Idee hat.

Diskussionskultur

Selbstverständlich waren wir uns auch nicht bei allem einig. Ganz im Gegenteil sogar.
Ich war (und bin weiterhin) ein großer Befürworter von KISS, während der Kollege mit Clean Code, SOLID und DDD um die Ecke kam.
Grundsätzlich nichts was sich widersprechen sollte, aber wir waren beide jeweils zu dogmatisch unterwegs.
Er sah meinen Code als Spaghetticode und ich seinen Code als overengineered.
Bei uns sind also sehr unterschiedliche Perspektiven aufeinandergetroffen.
Während unserer Diskussionen haben wir auch oft draußen auf dem Firmengelände eine Runde gedreht, um ein bisschen frische Luft (in seinem Fall mit Nikotin angereichert) zu schnappen. Irgendwann kam mal nach so einer Runde eine andere Kollegin auf meinen Kollegen zu und fragte, ob wir uns denn wieder vertragen hätten.
Für uns waren das ganz normale Diskussionen, für andere sah es aus wie Streit.
Natürlich ist das auch viel vom Charakter abhängig und einiges hätte besser laufen können.

Kritik

Es passiert schnell, dass man Kritik an der eigenen Arbeit persönlich nimmt, und es ist eine sehr wertvolle Fähigkeit, eben dies nicht zu tun, sondern objektiv an die Sache heranzugehen.
Meiner Meinung nach ist das eine der wichtigsten Lektionen, die nicht genug vermittelt werden.
Auf meinem Weg in die Softwareentwicklung habe ich zuerst eine Ausbildung zum Gestalter (offiziell: Gestaltungstechnischer Assistent für Medien und Kommunikation) gemacht.
Dort war genau das die erste Lektion, welche uns von den Lehrern vermittelt wurde:
Wenn man jemandem ein Arbeitsergebnis präsentiert, dann ist es ganz egal, was man persönlich über sein Werk denkt. Wenn das Gegenüber sagt, dass er es nicht gut findet, dann darf man das nicht persönlich nehmen.
Stattdessen fragt man nach: „Was genau passt nicht?“ „Was kann ich besser machen?“
Im besten Fall hat man natürlich jemanden vor sich sitzen, den man konkret fragen kann: „Wie kann ich es besser machen?”.
Im schlimmsten Fall bekommt man ein „Keine Ahnung, du bist doch der Experte.“ zurück.
Aber selbst dann kann man die getane Arbeit als Training ansehen. Also macht man weiter, bis das Ergebnis passt. Übung macht den Meister.

Beim Pair-Programming ist man natürlich permanent dieser „Kritik“ ausgesetzt. Auch ich musste diese Lektion wieder verinnerlichen.
Es gibt immer wieder unterschiedliche Ansätze ein Problem anzugehen, und regelmäßig haben wir uns mit einem „Agree to disagree“ für eine Lösung entschieden.
Zu den Fähigkeiten, die man mit dem Pair-Programming ausbaut, gehören auch die Kommunikation der eigenen Denkweise, sowie das Hinterfragen von unterschiedlichen Varianten und das Abwägen von verschiedenen Lösungswegen miteinander.

Erfolge

Was passierte während unserer engen Zusammenarbeit?
Ich lernte fortgeschrittenere Prinzipien und Systeme der Softwareentwicklung.
Meine Skepsis gegenüber automatisierten Softwaretests hat sich um 180° gedreht und ich bin nun großer Fan von TDD. Überall im Haus habe ich Fachlektüre wie "Fundamentals of Software Architecture”, “Vaught Vernons Domain-Driven Design” oder “A Philosophy of Software Design” herumliegen, während ich auf YouTube Kanälen wie Modern Software Engineering und Arjan Codes folge.
Gleichzeitig ist mir die Wichtigkeit von Kommunikation immer klarer geworden.
Natürlich war mir das grundsätzlich schon vorher klar, aber meine Herangehensweisen haben sich allgemein geändert und der Wissensdurst ist angewachsen.
Die Kommunikation hat sich generell verbessert, nicht nur mit dem einen Kollegen.
Es ist immer wieder wunderbar zu sehen, welche neuen Wege sich auftun, sobald man dieselben Probleme aus unterschiedlichen Perspektiven beleuchtet.
Auch habe nicht nur ich dazugelernt, sondern mein Kollege auch. Am Ende stellte sich heraus, dass vieles tatsächlich Overengineering war und zum wirklichen Verständnis der ganzen Architekturkonzepte gehört nicht nur, dass man weiß wie man sie anwendet, sondern auch, wann und wo man dies tut.
Jedenfalls hat mich mein Kollege mit der Begeisterung für das Pair-Programming angesteckt und wir sehen immer wieder Fälle, in denen es sich sehr positiv auf Projekte auswirkt (oder auswirken könnte).

Zusammenarbeit aus der Ferne

2020 kam plötzlich die Pandemie und das damit erzwungene Homeoffice.
Ich war bis dahin offen gesagt kein Fan davon, von daheim zu arbeiten. Zuvor hatte ich es nur selten ausprobiert und immer Probleme gehabt, mich auf die Arbeit zu konzentrieren.
Nun saß ich plötzlich daheim und sollte auf unbestimmte Zeit nur von da aus arbeiten?
Oha.
Gleich am ersten Tag wurde ganz selbstverständlich Teams gestartet und wir begannen darüber zu arbeiten.
Das klappte wunderbar. Wir mussten uns nicht mehr zu zweit an einen Schreibtisch quetschen und an den Tastaturbelegungen des jeweils anderen verzweifeln, wenn man mal die Rollen getauscht hat. Zugegeben, die ganzen Remote-Tools waren nicht allzu ausgereift und es gab einige technische Probleme, aber insgesamt wurde die Arbeit plötzlich sogar angenehmer und – man mag es kaum glauben – produktiver.

Mob-Programming

Zu der Zeit hatten wir allerdings auch gerade ein neues und großes Projekt bekommen und damit auch ein neu zusammengewürfeltes Team. Mit beiden gab es Startschwierigkeiten.
Also beschlossen wir kurzerhand, einfach mal Mob-Programming auszuprobieren.
Anstatt dass jeder irgendwie sein eigenes Süppchen kochte, traten wir alle einem gemeinsamen Call bei und wir arbeiteten eine Aufgabe nach der anderen in der großen Gruppe ab.
Erneut wurden wir überrascht, wie gut das funktioniert.

Natürlich war ich wieder der Skeptiker und ich hatte das erwartet, was bis dahin auch in so ziemlich jeder Gruppenarbeit passiert war: Einer oder zwei machen alles, der Rest macht etwas anderes oder ruht sich aus.
Aber tatsächlich haben sich alle eingebracht. Was uns noch mehr erstaunt hat: Darunter waren auch Leute, bei denen man sonst eher mehrmals nachfragen musste, um ein Ergebnis zu bekommen.
Wir haben uns gegenseitig hochgeschaukelt und oftmals lag das Problem eher darin, dass wir auch mal ein Ende finden mussten. Nach ein paar Tagen fingen wir dann an, auch Dinge zu parallelisieren, indem sich immer wieder kleinere Grüppchen aus dem Call lösten und ihre eigenen Calls eröffneten.
Und natürlich hat jeder von uns auch jeweils Zeit für sich gehabt und an eigenen Dingen gearbeitet. Das ging entweder vor und nach unseren gemeinsamen Calls, oder man hat sich einfach mal mit Ansage ausgeklinkt. Unsere „Gruppencalls“ waren keine verpflichtende Veranstaltung, aber wir waren trotzdem dabei.
Irgendwann waren wir in einem Modus, in dem unser Call ähnlich wie ein Großraumbüro funktionierte. Wir gingen rein, sagten „Hallo“, schalteten das Mikrofon stumm und fingen an zu arbeiten. Wer eine Frage hatte, stellte sie einfach in die Runde (auch schon mal per Chat) und immer wieder haben sich einzelne Grüppchen herausgelöst, um eine Aufgabe gemeinsam anzugehen. Es war eine sehr interessante Art zu arbeiten und wir haben natürlich auch viel über Persönliches miteinander geredet, geflucht, geschimpft und sehr viel gelacht.
Natürlich muss man dabei auch beachten, dass es eine Zeit der gesellschaftlichen Isolation war, die wir damit kompensiert haben.
Auch waren wir alle froh, dass wir uns bereits persönlich kannten und getroffen hatten, auch wenn es später nur alle paar Monate war.

Die Rückkehr zur „normalen“ Arbeit

Dann kam das nächste Projekt, diesmal unter anderer Führung.
Hier wurde ein Framework eingesetzt, welches im Lexikon unter „Overengineering“ aufgeführt werden kann.
Dazu sollten alle Entwickler nun jeweils einzeln für sich arbeiten. Schließlich sind wir ja alle Experten. Warum also sollten fünf Leute an einer Aufgabe arbeiten, wenn sie auch in derselben Zeit fünf Aufgaben abschließen können?
Aber was ist mit dem Austausch?
Dafür gibt es Code-Reviews!
Da muss jeder drübergucken und es muss eine Mindestanzahl von Approvals vorhanden sein, bevor gemerged werden darf. Zusätzlich wird jeden Morgen ein Stand-up-Meeting, äh, eine "Ceremony" gemacht. Im Durchschnitt jeweils 45 Minuten.
Der Kenner wird schon wissend mit dem Kopf nicken; hier war eine der schlimmsten Varianten von Scrum im Einsatz. Aber darauf möchte ich hier gar nicht so sehr eingehen, schließlich geht es um ein bestimmtes Thema.

Wie sah dort also die Arbeit aus?
Zuerst wurden alle Aufgaben im gesamten Team im Detail besprochen.
Das Ziel war dabei, dass jeder Entwickler sich die Aufgabe schnappen und abschließen können sollte, ohne dass Nachfragen nötig wären.
Dann hat jeder für sich seine eigene Aufgabe begonnen. Wenn man den Eindruck hatte, dass man fertig war, dann wurde ein PR eröffnet und jeder anwesende Entwickler wurde als Reviewer eingeladen.
Damit die Reviews nicht zu lange liegen blieben, gab es die Vereinbarung, dass man eine Einladung zum Review möglichst zeitnah annehmen sollte.
Also unterbrach man seine Arbeit, öffnete den PR und das damit verlinkte Ticket. Dann arbeitete man sich zuerst in die Aufgabe ein und dann in die Lösung des Kollegen.
Rein anhand des Diffs in der Web-UI war das gar nicht so einfach (dass dahinter das erwähnte viel zu komplexe Framework lag, hat nicht geholfen), und im Idealfall checkte man den Branch lokal aus, um sich das Feature (oder den Bugfix) wirklich anzuschauen.
Selten gab es kein Feedback. Irgendetwas wurde fast immer gefunden.
Da diese Reviews trotzdem immer etwas dauerten, fing der ursprüngliche Bearbeiter der Aufgabe meistens schon mal die nächste Aufgabe an. Also noch ein Kontextwechsel.
In den Reviews entstanden immer wieder Diskussionen und mehrmals mussten Aufgaben im Anschluss komplett neu angefangen werden, oder sie wurden sogar komplett eingestellt.
Keine dieser Aufgaben war zu diesem Zeitpunkt zu weniger als zwei Wochen in Entwicklung.
Wir hatten also ein System, bei dem wir nicht wirklich zusammenarbeiteten, sondern nebeneinander, mit ständigen Überschneidungen, die jeweils immer Kontextwechsel bedeuteten. Fast ausschließlich bei diesen Überschneidungen gab es Feedback, welches zu dem Zeitpunkt oftmals bereits zu spät war.

Natürlich gab es auch viele andere Probleme in dem Projekt, aber einigen von uns wurde zu der Zeit klar, dass der negative Zeiteinfluss bei Pair-Programming womöglich gar nicht so groß ist, wie wir bis dahin dachten.

Die Studienlage

Irgendwann bin ich zufällig auf diesen Artikel hier gestoßen: Der lise Blog. Ist Pair Programming Zeitverschwendung?

Es handelt sich natürlich mehr um einen Werbeartikel der Firma, mit welcher ich bisher ansonsten keine Berührungspunkte hatte.
Auch habe ich bisher anders mit Pair Programming gearbeitet, als es im Artikel beschrieben wird.
Aber am interessantesten fand ich die direkt im ersten Absatz verlinkte Studie: The Costs and Benefits of Pair Programming

Ich kann nur empfehlen, das verlinkte Dokument durchzulesen. Es ist nicht allzu lang.

Hier ist eine Zusammenfassung:

Durch die Nutzung von Pair Programming haben Aufgaben etwa 15 % länger für die Umsetzung benötigt.
Aber es führte auch zu:

• Geringere Defektrate:
  Es kam zu deutlich weniger Fehlern und Bugs in der Entwicklung.
  Dies hat den zeitlichen Mehraufwand mehr als ausgeglichen, da der Bedarf an Folgeaufgaben für Refactoring und insbesondere Bugfixing deutlich gesunken ist.

• Sauberer Stil des Codes:
  Entwicklerpaare neigen dazu, Lösungen mit weniger Codezeilen zu erstellen.
  Die Zusammenarbeit fördert die Betrachtung einer größeren Anzahl von Alternativen, was die Entwicklung eines besseren Ergebnisses fördert.

• Kontinuierliche Reviews:
  Die enge Zusammenarbeit führt zu kontinuierlichen Design- und Code-Reviews. Fehler werden viel häufiger bereits beim Eintippen entdeckt, was die Kosten für deren Behebung erheblich senkt.
  Das passt auch zu meinen vorher beschriebenen Erfahrungen und führt zu dem ersten erwähnten Punkt mit der geringeren Defektrate.

• Verbesserte Problemlösung:
  Paare berichten, dass sie Probleme schneller lösen können.
  Dies wird oft als „Pair-Relaying“ beschrieben, bei dem die Partner abwechselnd Ideen einbringen und so schwierige Aufgaben gemeinsam bewältigen.

• Bessere Lernergebnisse (Knowledge-Sharing):
  Bei dem Pair-Programming wird kontinuierlich Wissen ausgetauscht.
  Das beinhaltet alles von Arbeitsmethoden und der Nutzung von Tools bis hin zur eigentlichen Arbeit.

• Verbessertes Teambuilding und Kommunikation:
  Die Arbeitsweise erzwingt, dass man viel (quasi dauerhaft) miteinander kommuniziert.
  Dies kann die Teamdynamik, den Informationsfluss und die allgemeine Effektivität verbessern.

• Verringerung von Personalrisiken:
  Da immer mehrere Personen an einem Thema arbeiten, ist das Wissen immer verteilt.
  Das senkt das Risiko, dass sich nur eine Person mit einem Thema auskennt und der Ausfall dieser Person zu Problemen führen kann.
  Damit ist das „Schlüsselpersonenrisiko“ oder auch der „Bus-Faktor“ deutlich verringert.

• Höhere Arbeitszufriedenheit:
  Entwickler, die in Paaren arbeiten, empfinden die Erfahrung meist als angenehmer und sind zuversichtlicher in Bezug auf die Qualität ihrer Arbeit.

Es ist natürlich schön, wenn man sieht wie die eigenen Erfahrungen durch eine Studie bestätigt werden. Natürlich muss man auch auf die (möglichen) Nachteile der Methode achten.
Laut der Studie gibt es einen initialen Mehraufwand. Dazu gehören sowohl die Anpassungsphase, bei der die Entwickler sich zuerst an die Methode gewöhnen müssen, als auch die durch die zusätzliche Kommunikation generell langsamere Arbeitsweise.
Sehr viele haben auch eine anfängliche Skepsis (so wie ich sie hatte). Dies amortisiert sich meistens auch erst später, wenn man weniger Defekte im System hat. Viele hören das nicht gerne und sie bevorzugen die etwas schnellere Entwicklung von Anfang an.
Auch kann es zu persönlichen Konflikten kommen. Manche Leute haben Probleme damit, miteinander zu arbeiten und einige davon haben sich in ihrer Einzelkämpfermentalität zu sehr verfestigt.
Zusätzlich braucht auch jeder Entwickler mal etwas eigene Zeit, um sich fokussiert auf eine Aufgabe konzentrieren zu können.

Sollten wir jetzt nur noch im Pair arbeiten?

Nein.
Ich kann nur empfehlen niemandem zu glauben, der behauptet, eine Goldlösung für alles gefunden zu haben.
Beim Pair Programming sieht es genauso aus. Ich bin definitiv ein starker Verfechter dieser Methodik und ich habe bisher ausschließlich sehr gute Erfahrungen damit gemacht.
Gleichzeitig fällt es mir wirklich schwer, irgendwelche negativen Punkte zu finden.
Aber, der Einstieg ist oftmals zuerst schwierig und jeder braucht immer noch seinen eigenen Freiraum.
Je länger man vorher nur im Alleingang entwickelt hat, desto schwieriger gestaltet sich für gewöhnlich die Umstellung.
Den Grundsatz „People over Processes“ aus dem agilen Manifest würde ich auch hier anwenden.
Man sollte es aber zumindest mal für ein paar Wochen ausprobieren. Nach der ersten Woche war ich definitiv noch kein Fan, sondern das hat deutlich länger gedauert.
Man muss es auch nicht mit dem Brecheisen einführen.
Je nach Teamgröße und Verfügbarkeit könnte man einen festen Zeitslot für Pair- (oder Mob-)Programming einrichten und diesen nach Bedarf anpassen. Oder innerhalb des Teams organisieren sich kleine Gruppen selbstständig, um jeweils für ein paar Stunden (oder wenigstens Minuten) zusammen an Aufgaben zu arbeiten.
Wenn man dem Ganzen offen gegenübersteht, dann sind die Vorteile nicht von der Hand zu weisen und die Erfolge sollten spätestens nach wenigen Wochen sichtbar sein.

Zusammenfassung (tl;dr)

Pair Programming ist eine gute Methodik für nachhaltige Softwareentwicklung.
Der Einstieg ist nicht immer leicht und dabei stark von der bisherigen Erfahrung und dem Charakter der beteiligten Personen abhängig. Insgesamt wird die reine Entwicklungszeit für Features zwar etwas langsamer, aber diese Zeit amortisiert sich durch höhere Qualität, bessere Wartbarkeit, geringere Anzahl an Fehlern und verbesserte teaminterne Kommunikation.
Das Onboarding ist übrigens auch gleich mit abgedeckt, da neue Entwickler problemlos in den Prozess mit aufgenommen werden können.
All dies bestätigt nicht nur meine persönliche Erfahrung (und die vieler meiner Kollegen), sondern auch Studien.

Schlusswort

Ich lese sehr viel über Softwareentwicklung und schaue mir dabei auch immer wieder gerne an, was andere so schreiben.
Interessanterweise sehe ich Pair Programming dabei kaum erwähnt. Aber wenn, dann ist es fast ausschließlich positiv.
Es ist für mich eigenartig und mittlerweile sogar unverständlich, warum Pair Programming nicht der Standard ist, wenn es doch so viele Vorteile bringt.
Die Versuchung, mehrere Leute auf genauso viele Themen auf einmal zu werfen, scheint einfach zu groß zu sein.
Vielleicht haben auch zu viele Leute nicht das Mindset dafür, um sich wirklich darauf einzulassen.

Oder die Einstiegshürde ist für einige zu groß, um darüber hinwegzukommen.
Ich kann nur dazu raten, es mal auszuprobieren.