Arvid sitzt seit 15 Minuten vor seinem Rechner, ohne einmal die Tastatur berührt zu haben – es fällt ihm sichtlich schwer. Sein Job ist in dieser Zeit zuzuschauen. Arvid – Anfang 30, sportlich – ist Programmierer bei Volkswagen, trägt aber weder Blaumann noch Krawatte, sondern Hoodie und Adidas-Sneaker. Er muss seinem Pairing-Partner Jonas noch zehn Minuten über die Schulter schauen, bevor er wieder selber an die Tastatur darf.

Auch große Konzerne setzen auf Startup-Methoden: Das Digital-Lab-Berlin ist Volkswagens Vorzeige-Lab und arbeitet nahezu komplett agil. Hier wird seit der Gründung Software mit Pair-Programming umgesetzt – eine Methode, bei der zwei Entwickler gleichberechtigt an einer Aufgabe sitzen. So sollen schnellere Ergebnisse möglich sein und durch das Pairing die Qualität der Umsetzung steigen. Doch wie gut funktioniert die Methode in der Praxis? Und lohnt sich überhaupt, zwei Entwickler für eine Aufgabe zu bezahlen?

Der Tag im Berliner Lab beginnt früh: um 8 Uhr. Nach einer Führung durch das Büro, das auf drei Etagen verteilt ist, fällt schnell auf: Die VW-Werkshallen in Wolfsburg sind hier in Berlin-Friedrichshain weit weg. Starre Strukturen und Anzugträger sind nicht zu sehen. Die Mitarbeiter sind je nach Projekt einer Etage und einem Platz zugeteilt, feste Arbeitsplätze gibt es nur für Wenige. Das Büro ist offen, hell und hat alles, was man sonst eher in einem Startup-Büro erwartet: eine Tischtennisplatte, Sitzsäcke, Playstation und hippe Getränke. Um 8:30 Uhr gibt es ein freiwilliges Standup-Meeting, bei dem unter anderem aktuelle Besucher oder Events angekündigt werden. Aber vorher gibt es erstmal ein für Mitarbeiter kostenloses Frühstück mit Müsli, Bagels, Eiern, Wurst- und Käseplatte.

Es ist noch vor neun Uhr, und Arvid und Jonas sitzen bereits startklar am Rechner. Im Lab gibt es feste Arbeitszeiten 8:30 bis 17 Uhr. Das ist wichtig für die Teams. „Anders würde das Pair-Programming nicht funktionieren”, sagt Jonas. Arvid und Jonas sitzen zwar nebeneinander, dennoch hat jeder seinen eigenen Bildschirm sowie Maus und Tastatur. Die Bildschirme sind synchron, sodass jeder an seinem Rechner arbeiten beziehungsweise zuschauen kann.

Bevor es losgeht, stellt Arvid einen Timer auf 25 Minuten. Wenn die Zeit abgelaufen ist, folgen fünf bis zehn Minuten Pause, dann ist Jonas an der Reihe. E-Mails oder andere Kommunikations-Tools wie Slack sind in dieser Zeit tabu. „Wir empfangen keine projektrelevanten Mails, dafür haben wir unser Tool. Und es wird darauf geachtet, die Konzentration der Teams im Arbeitsalltag so wenig zu stören wie möglich“, erzählt Jonas. Der Ausnahmefall ist allerdings interessant: Nora – Projektmanagerin – platziert einen kleinen aufblasbaren Flamingo auf dem Boden, hinter Arvids Rücken. „So weiß ich, dass sie eine Frage hat. Sie wird uns bei Themen, die nicht eilig sind, nicht extra unterbrechen“, erklärt Arvid.

Es wird laut. Selbst für ein Großraumbüro ungewöhnlich laut, denn die Pairing-Partner besprechen ihre Aufgaben. Doch nach wenigen Minuten sinkt die Lautstärke wieder auf einen angenehmen Pegel.

Arvid hat bereits angefangen zu coden. Jeden Gedanken und jede Veränderung spricht er laut aus, während Jonas auf seinem Bildschirm das Vorgehen beobachtet. Häufig stellt er auch Fragen, sodass Jonas seine Idee oder einen gegebenenfalls besseren Vorschlag einbringen kann.

