Ein persönliches Plädoyer für echte Zusammenarbeit in der Softwareentwicklung

Ich gehöre vermutlich zu einer Minderheit unter Entwicklern. Der Traum vieler Kolleginnen und Kollegen sieht ungefähr so aus: Eine klar abgegrenzte Aufgabe, Kopfhörer auf, Tür zu – und dann für Stunden oder besser noch Tage „in Ruhe" an dieser Aufgabe arbeiten, um irgendwann stolz zu verkünden: „Ich bin fertig." Klingt nach Entwickler-Paradies, oder?

Für mich klingt das inzwischen eher nach Entwickler-Hölle.

Ich hasse es, über einen längeren Zeitraum alleine zu arbeiten. Was ich stattdessen bevorzuge? Mob-Programming, Pair-Programming oder wenigstens intensives Swarming. Und das sage ich nicht, weil es gerade hip ist oder weil ich es irgendwo in einem Agile-Buch gelesen habe. Ich sage es, weil ich nach Jahren in beiden Welten festgestellt habe: Die enge Zusammenarbeit macht mich nicht nur produktiver – sie macht mich zufriedener, fokussierter und ehrlich gesagt auch zu einem besseren Entwickler.

In diesem Artikel möchte ich erklären, warum das so ist. Es geht dabei weniger um die bekannten Argumente rund um Code-Qualität und Wissenstransfer – so wichtig die auch sind. Es geht um etwas, worüber wir in unserer Branche viel zu selten sprechen: Wie fühlt sich die Arbeit eigentlich an?

Was mir beim Solo-Entwickeln fehlt

Wenn ich längere Zeit alleine arbeite, fehlen mir vier Dinge ganz besonders – und zwar so sehr, dass sie mein Wohlbefinden und meine Leistung spürbar beeinflussen:

Erstens fehlt mir die Konfidenz. Alleine schleicht sich ständig ein nagendes Gefühl ein: Bin ich überhaupt auf dem richtigen Weg? Übersehe ich etwas Offensichtliches? Im Team bekomme ich sofort eine zweite Meinung – und allein das Ausbleiben von Widerspruch gibt schon eine gewisse Sicherheit.

Zweitens lasse ich mich alleine viel stärker ablenken. Im Pair oder Mob liest niemand nebenbei Mails oder scrollt durch Social Media. Alleine ist die Verführung riesig – und ich ertappe mich dabei, wie ich ihr viel zu oft nachgebe.

Drittens schlagen Energie- und Motivationstiefs voll durch. Jeder kennt diese Momente, wenn die Arbeit gerade zäh ist. In der Gruppe fängt mich jemand auf. Alleine muss ich mich selbst motivieren – und das klappt leider nicht jedes Mal.

Und viertens – das ist der für mich wichtigste Punkt – erlebe ich alleine deutlich weniger Flow. Weniger von diesen Momenten, in denen man die Zeit vergisst, völlig aufgeht in dem, was man tut, und am Ende des Tages das Gefühl hat, wirklich etwas Bedeutsames geschafft zu haben.

Lass mich auf jeden dieser Punkte genauer eingehen.

1. Weniger Konfidenz: Das ständige Zweifeln

Es gibt diesen inneren Kritiker, den vermutlich jeder Entwickler kennt. Die Stimme, die fragt: Passt die Architektur, oder baue ich gerade Mist? Gibt es eine deutlich einfachere Lösung, die ich nicht sehe? Übersehe ich ein fundamentales Problem?

Wenn ich alleine arbeite, ist diese Stimme unangenehm laut. Nicht weil ich generell unsicher wäre – sondern weil mir schlicht die Bestätigung fehlt. Oder der Widerspruch. Beides wäre hilfreich, aber beides bleibt aus.

Beim Pair- oder Mob-Programming sieht das völlig anders aus. Ich habe permanent eine zweite Perspektive. Wenn ich einen Ansatz vorschlage und kein Widerspruch kommt, dann ist das schon ein Signal: So falsch kann das nicht sein. Und wenn jemand Bedenken äußert, dann habe ich die Chance, meinen Ansatz zu überdenken, bevor ich Stunden in die falsche Richtung investiert habe. Gemeinsam finden wir dann immer eine gute, meist bessere Lösung. Selbst beim Swarming bekomme ich zumindest relativ zeitnah Feedback.

