Bitte (gaaaanz lang) warten!

“Bitte warten – Ein Mitarbeiter wird sich gleich bei Ihnen melden!”

“Bitte hier anstellen!”

“Stau auf der Südost-Tangente, rechnen Sie mit einem Zeitverlust von mindestens 1 Stunde!” 

“Ein Moment noch, wir rufen Sie auf, wenn Sie dran sind!” 

Steigt bei Ihnen auch der Puls, wenn sie diese Sätze lesen? Das erinnert an Arztpraxen, Telefon-Warteschleifen, Schlangen am Flughafen. Das klingt nach undefinierter Wartezeit, nach sinnlos vergeudeter Zeit, für die uns vermutlich tausend andere Dinge einfallen würden, die wir lieber täten. Der Mensch ist offensichtlich nicht für das Warten geschaffen.

Wir alle wissen aber, dass Warten und Geduld zu unserem Leben gehören. Schon in der Kindheit wird uns beigebracht, dass wir nicht “alleine auf der Welt sind” und dass es kein gutes Benehmen ist, sich vorzudrängen. Ja, weil die anderen auch warten müssen und das auch nicht gerne tun. 

• Aber ist Warten tatsächlich ein unvermeidbares Übel der Natur? 
• Und wenn dem so ist, warum regen wir uns darüber so auf?

Betrachten wir die Fragen mal im Einzelnen:

Ein wichtiger Teil unseres Menschseins ist Selbstbestimmtheit. Schon im frühen Kindesalter reagieren wir allergisch, wenn über uns Kontrolle ausgeübt wird. Wir wollen darüber bestimmen, wann wir was tun. Dieser Kontrolle werden wir durch Warteschleifen, Staus & Co beraubt. Das ärgert, frustriert und stresst uns. Und das noch verstärkt, wenn wir das Gefühl haben, dass wir den Grund für das Warten nicht kennen oder nicht verstehen.

Das führt uns zur zweiten Frage: Ist Warten ein unvermeidbares Übel der Natur?

Das Leben ist kein Ponyhof. Wenn es 2 Supermarktkassen gibt und 20 Kunden wollen gleichzeitig bezahlen, dann ist Warten unvermeidlich – zumindest für einen Teil der Kunden. 

Es sei denn, man würde das System anders organisieren: 

• Man könnte zum Beispiel eine Möglichkeit finden, Supermarktkassen flexibel zu skalieren. D.h. wie durch ein Wunder würden plötzlich 18 zusätzliche Supermarktkassen zur Verfügung stehen und alle Kunden könnten gleichzeitig bedient werden. Bei physischen Konstrukten ist das schwer vorstellbar, bei Software allerdings sehr wohl.
• Man könnte die 18 Kunden anders beschäftigen, sie z.B. auf einen Kaffee einladen. Damit würde die Zeit nicht als Wartezeit wahrgenommen werden.
• Man könnte schon frühzeitig dafür sorgen, dass nicht so viele Kunden gleichzeitig zur Kassa kommen. Z.B. indem sie vorher oder im Geschäft hingewiesen werden, dass die Kassen derzeit überfüllt sind. Die Kunden könnten dann nach andere Dinge erledigen und ersparen sich den Ärger des Wartens.

Zusammengefasst: Effiziente Ressourcen-Zuteilung ist eine inhärente Herausforderung von Systemen mit begrenzten Ressourcen. Wir alle kennen Systeme, wo dies besser gelingt und andere, wo Warten unvermeidlich erscheint. 

Im privaten Umfeld ist dies ärgerlich, im beruflichen Alltag ist dies aber ein fundamentales Problem, das massive Auswirkungen auf die Wettbewerbsfähigkeit von Unternehmen hat.

Betrachten wir die Situation in klassischen IT-Projekten:

Der Haupt-Produktivitätskiller sind Abhängigkeiten. Sie sorgen für Verzögerungen, Frustration und Qualitäts-Probleme: 

Wir wollen A lösen, brauchen dafür aber B, C und D. Blöderweise ist B in einer anderen Abteilung, C in einer anderen Firma und für D brauchen wir Genehmigungen von unserem Geschäftsführer, dem Papst und dem österreichischen Fussball-Teamchef. Also, schieben wir die Arbeit von A auf die Seite und beginnen mit U. Leider stellen wir aber nach kürzester Weise fest, dass wir dafür V, W und X benötigen. Und … richtig geraten: Auch das können wir nicht selber lösen, sondern brauchen dafür…

Jeder der in der IT arbeitet, wird relativ einfach die Buchstaben mit konkreten Tätigkeiten ersetzen können. Best of:

• Freischaltung der Firewall
• zur Verfügung stellen einer Testumgebung
• Detaillierte Erklärung von einem Sachkundigen, wie man Tool X richtig verwendet
• Einrichten von Zugriffsrechten
• Wissen, wo eine bestimmte Library zu finden ist
• Bestätigung von wem auch immer, dass diese Java-Klasse verändert werden darf
• usw

