In der Softwareentwicklung spielt der Arbeitsfluss eine entscheidende Rolle für die Effektivität und Produktivität eines Teams. Dieser Artikel beleuchtet, warum der Flow so wichtig ist und wie Mob Programming, ein unkonventioneller und extrem kollaborativer Ansatz, zur Verbesserung beitragen kann.

Das Konzept des Flows hat seine Wurzeln in der „Lean Production“ und der „Theory of Constraints“, beides Ansätze aus der Fertigungsindustrie. Mit der zunehmenden Verbreitung von DevOps und der wachsenden Popularität von Kanban wird dieses Prinzip auch vermehrt auf die Softwareentwicklung übertragen. Viele sehen darin eine konsequente Weiterentwicklung agiler Methoden – oft als „Agilität 2.0“ bezeichnet.

Warum ist Flow in der Softwareentwicklung relevant?

In der Softwareentwicklung bezeichnet Flow den reibungslosen, kontinuierlichen Durchfluss von Arbeit durch das System – also durch den gesamten Entwicklungsprozess, der aus verschiedenen Schritten wie Planung, Entwicklung, Testen und Auslieferung besteht. Das Ziel ist es, Aufgaben möglichst ohne Verzögerungen und Unterbrechungen zu bearbeiten. Ein solcher kontinuierlicher Arbeitsfluss ermöglicht es den Teammitgliedern, sich besser zu fokussieren und Fehler schneller zu erkennen und zu beheben. Das wirkt sich positiv auf die Qualität der Software aus und fördert kontinuierliches Feedback, das wiederum zu verbesserten Produkten und Prozessen führt.

Mit einem reibungslosen Flow gewinnen Teams an Transparenz: Jeder weiß, wo das Projekt steht, was die Zusammenarbeit und das Vertrauen sowohl innerhalb des Teams als auch bei externen Stakeholdern in die Arbeit des Teams stärkt.

Ein wesentlicher Vorteil eines guten Flows ist die drastische Reduktion von Kontextwechseln. Laut einer aktuellen Studie [1] von GitKraken und JetBrains, bei der über 25 000 Entwickler:innen befragt wurden, stellen häufige Kontextwechsel das größte Hindernis für produktives Arbeiten dar. Studien aus der Psychologie [2] belegen zudem, dass Kontextwechsel nicht nur die Produktivität senken, sondern auch den Stresspegel erheblich erhöhen. Flow und Kontextwechsel beeinflussen sich dabei gegenseitig: Ein besserer Flow führt zu weniger Unterbrechungen, während weniger Unterbrechungen wiederum einen besseren Flow ermöglichen. Ohne störende Kontextwechsel können Aufgaben schneller abgeschlossen werden, was den gesamten Arbeitsfluss unterstützt.

Flow ist zudem ein zentraler Faktor für das empirische Arbeiten, das Fundament agiler Softwareentwicklung. Empirisches Arbeiten bedeutet, dass Teams auf der Grundlage von Beobachtungen und Erfahrungen entscheiden und agieren, um so ihre Prozesse und ihre Ergebnisse kontinuierlich anzupassen und zu verbessern. Empirismus, wie er in Scrum oder Kanban verankert ist, basiert auf drei Säulen: Transparenz, Inspektion und Anpassung.

Transparenz bedeutet, dass alle Beteiligten jederzeit den aktuellen Stand des Projekts überblicken können. Um echte Transparenz zu schaffen, ist kontinuierlicher Fortschritt am Produkt nötig. Genau hier spielt Flow eine entscheidende Rolle. Ohne ihn bleibt Transparenz oft auf abstrakte Fortschrittsberichte beschränkt, anstatt sich durch reale Verbesserungen am Produkt zu zeigen.

Die regelmäßige Inspektion der Arbeit und der genutzten Prozesse ist unerlässlich, um sicherzustellen, dass die Ziele des Projekts erreicht werden. Wenn jedoch kein kontinuierlicher Flow vorhanden ist, bleiben potenzielle Risiken und Missverständnisse lange unentdeckt, was die Qualität des Produkts beeinträchtigen kann. Ein guter Flow hingegen ermöglicht es, häufiger neue, benutzbare Versionen des Produkts zu erstellen, die regelmäßig inspiziert werden können. Das hilft, Risiken frühzeitig zu erkennen, und fördert fundiertere Produktentscheidungen.