Das Ergebnis: Im Team arbeite ich mit einer inneren Ruhe, die ich alleine selten habe. Ich muss weniger Energie darauf verwenden, mich immer wieder selbst zu hinterfragen – und kann diese Energie stattdessen in die eigentliche Arbeit stecken.

2. Mehr Ablenkung: Der ständige Kampf gegen den Browser-Tab

Ich bin ein disziplinierter Mensch. Zumindest rede ich mir das gerne ein.

Aber wenn ich alleine arbeite, ertappe ich mich ständig dabei, wie der Fokus abrutscht. Ich wechsle in den Browser, und da ist noch der Tab mit der Nachrichtenseite offen. Ich sehe im Augenwinkel, dass eine neue E-Mail reingekommen ist. Oder eine Teams-Nachricht. Nur kurz schauen – und schon sind zehn Minuten weg und der Kontext, den ich mir mühsam aufgebaut hatte, ist dahin.

Im Pair-Programming passiert mir das nicht. Man liest nicht einfach nebenbei seine Mails, wenn man gerade gemeinsam mit jemand an einem Problem arbeitet. Das wäre schlicht unhöflich. Im Mob-Programming gilt das erst recht. Da können manchmal Stunden vergehen, bis ich überhaupt an meine Nachrichten denke. Nicht weil ich mich zwingen muss, sie zu ignorieren – sondern weil ich so eingebunden bin, dass ich sie schlicht vergesse.

Für mich ist die Zusammenarbeit damit eine Art natürlicher Ablenkungsschutz. Kein Tool, kein Website-Blocker und keine Pomodoro-Technik hat bei mir annähernd so gut funktioniert wie einfach gemeinsam mit anderen zu arbeiten.

3. Motivationstiefs: Gemeinsam über das Loch hinweg

Jeder kennt diese Momente. Man hat gerade eine Aufgabe abgeschlossen, steht vor dem nächsten Problem und der einzige Gedanke ist: Uff.

Es ist der Moment, in dem die Motivation auf null sinkt. In dem man eigentlich nur noch aufstehen, einen Kaffee holen oder das Handy rausholen will. Und wenn ich ehrlich bin: Genau das tue ich dann auch, wenn ich alleine arbeite. Mehrmals am Tag. Manchmal wird aus einer kurzen Kaffeepause eine halbe Stunde die ich mit anderen, viel unwichtigeren Dingen zubringe die aber in diesem Moment gerade mehr Spaß machen. Nicht weil ich faul bin – sondern weil in diesem Moment niemand da ist, der mich über das Motivationsloch hinwegzieht.

In der Gruppe fühlen sich diese Momente komplett anders an. Ein neues Problem ist dann nicht „Uff", sondern eher: Okay, das wird spannend – lass uns das mal gemeinsam angehen. Es entsteht eine Art kollektive Energie, die individuelle Tiefs auffängt.

Und das Schöne daran: Es ist keine Einbahnstraße. Wenn ich gerade ein Tief habe – was völlig normal ist und jedem passiert –, ist fast immer jemand anderes in der Gruppe, der gerade Energie hat und den Rest mitzieht. Und eine Stunde später ist es vielleicht umgekehrt. Das ist kein theoretisches Konzept, das ist gelebter Alltag in jedem Mob, den ich erlebt habe.

4. Weniger Flow – und warum das der entscheidende Punkt ist

Jetzt komme ich zu dem Thema, das mir am meisten am Herzen liegt. Es geht um Flow – diesen Zustand, in dem man die Zeit vergisst, völlig aufgeht in der Tätigkeit und das Gefühl hat, dass alles zusammenpasst. Manche nennen es „in the Zone sein".

Der Psychologe Mihaly Csikszentmihalyi hat sich über Jahrzehnte mit diesem Phänomen beschäftigt. Er beschreibt Flow als einen Zustand optimaler Erfahrung – und geht so weit, ihn als eine der wichtigsten Voraussetzungen für ein glückliches und erfülltes Leben zu bezeichnen. So weit möchte ich vielleicht nicht gehen, aber eines ist sicher: Die Tage, an denen ich Flow erlebe, sind die Tage, an denen ich abends zufrieden nach Hause gehe und Spaß an meiner Arbeit gehabt habe. Und die Tage ohne Flow fühlen sich zäh und unbefriedigend an, selbst wenn ich objektiv „genug geschafft" habe.