Wir wollen arbeiten, aber wir stehen gefühlt die meiste Zeit in langen Schlangen vor Supermarktkassen. Und die Supermarktkassen sind besetzt von Kollegen, die selber schon über alle Maßen genervt sind und uns daher sicher nicht sagen können, wann wir drankommen. Wenn es uns zu blöd wird, dann starten wir eine Eskalation. Damit gewinnen wir die Schlacht – und bekommen das, was wir wollen – aber wir alle verlieren den Krieg. 

Genau diese Problematik versuchen die Konzepte Lean und DevOps zu adressieren. Es geht dabei darum, bei Abläufen für jede der enthaltenen Tätigkeiten festzustellen:

1. ob diese Tätigkeiten einen Wert aus Sicht des Kundens generiert
2. Wieviel Zeit für jede dieser Tätigkeiten benötigt wird
3. wie oft diese Tätigkeit zu Problemen führt, die eine Nachbearbeitung erfordern

In Bezug auf das Ausgangsthema “Warten” möchte ich insbesondere den zweiten Punkt aufgreifen:

Wieviel Zeit wird für eine bestimmte Tätigkeit benötigt?

In diesem Zusammenhang ist es relevant, zwischen der Gesamt-Durchlaufzeit (“Lead time”) bzw. der Wertschöpfungszeit (“Value-added Time”) zu unterscheiden. Es kann nämlich eine Tätigkeit möglicherweise nur 10 Sekunden für die Erledigung in Anspruch nehmen, tatsächlich müssen wir aber 2 Monate auf diverse Inputs (z.B.Genehmigungen) warten. Wir arbeiten gefühlt immer weniger Zeit produktiv und warten immer mehr Zeit auf Inputs. 

Von Lean abgeleitet gibt es für IT-Abläufe mehrere Lösungsansätze:

• Kleine, schlanke Produkt-Teams mit hoher Kohäsion 

Wir können nicht alles alleine lösen! Aber je mehr wir zumindest innerhalb eines Teams lösen können, desto weniger Abhängigkeiten haben wir zu “entfernten” Personen. Wenn es auch – wie in SCRUM, Agile – gelingt dieses Team räumlich und atmosphärisch nahe zusammen zu bringen, dann werden Wartezeiten deutlich reduziert. 

DevOps erweitert dieses SCRUM-Prinzip durch das Inkludieren von unterschiedlichen Rollen innerhalb dieser Teams. Insbesondere sollten Entwicklung (Dev) und Betrieb (Ops) vertreten sein, aber je nach Priorität auch andere Rollen wie z.B. Architektur, Security, User-Interface-Designer, etc. Der Schlüssel ist einfacher, schneller Zugriff auf Personen, die wir kennen und im direkten Zugriff haben.

• Self-service Plattformen:

Aufgrund der – auch in SCRUM festgeschriebenen – Limitation von Team-Größen ist es allerdings unumgänglich, gewisses spezialisiertes Wissen zu bündeln. Diese werden in zentralisierten Teams organisiert, und sollen die Produkt-Teams in dem jeweiligen Themengebiet unterstützen. Um aber daraus nicht die oben beschriebenen problematischen Abhängigkeiten zu erzeugen, empfehlen sich automatisierte Self-service Plattformen, die das spezifische Know-how in einfach zu konsumierenden Services verpacken. 

Statt also für das Bereitstellen einer Testumgebung irgendwo ein Ticket erstellen zu müssen, dass dann manuell nach unbestimmter Zeit bearbeitet wird, sollten die Produkt-Teams hierfür ein Service zur Verfügung gestellt bekommen.

• loose gekoppelte Architekturen:

Dafür bekannt geworden sind Konzepte wie Service-orientierte Architekturen (SOA) bzw. Micro-Services-Architekturen, die auf System-Ebene versuchen aus einem großen Ganzen, kleine, kohäsive Komponenten zu schneiden. Diese Komponenten sollten möglichst wenig kommunizieren müssen und wenn dann nur über stabile, grob granulare Interaktionsmuster. Die Struktur und Regeln für diese Interaktionsmuster sind vertraglich festgehalten (=Application Programming Interfaces). 

Es gibt viele Beispiele, wo diese Ansätze die Wertschöpfung in der IT drastisch verbessert haben. Ganz ohne Warten wird es nicht gehen, aber wir sollten hinterfragen, ob es nicht alternative Lösungen gibt, die das Warten eliminieren oder zumindest reduzieren. Denn wir wir unter Druck stehen und auf eine Genehmigung ewig warten müssen, dann erzeugt das Stress beim Mitarbeiter und lähmt die Firma. Entschleunigung praktizieren wir wohl lieber in unserem nächsten Strand-Urlaub! Da warten wir gerne bei einem Sonnen-Untergang auf unseren nächsten Cocktail.