Ist es nicht anstrengend dauernd laut zu denken? Arvid antwortet: „Definitiv! Ich habe einige Zeit gebraucht um mich daran zu gewöhnen. Die erste Zeit war ich nach der Arbeit echt erschöpft.” Jonas ist erst seit vier Wochen im Digital Lab Berlin und sagt: „Dem stimme ich zu! Ich bin noch mitten in der Gewöhnungsphase. Das ist schon sehr anspruchsvoll.”

Das Projekt, an dem die beiden arbeiten, wird in Go geschrieben. Arvid hat eine erkennbare Vorliebe für die Sprache. Jonas hingehen lernt sie gerade erst: „Somit ist es für mich doppelt anstrengend“.

Die Zeit ist um. Jonas ist an der Reihe. Ihm fällt das Programmieren mit Go sichtlich schwerer als Arvid. Muss der sich nicht beherrschen, nicht dazwischen zu gehen, wenn er doch weiß, dass er selbst schneller wäre? „Na klar würde ich das manchmal gerne, aber wir sind ein Team. Wir wollen beide dazulernen und auch voneinander, wir wollen immer besser werden, um möglichst viel gemeinsam zu erreichen“, antwortet Arvid.

Der Timer läuft Stunde für Stunde, Arvid und Jonas wechseln sich jedes Mal ab. Manchmal ist es auch ein fließender Übergang.  Volkswagen lässt seinen Entwicklern beim Pair-Programming viel Freiraum. Im SDC (Software-Development-Center) Wolfsburg wird zum Beispiel auch ganz klassisch gecoded, erzählt uns Frank Loydl aus der Volkswagen-Konzern-IT und Leiter Software-Development. Kurz nach unserem Gespräch wurde er IT-Chef der Marke Audi.

Loydl erzählt, wie Volkswagen überhaupt zum Pair-Programming gekommen ist: „Die grundsätzlich positive Erfahrung mit agilem Arbeiten im Volkswagen-Konzern hat uns gezeigt: Das funktioniert richtig gut. Und wir können damit wirklich erfolgreich sein. Die logische Konsequenz war die Frage, wie wir uns hier noch weiter entwickeln können. Eines war von Beginn an klar: Neue Methoden müssen das höchste Niveau der Entwicklung erfüllen.”

„Pair-Programming ist natürlich nicht immer die beste Lösung.”

Trotz der Entstehung in den 90er Jahren ist die Methode in der praktischen Anwendung nicht überall verbreitet. Was die Gründe dafür sind, erklärt Loydl: „Pair-Programming ist natürlich nicht immer die beste Lösung. Diese Methode eignet sehr gut für bestimmte Projekte – für andere Projektsituationen ist sie wirtschaftlich nicht sinnvoll“, erläutert er. „Für Software, bei der es um maximale Entwicklungsgeschwindigkeit bei sehr hoher Qualität geht, ist Pair-Programming das beste Mittel der Wahl. Denn es erlaubt eine schnelle Anpassung, wenn sich Anforderungen an die Software ändern. Bei anderen Projekten können andere Arbeitsmethoden der wirtschaftlichere Weg sein.“

Unser Besuch zeigt, dass agiles Arbeiten auch in großen Konzernen möglich ist. Zumindest dann, wenn das Vorgehen beherrscht wird und bestimmte Regeln vorhanden sind.

Dabei liegt Pair-Programming als Methode nicht jedem und es benötigt immer eine gewisse Eingewöhnungszeit. Doch es bietet viele Vorteile: keine Überstunden, schnelle Veränderbarkeit, kurze Kommunikationswege und ein kontinuierliches Lernen voneinander. Um so fokussiert wie Jonas und Arvid arbeiten zu können, werden allerdings auch bestimmte Unternehmensstrukturen vorausgesetzt. Denn nur dann lohnt es sich auch, zwei Entwickler für eine Aufgabe zu bezahlen und am Ende schnellere sowie bessere Ergebnisse zu erreichen.

Übrigens: Kein Unternehmen ist von heute auf morgen agil. Es ist ein Prozess, der niemals endet. Und ohne richtige Betreuung verfallen Mitarbeiter schnell wieder in alte Muster.