Das Spannende daran: Csikszentmihalyi beschreibt acht Komponenten, die Flow-Erfahrungen ausmachen – die sogenannten „Components of Enjoyment". Und als ich diese das erste Mal gelesen habe, dachte ich: Das klingt wie eine Beschreibung von gutem Mob-Programming.

Ich möchte diese acht Komponenten einzeln durchgehen und zeigen, warum sie in der engen Zusammenarbeit so viel leichter zu erreichen sind als alleine.

4.1 A Clear Goal – Klare Ziele

Flow entsteht dort, wo das Ziel klar ist. Wenn ich weiß, worauf ich hinarbeite, kann ich meine gesamte Aufmerksamkeit darauf richten. Unklarheit hingegen erzeugt Unsicherheit, Zögern und innere Reibung – alles Feinde des Flow.

Wenn wir im Pair oder Mob gemeinsam arbeiten, müssen wir uns zwangsläufig darauf einigen, was wir als Nächstes erreichen wollen. Diese Einigung erzwingt, dass das Ziel explizit wird. Mit etwas Übung werden die Ziele nicht nur explizit, sondern auch klein genug, um sie in überschaubarer Zeit zu erreichen.

Ist das Ziel unklar oder zu groß, fällt das in der Gruppe schnell auf. Jemand fragt: Was genau versuchen wir gerade? Und schon entsteht eine kurze Diskussion, die das Ziel schärft. Alleine kann es passieren, dass ich stundenlang einem vagen Ziel hinterherarbeite, ohne es zu merken. Die Gruppe ist hier ein natürliches Korrektiv.

4.2 Feedback – Unmittelbares Feedback

Flow braucht Feedback. Ich muss spüren können, ob ich dem Ziel näher komme oder nicht. Beim Sport ist das offensichtlich: Der Ball geht rein oder nicht. In der Softwareentwicklung ist Feedback oft verzögert – Code-Reviews kommen Stunden oder Tage später, und Feedback zur Benutzbarkeit - wenn überhaupt dann erst nach Wochen.

Im Pair- und Mob-Programming ist das Feedback dagegen sofort da. Ich sehe an der Reaktion meiner Kolleginnen und Kollegen, ob eine Idee gut ankommt. Ich höre sofort, wenn jemand eine bessere Alternative sieht. Ich merke in Echtzeit, ob wir dem Ziel näher kommen oder uns verrannt haben. Und genau deshalb liebe ich es, wenn ich mit Personen mobben oder pairen kann, die eine ganz andere Perspektive haben als ich - gerne auch jemand aus dem Business oder eher mit einem QS-Fokus.

Dieses unmittelbare Feedback ist wie ein Kompass, der ständig nachjustiert wird. Es hält mich auf Kurs – und genau das braucht Flow.

Und fühle ich mich im Mob manchmal gelangweilt, weil ich unterforder bin? Eigentlich nie. Irgendetwas gibt es immer beizutragen. Wenn nicht an der Aufgabe selbst, dann an der grundsätzlichen Struktur, den Tools, der Architektur oder aber auch wie wir miteinander kommunizieren und wie wir Lösungsvielfalt schaffen.

4.3 Challenges Match Skills – Die richtige Balance

Csikszentmihalyi beschreibt, dass Flow dort entsteht, wo die Herausforderung zu den eigenen Fähigkeiten passt. Ist die Aufgabe zu leicht, entsteht Langeweile. Ist sie zu schwer, entsteht Überforderung. Der Sweet Spot liegt dazwischen.

In der Gruppe ist dieser Sweet Spot viel leichter zu treffen. Ich kann mich mit meinen Stärken einbringen, und andere Mitglieder der Gruppe ergänzen dort, wo ich nicht so stark bin. Gemeinsam lösen wir Probleme schneller, weil wir auf einen breiteren Pool an Wissen und Erfahrung zugreifen können.

Besonders bei wirklich schwierigen Problemen zeigt sich der Vorteil: Wo ich alleine vielleicht resigniert hätte, hat in der Gruppe fast immer jemand noch eine Idee, was wir ausprobieren können. Die Herausforderung bleibt hoch, aber das Gefühl der Überforderung bleibt aus. Genau das ist die Voraussetzung für Flow.

