“Die Leute in diesem Startup sind derartig *busy*, dass sie sich nicht mal die Zeit nehmen, ein Glas Wasser zu trinken! Was kann man dagegen tun?”

Alle zu einem Achtsamkeits-Workshop schicken? Verpflichtende Trinkpausen einführen? Mit ihnen darüber reden, dass überhastetes Arbeiten die Fehlerquote erhöht?

Spaß beiseite, gesund ist dieser Zustand jedenfalls nicht – weder für die betroffenen Teammitglieder, noch für die gesamte Organisation, die auf ihre Arbeitsergebnisse angewiesen ist.

Neulich hatte ich Ihnen dieses stark vereinfachte Modell eines Software-Lieferprozesses präsentiert, eine einfache Box:

Links fließt Arbeit in die Box hinein, innerhalb des Prozesses werden die einzelnen Tickets (User Stories, Change Requests o.ä.) bearbeitet, und schließlich verlässt die “fertige” Arbeit das System wieder.

Wir waren uns (hoffentlich) einig, dass mittel- und langfristig die Zuflussrate kleiner sein muss als die Abarbeitungsrate. Ich deute die oben angesprochene extreme Geschäftigkeit als Symptom der Überlastung (zugegeben, es ist eine Ferndiagnose): Es wird dauerhaft mehr Arbeit angenommen, als bewältigt werden kann. Das führt zu ständigem Getriebensein, Verfehlen von Terminzusagen, schlechter Qualität, Stress, Burnout usw. Es gehört eben zur Wissensarbeit, dass es immer mehr zu tun gibt, als man realistischerweise abarbeiten kann.

Die meisten “Tipps & Tricks”, die man so lesen kann, beziehen sich auf den Raum innerhalb der Box: bessere Retrospektive machen, cleverer beim Code Review sein, User Stories nach Schema F schreiben – all das hilft, die Abarbeitungsrate zu steigern.

Nur nützt das oft nichts, wenn die Zuflussrate an neuer Arbeit nicht begrenzt wird, gelegentliche Steigerungen der Abarbeitungsrate führen dann nur zu Steigerungen beim Zufluss. Das Überlastungsproblem bleibt damit stabil.

Warum wird der Zufluss so selten bewusst gesteuert?

Ich denke, die Argumente für die Begrenzung des Zuflusses liegen auf der Hand, also muss es tiefere Ursachen geben, warum es so selten geschieht.

Geht nicht gibt’s nicht. Wer Aufgaben ablehnt, egal mit welcher Begründung, ist kein Teamplayer, hat keine ausreichende Motivation, glaubt nicht an die Sache usw.

Der Kompetenzbereich der “Prozessverbesserer” (z.B. Scrum Master) beginnt erst nach dem Zufluss. Im Idealbild von Scrum nimmt sich das Team natürlich gerade so viel vor, wie es innerhalb eines Sprints schaffen kann. Wenn Scrum gut funktioniert, gibt es also eine Begrenzung des Zuflusses. In der Realität wird die Arbeit innerhalb eines Sprints oft nicht geschafft. Dann muss man eben die Schätz-Skills oder andere “Best Practices” des Teams verbessern – der Fokus und fast der gesamte Werkzeugkasten des Scrum Masters richtet sich auf die Abarbeitungsrate.

Steuerung via Auslastung. Einige Führungskräfte sehen den Software-Lieferprozess als Black Box – wenn man Druck ausübt, passiert etwas (sonst nicht). Also lieber etwas mehr Druck ausüben als zu wenig. Wenn man immer für genug Nachschub bei der Arbeit und “Motivation” sorgt, kann kein Leerlauf aufkommen. Erst, wenn die Auslastung offensichtlich nicht mehr zu steigern ist, kann der Druck etwas nachlassen.

Management-Glaubenssätze. Außerdem gibt es “Parkinson’s Law”, das besagt, dass die Arbeit sich immer soweit ausdehnt, bis sie die zur Verfügung gestellte Zeit ausfüllt. Also lieber weniger Zeit zur Verfügung stellen. In dieselbe Richtung geht die “80/20-Regel” (Pareto-Prinzip) – 80% des Nutzens lassen sich mit 20% des Aufwandes erzielen. Wer als Führungskraft die Deadlines knapp bemisst, vermeidet also, dass die Leute unnötigen Aufwand treiben.

Verzicht und Abwägung sind mühsam. Der bewusste Verzicht (auf Features, Extras, Umsätze) und das Abwägen zwischen Alternativen im Angesicht begrenzter Kapazitäten kann unangenehm werden. Man muss sich mit der eigentlichen Arbeit inhaltlich auseinandersetzen, allgemeine “Leadership Skills” reichen nicht aus.

Ich bin sehr dafür, die Abarbeitungsrate zu steigern – nur sollte man den Zufluss nicht vernachlässigen.

Matthias Berth