Ebenso wichtig ist die Anpassung: Um wirkungsvolle Prozess- und Produktentscheidungen zu treffen, müssen diese regelmäßig angepasst werden, sobald neue Erkenntnisse vorliegen. Ein guter Flow ermöglicht es, diese Anpassungen schnell umzusetzen und ihre Wirkung zeitnah zu bewerten. Ohne einen reibungslosen Arbeitsfluss kann es hingegen lange dauern, bis Änderungen durchgeführt und deren Ergebnisse sichtbar werden, was die Reaktionsfähigkeit des Teams einschränkt und den Nutzen agiler Methoden mindert.

Ohne einen kontinuierlichen Arbeitsfluss besteht die Gefahr, dass Teams zwar agile Rituale durchführen, aber nicht in der Lage sind, echte Transparenz, fundierte Inspektionen und sinnvolle Anpassungen auf Basis tatsächlicher Ergebnisse vorzunehmen. Dadurch bleibt der eigentliche Nutzen agiler Methoden, nämlich die schnelle Reaktion auf Veränderungen und die kontinuierliche Verbesserung, unerreicht.

Flow in der Praxis

Flow bietet viele Vorteile: Er ermöglicht schnelleres Feedback und somit schnellere Kurskorrekturen, steigert die Produktivität durch weniger Kontextwechsel, verbessert die Qualität durch die enge Zusammenarbeit aller Beteiligten und hilft dabei, Prozesse zu optimieren, indem Schwachstellen schneller sichtbar werden. Zudem erhöht Flow die Transparenz, was wiederum zu fundierteren Entscheidungen führt. Angesichts dieser Vorteile könnte man erwarten, dass die Optimierung des Arbeitsflusses im Fokus aller Softwareentwicklungsteams steht. Die Realität sieht jedoch oft anders aus.

Häufig liegen Anforderungen monatelang oder sogar jahrelang im Backlog, bevor sie umgesetzt werden. Fertiggestellte Funktionalitäten müssen auf das nächste Release warten, bevor die Anwender:innen sie nutzen und Feedback geben können. Während der eigentlichen Entwicklung besteht ein großer Teil der Zeit aus Wartephasen, in denen Anforderungen darauf warten, weiterbearbeitet zu werden.

Obwohl die Wartezeiten am Anfang und Ende eines Projekts wichtige Einflussfaktoren für Business Agility sind, konzentriert sich dieser Artikel vor allem auf den Flow während der Entwicklungsphase. Das ist der Bereich, in dem die Entwickler:innen selbst den größten Einfluss haben. Doch gerade hier zeigt sich oft, dass eher auf Auslastung als auf Flow optimiert wird. Das bedeutet, dass Prozesse und Arbeitsorganisation hauptsächlich darauf abzielen, dass Entwickler:innen stets beschäftigt sind, um Leerlaufzeiten zu vermeiden. Dieser Ansatz, der als „Utilization Trap“ bekannt ist, beruht auf der Annahme, dass eine hohe Auslastung der Ressourcen automatisch zu höherer Effizienz und Produktivität führt. In der Praxis entstehen jedoch durch diese Auslastung häufig Verzögerungen, Engpässe und ineffiziente Abläufe.

Sehr anschaulich wird dieser Effekt in einem Video von Hendrik Kniberg dargestellt [3]. Im Kontext der Warteschlangentheorie lässt sich mit Hilfe der Kingman-Formel [4] der mathematische Beweis führen, dass Auslastungen nahe 100 Prozent zu sehr langen Wartezeiten und damit zu einem geringen Durchfluss führen. Im Alltag kennt jeder dieses Problem beim Autofahren: Wenn die Straßenkapazität nahezu vollständig ausgelastet ist, spricht man von Stau – mit spürbaren Auswirkungen auf den Durchsatz und die Reisezeit. Später im Artikel werden wir diese Problematik vertiefen und gängige Strategien zur Arbeitsorganisation kritisch hinterfragen.

Leider sind diese Konzepte jedoch sehr abstrakt und die daraus zu ziehenden Konsequenzen für viele kontraintuitiv. In den meisten Teams scheint es selbstverständlich, dass jedes Teammitglied, möglichst unabhängig vom Rest des Teams, klar abgegrenzte Aufgaben bearbeitet. Die Umsetzung von Funktionalität im Produkt wird zudem häufig in unabhängige Einzelschritte aufgeteilt, die dann von unterschiedlichen Personen ausgeführt werden...