4.4 Concentration – Tiefe Konzentration

Flow erfordert anhaltende, tiefe Konzentration. Jede Unterbrechung reißt einen heraus – und der Weg zurück in den fokussierten Zustand kostet Zeit und Energie.

Im Mob habe ich deutlich weniger Unterbrechungen. Der Grund ist einfach: Idealerweise sind die Personen, die ich für eine Aufgabe brauche, bereits im Raum. Es entstehen viel weniger Abhängigkeiten nach außen. Wir können Aufgaben in einem Rutsch erledigen, haben weniger Kontextwechsel und bleiben fokussiert.

Und selbst wenn einzelne Personen den Mob temporär verlassen müssen – sei es für ein Meeting oder einen kurzen Anruf –, kann der Rest nahtlos weiterarbeiten. Wenn die Person zurückkommt, steigt sie einfach wieder ein und ist innerhalb von Minuten wieder integriert. Alleine hingegen bedeutet jede Unterbrechung: kompletter Neustart des mentalen Kontexts.

4.5 Focus – Fokus halten

Diesen Punkt habe ich weiter oben bereits angeschnitten, aber im Kontext von Flow verdient er eine eigene Betrachtung. Flow erfordert nicht nur punktuelle Konzentration, sondern die Fähigkeit, den Fokus über einen längeren Zeitraum aufrechtzuerhalten. Es geht um Ausdauer in der Aufmerksamkeit.

In der Gruppe fällt das so viel leichter. Die gemeinsame Arbeit erzeugt eine natürliche Verbindlichkeit: Ich bleibe beim Thema, weil andere beim Thema sind. Es gibt eine Art sozialen Rhythmus, der den Fokus trägt.

Und wenn ich mal einen Hänger habe? Dann ist das kein Drama. Der Rest der Gruppe hält den Flow aufrecht. Ich kann mich gedanklich für ein paar Minuten rausnehmen, durchatmen – und dann wieder mit frischer Energie einsteigen. Alleine hingegen bedeutet ein Hänger oft: Der Fokus ist weg, und es dauert eine halbe Stunde, bis ich ihn wiederhabe. Wenn überhaupt.

4.6 Control – Kontrolle über den Prozess

Ein wesentliches Element von Flow ist das Gefühl, die Situation unter Kontrolle zu haben – oder zumindest die Möglichkeit zu haben, sie zu beeinflussen.

In der Gruppe ist dieses Kontrollgefühl überraschend groß. Wir können als Team mit Unterbrechungen und Unvorhergesehenem viel besser umgehen als ich alleine. Fällt eine Person für Support aus, arbeitet der Rest weiter. Kommt ein unerwartetes Problem, haben wir mehr Perspektiven, um damit umzugehen.

Dazu kommt etwas, das ich sehr schätze: Die Bereitschaft, neue Wege zu gehen und Althergebrachtes in Frage zu stellen, ist in der Gruppe deutlich größer als alleine. Alleine neige ich dazu, bei bewährten Mustern zu bleiben – auch wenn sie vielleicht nicht mehr optimal sind. In der Gruppe trauen wir uns mehr. Und dieses „Trau dich" verstärkt das Kontrollgefühl: Wir gestalten den Prozess aktiv, statt ihm ausgeliefert zu sein.

4.7 Loss of Self-Consciousness – Das Ego tritt zurück

Csikszentmihalyi beschreibt, dass im Flow das Bewusstsein für das eigene Selbst in den Hintergrund tritt. Man denkt nicht mehr darüber nach, wie man wirkt oder ob man gut genug ist. Man geht vollständig in der Tätigkeit auf.

Wenn man sich auf echte Teamarbeit einlässt, passiert genau das. Das Ego hat dort keinen Platz. Am Ende eines intensiven Mob-Tages lässt sich nicht genau sagen, wer jetzt diese geniale Idee hatte oder wer letztendlich die Lösung für das knifflige Problem gefunden hat. Es sind gemeinsame Gedankengänge – jeder baut auf dem auf, was andere schon vorgedacht haben.

Und am Ende ist es auch egal.

