Das Berater-Mantra „stop starting, start finishing“ ist ja schön und gut. Aber wozu? Welche konkreten Auswirkungen haben Taskwechsel in der Realität?
Task-Switching und Ansätze von Multitasking begegnen uns in der Produkt- bzw. Softwareentwicklung, in Projekten und der Wissensarbeit in den verschiedensten Formen: Auf höchster Ebene arbeitet ein Unternehmen an mehreren Produkten parallel. Ein Dienstleister übernimmt mehr Aufträge, als die Ressourcen zulassen. Ein Softwareteam bekommt mehrere Domänen, Module, Komponenten oder Projekte zugewiesen. Auf der Ebene der täglichen Arbeit zeigt ein Blick auf das Kanban-Board, dass manche Entwicklerinnen und Entwickler mehr als ein Item zeitgleich in Bearbeitung haben.
Im Alltag bedeutet dies, dass auf verschiedensten Flughöhen immer wieder zwischen Aufgaben und Kontexten gewechselt werden muss. Die Auswirkungen davon können wir beobachten und spüren. Vorhaben werden später fertig als gedacht. Alle sind beschäftigt und geschäftig, doch nichts geht voran.
Welche Argumentationen können helfen, Unternehmen und Menschen davon zu überzeugen, Parallelarbeit zu reduzieren oder zu vermeiden?
Inhaltsverzeichnis
Auswirkungen in Simulationen erlebbar machen
Um den Alltag auszublenden und das Thema Multitasking fokussiert zu betrachten, bieten sich zunächst ausgewählte Spiele und Simulationen an.
Eine erste Möglichkeit, die sich vom Aufbau und Ablauf nahe an den Kanban-Boards von Softwareteams orientiert, ist TWiG. TWiG ist eine einfache Simulation, um den Teilnehmenden einen Eindruck von der Arbeit in einem Work-in-Progress-begrenzten System zu geben:
Wenn Du nicht am Rechner sitzen willst und Vor-Ort-Formate suchst, gibt es einiges an Optionen. Das Kanban Pizza Game ist ein Klassiker, den es in verschiedenen Abwandlungen auch zum Bau von Papierfliegern oder Faltschwänen gibt.
Soll es schnell gehen, bietet sich für zwischendurch das Multitasking Name Game an. Dieses braucht wieder viel Zeit, noch großen Vorbereitungsaufwand.
Der Vorteil von solchen Spielen und Simulationen ist, dass sie unmittelbare Reflexionen über das Erlebte und Beobachtete erlauben. Und ja, sie machen auch einfach Spaß.
Der Nachteil ist, dass die Übertragung des Erlernten in den Alltag schwierig ist.
Und je nach Zielgruppe können Spiele auf Ablehnung stoßen. Für Zahlenmenschen beispielsweise braucht es etwas Greifbares.
Die finanziellen Kosten von Multitasking
In seinem bereits 1992 erschienenen Buch „Quality Software Management: Systems Thinking“ zeigt Gerald M. Weinberg folgende Zahlen zum Verlust beim Wechsel zwischen verschiedenen Projekten:
Ein wichtiges Wort zur Einordnung dieser Zahlen: Weinbergs Schätzungen beruhen auf Beobachtungen und Erfahrungen und nicht auf kontrollierten wissenschaftlichen Studien. Sie sind nicht universell gültig.
Neuere Forschungsergebnisse aus der Kognitionspsychologie und den Neurowissenschaften deuten darauf hin, dass die Kosten für den Wechsel zwischen verschiedenen Aufgaben vielschichtiger sind als Weinbergs lineares Modell. Faktoren wie die Komplexität der Aufgaben, die individuelle kognitive Flexibilität und die Art der Aufgaben wirken sich erheblich auf die Reduzierung aus. Wenn Du hier tiefer einsteigen willst, ist Sophie Leroys Arbeit zur „Attention Residue“ ein guter Anfang.
Weinbergs Zahlen verdeutlichen jedoch nach wie vor anschaulich das Problem, das bei Multitasking entsteht. Dargestellt als Diagramm wird der Verlust noch einmal deutlicher:
Und nun stellen wir uns mal vor, was dies mit Blick auf die Entwicklungskosten bedeutet.
Gehen wir der Einfachheit halber von einem Jahresbruttogehalt von 60.000 € für eine Softwareentwicklerin aus. Zusammen mit den Lohnnebenkosten ergibt dies ein Arbeitgeberbrutto von schätzungsweise 72.000 € pro Jahr bzw. 6.000 € pro Monat.
Kombiniert man diese Kosten nun mit den Verlusten aufgrund von parallelen Projekten bzw. Aufgaben, ergibt dies folgendes Bild:
Selbst im einfachsten Fall mit nur zwei parallel laufenden Projekten ergibt dies einen monetären Verlust von 1.200 € pro Monat. Und das gilt nur für einen Menschen. Gehen wir von einem kleinen Team mit 4 Entwicklerinnen aus, sprechen wir bereits von 4.800 € pro Monat und damit 57.600 € pro Jahr. Das entspricht in diesem Beispiel fast den Kosten für eine volle Entwicklerstelle. Das muss man sich erstmal leisten können.
Und bis hier sprechen wir nur von (einem Teil der) Entwicklungskosten. Lohnt sich dieser Verlust denn dann zumindest in Hinsicht auf die zeitliche Fertigstellung von Vorhaben?
Die zeitlichen Kosten von Aufgabenwechseln
Henrik Kniberg hat vor Jahren einen schönen Impuls zum Thema Work-in-Progress und Flow gegeben.
Auf Basis dessen könnte der Ablauf von drei Projekten in einem Unternehmen so aussehen:
In vielen kleinen Abschnitten wird abwechselnd an allen drei Projekten gearbeitet. Alle sind beschäftigt und Stakeholder bekommen den Eindruck, dass etwas passiert. Formt man die Darstellung oben ein klein wenig um, zeigt sich dieses Bild von Anfang und Ende jedes Vorhabens:
Aber Moment: Was noch fehlt, sind die Verluste für die Arbeit an drei parallelen Projekten! Ziehen wir also Weinbergs Zahlen heran und schlagen die sich daraus ergebenden 40 % Verschwendung für drei gleichzeitige Projekte auf, verändert sich der Ablauf:
Das ist ein deutlicher Unterschied in der Fertigstellungszeit im Vergleich zum naiven Idealbild.
Und jetzt schauen wir mal, was sich ändert, wenn die drei Projekte sequenziell und fokussiert abgearbeitet werden:
Zwei von drei Vorhaben werden deutlich früher abgeschlossen. Das bedeutet früheren Umsatz für das Unternehmen, schafft Freiräume für neue Projekte und obendrauf kommen noch vorgezogene Lerneffekte bzw. Anpassungsmöglichkeiten.
Fazit
Multitasking, Aufgabenwechsel, Parallelarbeit und häufige Kontextwechsel sind Verschwendung.
Sie kosten bares Geld durch die geistige Rüstzeit, die bei Taskwechseln entsteht. Sie erzeugen Verzögerungen bei der Bearbeitung und Fertigstellung von Produkten und Projekten. Und sie beeinträchtigen die Reaktions- und Anpassungsfähigkeit von Organisationen.
Dieser „Waste“ lässt sich berechnen und klar aufzeigen. Die konkreten Kosten variieren natürlich je nach Unternehmen und weiteren Faktoren. Trotzdem liefern Weinbergs Zahlen eine Grundlage, um sich der Verluste klar zu werden.
Und so bleiben die Empfehlungen bestehen, Softwareteams mit klaren Prioritäten und einem fokussierten Arbeitsfluss zu strukturieren. Dies vermeidet Effizienz- und Effektivitätsverluste und steigert somit die Produktivität.
Schnapp Dir die 7 Fragen für hochproduktive Entwicklungsteams und buche Deine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Dich am wirkungsvollsten unterstützen kann.
