Perspektivenwechsel - eine agile Kolumne

Singletasking

Bob und Jens, zwei alte Freunde, treffen sich in ihrer Stammkneipe.Jens: Ich wünschte, ich wäre eine Frau! Bob: Aha?!?

Naja, nicht so richtig. Aber man sagt doch immer, dass die Frauen uns Männern beim Multitasking haushoch überlegen sind. Und gestern habe ich es wieder selbst erlebt: Meine Frau saß am Rechner und hat ihren Unterricht für den nächsten Tag vorbereitet. Gleichzeitig lief im Hintergrund der

Fernseher, und sie hat die ganze Handlung mitbekommen. Und als dann das Telefon klingelte, hat sie sich einfach den Hörer geschnappt und nebenbei auch noch telefoniert. Ich hingegen war schon überfordert, als ich beim Kochen zwei Herdplatten gleichzeitig domptieren musste.

Ja, das ist beeindruckend.

Kann man Multitasking eigentlich lernen? Gibt es dafür Kurse? Stell dir mal vor, wie effizient man bei der Arbeit sein könnte, wenn man seine vielen parallelen Projekte besser im Griff hätte!

Hm. Vielleicht geht das aber auch in die falsche Richtung, und wir sollten stattdessen lieber ganz auf Multitasking verzichten.

Hä?

Unterm Strich wirkt es sich eigentlich immer negativ aus.

Wieso denn das?

Zuerst einmal kosten Kontextwechsel ja bekanntlich sehr viel Zeit und Energie. Das weiß jeder, der schon einmal an einer anspruchsvollen Aufgabe saß, dabei unterbrochen wurde und sich danach wieder in die Aufgabe eindenken musste.

Jens. Ja klar, das ist bekannt. Aber darum geht es doch gar nicht. Ich arbeite zum Beispiel gerade in einem Projekt, in dem wir eine große Webanwendung bauen. Da kann ich regelmäßig nicht weiterarbeiten, weil ich auf die Zuarbeit der Webdesigner angewiesen bin. Ich kann natürlich nicht einfach rumsitzen. Deshalb arbeite ich parallel noch in einem zweiten Projekt – und manchmal auch in einem dritten.

Und das ist noch nicht einmal viel. Ich treffe öfters Leute, die in mehr als 5 Projekten gleichzeitig arbeiten. Aber selbst 3 Projekte sind eindeutig zu viel – optimal ist ein einziges.

Das kann nicht sein! Wenn ich nur in einem einzigen Projekt arbeiten würde, wäre ich im Schnitt höchstes zu 80 % ausgelastet – das erklär mal meinem Chef!

Genau da liegt das Problem: In der Regel sehen wir (und vor allem unsere Chefs) auf die Auslastung einzelner Kollegen oder Abteilungen und versuchen, diese zu maximieren. Dabei übersehen wir, welche Folgen das auf Projektebene hat.

Aber wenn jeder Einzelne voll ausgelastet ist, dann arbeitet doch auch das ganze Projekt sehr effizient!

Eben nicht! Betrachten wir deinen Fall einmal etwas genauer: Nehmen wir an, dass der positive Effekt, den du durch eine höhere Auslastung durch die Arbeit in mehreren Projekten erreichst, nicht wieder durch die vielen Kontextwechsel aufgefressen wird – was ich kaum glaube. Man darf auch den erhöhten Kommunikationsaufwand nicht vergessen, den man durch die Zusammenarbeit mit vielen Kollegen zwangsläufig hat. Das eigentliche Problem liegt aber darin, dass alle Projekte viel später abgeschlossen werden.

Fällt das denn wirklich ins Gewicht?

Und ob! Du hast gesagt, dass du in deinem ersten Projekt etwa zu 80 % ausgelastet bist. Vermutlich wirst du aber in deinem zweiten und dritten Projekt nicht nur 20 % deiner Zeit arbeiten. Denn dafür würde sich eine Einarbeitung kaum lohnen.

Stimmt. Ich arbeite eigentlich in allen drei Projekten gleich viel.

Lass uns doch einmal aufmalen, was das für Folgen hat.

Bob nimmt sich einen Zettel und einen Kuli und malt eine Grafik

Abb. 1: Verzögerung durch parallele Projekte. Leicht verändert nach Eliyahu Goldratt (2002): Die kritische Kette. S. 134

In der rein sequenziellen Variante braucht Projekt A zehn Wochen bis zur Fertigstellung, in der parallelen Variante sind es 23 Wochen.

Wahnsinn! Durch den ständigen Wechsel entstehen ja riesige Verzögerungen.

Stimmt, es dauert nun mehr als doppelt so lange, bis ein Projekt abgeschlossen werden kann. Und das darf sich eigentlich kein Unternehmen erlauben, denn heute kommt es mehr denn je darauf an, früh am Markt zu sein.

Naja, so extrem gilt es ja zum Glück nur für Projekt A. Projekt B hingegen wird bei der unteren Herangehensweise nur etwas später fertiggestellt als oben. Und bei Projekt C entstehen gar keine Verzögerungen – es ist in beiden Fällen nach insgesamt 30 Wochen zu Ende gestellt.