Es geht nicht darum, der Star zu sein. Es geht darum, ein wichtiger Teil eines Teams zu sein, das gemeinsam etwas geschafft hat. Ich weiß, dass manche Entwickler damit Probleme haben – diesen individuellen Star-Status aufzugeben. Für mich persönlich ist es aber ungleich befriedigender, etwas gemeinsam erreicht zu haben, als alleine auf einem Podest zu stehen.

4.8 Transformation of Time – Die Zeit verfliegt

Das letzte und vielleicht greifbarste Merkmal von Flow: Das Zeitempfinden verändert sich.

Wenn ich alleine arbeite und gerade kein Flow da ist, zieht sich die Zeit wie Kaugummi. Ich schaue auf die Uhr, und seit dem letzten Mal sind gerade einmal sieben Minuten vergangen. Ich schaue wieder hin – elf Minuten. Der Tag fühlt sich endlos an.

Im Mob und im Pair ist das für mich komplett anders. Meistens verfliegt die Zeit. Man wundert sich, dass es schon wieder Mittag ist, und dann wieder, dass der Tag schon fast rum ist. Aber – und das ist der entscheidende Unterschied – man blickt auf einen erfüllten Tag zurück. Man hat das Gefühl, wirklich etwas erreicht zu haben. Nicht weil man sich verausgabt hat, sondern weil die Arbeit sich nicht wie Arbeit angefühlt hat.

Für mich ist das der ultimative Beweis: Flow ist im Team nicht die Ausnahme, sondern eher die Regel.

Fazit: Es geht um mehr als Code-Qualität

Pair- und Mob-Programming haben sehr viele positive Aspekte, die sich auf die Qualität des Produktes und des Codes beziehen. Weniger Bugs, besseres Design, breitere Wissensverteilung im Team – all das ist gut dokumentiert und vielfach belegt.

Aber darüber wird ein Aspekt oft übersehen, der für mich mindestens genauso wichtig ist: Die persönliche Zufriedenheit bei der Arbeit.

Ich habe für mich festgestellt, dass enge Zusammenarbeit mich nicht nur produktiver macht, sondern vor allem zufriedener. Es macht mir schlicht mehr Spaß. Ich bin motivierter, fokussierter und gehe abends mit einem besseren Gefühl nach Hause. Und wenn ich ehrlich bin: Ich suche inzwischen gezielt nach Engagements, bei denen ich eng mit anderen zusammenarbeiten kann.

Damit sage ich nicht, dass Solo-Arbeit per se schlecht ist. Es gibt Aufgaben, die man sinnvollerweise alleine erledigt, und es gibt Menschen, die in der Einzelarbeit aufblühen. Das ist völlig in Ordnung. Aber ich frage mich, bin ich da eine Aussnahme oder würden viele andere Entwicklerinnen und Entwickler auch von besserer Zusammenarbeit profitieren? Können wir so für mehr Spaß bei der Arbeit sorgen?

Wenn ich dir mit diesem kleinen Post einen kleinen Impuls geben konnte und du das vielleicht selbst mal ausprobieren möchtest, würde mich das echt freuen. Und wenn du einfach mal ausprobieren möchtest, wie sich das anfühlt oder wenn du gar für dich und dein Team einen Coach haben möchtest, der euch bei den ersten Schritten begleitet, dann melde dich sehr gerne bei mir.

Kurz erklärt: Pair-Programming, Mob-Programming und Swarming

Pair-Programming bedeutet, dass zwei Entwickler gemeinsam an einem Computer arbeiten. Eine Person schreibt den Code (der „Driver"), die andere denkt mit, reviewt in Echtzeit und gibt Richtung vor (der „Navigator"). Die Rollen werden regelmäßig getauscht.

Mob-Programming (auch „Ensemble Programming") erweitert dieses Prinzip. Mehrere Personen arbeiten gleichzeitig am selben Problem, am selben Computer. Auch hier gibt es einen Driver – die restlichen Teammitglieder navigieren gemeinsam. Der Driver-Rolle rotiert in kurzen Intervallen.

Swarming ist weniger formalisiert. Ein Team konzentriert sich gemeinsam auf eine einzelne Aufgabe, aber nicht zwingend am selben Computer. Die Teammitglieder arbeiten parallel an verschiedenen Aspekten derselben Aufgabe und stimmen sich häufig ab. Es ist gewissermaßen eine intensivere Form der Zusammenarbeit als üblich, aber weniger eng getaktet und weniger intensiv als Mob-Programming.