Verzögerungen nicht, aber das Projekt startet viel früher als es müsste.

Und das soll schlecht sein?

Ja! Geschwindigkeit ist in beide Richtungen wichtig. Entweder, ich beginne früh mit einem Projekt und will dann auch früh am Markt sein. Dann habe ich zumindest für eine kurze Zeit einen sehr hohen Marktanteil und kann vielleicht sogar meine eigene Technologie als Standard etablieren. Oder ich finde mich damit ab, dass ich zeitgleich mit meinen Mitbewerbern am Markt bin oder sogar etwas später – aber dann will ich auch so spät wie möglich starten.

Eigentlich ist das logisch. Wenn ich später beginne, kann ich die Zeit vor Projektstart dafür verwenden, um so viele Informationen wie möglich zu sammeln, um mir über mein Produkt klarer zu werden, um den Markt zu analysieren, die Konkurrenz zu beobachten und so weiter.

Genau. Und es kommt noch ein weiterer Punkt dazu: Bei uns in der IT ändern sich Technologien beinahe täglich – sowohl bei der Software als auch bei der Hardware. Wenn ich später mit einem Projekt beginne, kann ich neuere Technologien verwenden oder günstigere Hardware einbauen. Auch das kann einen deutlichen Wettbewerbsvorteil darstellen.

Darüber muss ich unbedingt einmal mit meinem Chef sprechen. Aber soll ich jetzt auch meiner Frau das Multitasking verbieten?

Das wird sie sich wohl kaum verbieten lassen. Und vermutlich legt deine Frau auch keinen großen Wert darauf, dass die Telefonate so schnell wie möglich beendet werden…

Perspektivenwechsel

Unser Effizienzdenken verleitet uns immer wieder zu Multitasking – sowohl bei unseren persönlichen Aufgaben als auch bei unseren Projekten. Der Grund dafür liegt häufig in unserem Auslastungsdenken: „Je größer der Anteil meiner Arbeitszeit, die ich mit produktiven Tätigkeiten verbringe, desto besser.“ Diese Sichtweise führt jedoch leicht zu lokalen Optimierungen und ist auf Projekt- oder Organisationsebene alles andere als effizient. Denn letztlich ist es völlig irrelevant, wie hoch die Auslastung einzelner Kollegen oder Abteilungen ist. Entscheidend ist viel mehr, wie schnell ich (erfolgreiche) Projekte abschließen und (gute) Produkte liefern kann. Und hierfür ist es in der Regel eine gute Idee, sich auf ein einzelnes Projekt zu fokussieren und das mit voller Kraft voranzutreiben, bis es wirklich abgeschlossen ist. Und wenn das bedeutet, dass einzelne Kollegen zwischendurch Leerlauf haben? Bevor man dann krampfhaft nach einem zweiten Projekt sucht, um diese Kollegen auszulasten, sollte man sie vielleicht lieber „rumsitzen“ lassen. Wie Google beweist, können aus solchen „Slack-Zeiten“ durchaus neue, kreative Ideen entstehen.

Eine andere Möglichkeit wird von Lean und verschiedenen agilen Ansätzen vorgeschlagen: Idealerweise sollte es einen gleichmäßigen Arbeitsfluss während der gesamten Projektlaufzeit geben. Wenn dem nicht so ist und einzelne Teammitglieder regelmäßig warten müssen, liegt ein systematisches Problem vor, das vom gesamten Team plus Management behoben werden sollte. Wenn beispielsweise die Arbeit der Entwickler ruht, weil sie auf die Zuarbeit der Webdesigner warten müssen, dann besteht hier offensichtlich ein Engpass, der behoben werden sollte. Eine einfache Lösung könnte darin bestehen, mehr Webdesigner einzustellen. Vielleicht sind die Designer aber auch nur schlecht verfügbar, weil sie in zu vielen parallelen Projekten arbeiten? Oder sie müssen so viel Papierkram erledigen, dass sie kaum noch zum designen kommen? Oder sie müssen ihre Entwürfe ständig neu machen, weil sie die Anforderungen der Entwickler nicht richtig verstehen? In all diesen Fällen liegt ein systematisches Problem vor, das sich vermutlich relativ leicht beheben lässt, sobald es erst einmal erkannt wurde. Werden Wartezeiten hingegen durch immer mehr parallele Projekte „kompensiert“, so werden damit gleichzeitig die tiefer liegenden Probleme verschleiert. In diesem Sinne führt Singletasking nicht nur zu kürzeren Durchlaufzeiten, sondern es macht auch schnell Probleme deutlich und kann so zu wichtigen Prozessverbesserungen führen.

Arne Roock arbeitet bei der it-agile GmbH in Hamburg. Als studierter Germanist interessiert er sich für informative, leicht verständliche und kooperative Kommunikation. Außerdem beschäftigt er sich seit Längerem mit den Themen Selbstorganisation und Zeitmanagement in der IT.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.