Work theatre in agile development

Manchmal liest man einen Text, in dem ein vages Gefühl, das man lange hatte gut formuliert und auf den Punkt gebracht wird. Auf einmal entsteht ein klarer Gedanke. So ging es mir mit dieser netten Kolumne: "Performative Work". Bei einem Kunden konnte ich das einmal in voller Pracht beobachten. Der Typ, der immer telefoniert. Die andere, die immer mit einem Stapel unter dem Arm irgendwohin unterwegs ist. So war das früher. Die schaffen was, das sieht man doch!

Heute sind es wie im Artikel beschrieben diejenigen, deren farbiger Präsenz-Buppel in der Teams-Liste nur zwischen grün und rot hin und herspringt und garantiert niemals gelb oder (Gott bewahre!) grau wird. Diejenigen, die immer die Meetings eröffnen. Die Aufgaben in möglichst winzige Teilaufgaben zerlegen, damit der Abarbeitungs-Fluss stattlicher wirkt. Hauptsache, das Ticket ist "erledigt", auch wenn man nur die Hintergrundfarbe einer Schaltfläche geändert hat.

Entscheidend ist dabei die Größe des Teams. In kleinen Teams, sagen wir, maximal 5 Personen, funktioniert es nicht, weil jeder weiß, was die anderen machen. Darüber hinaus verliert man den Überblick, egal wieviel Dailys es gibt. Da können die virtuellen Aktenköfferchen geschwungen werden. Und so vergeht ein merklicher Teil der Arbeitszeit in Meta-Arbeit, deren ausschließliche Aufgabe es ist, Arbeit auch nach Arbeit aussehen zu lassen. Jeder formuliert präzise sein Tagewerk, zeigt vollendete Tasks und benennt offene Zuarbeiten. Warum funktioniert das Projekt trotzdem nicht? Warum dauert alles immer viel zu lang? Es kann ja nur an denjenigen liegen, die im Daily nicht perfekt vorbereitet sind, deren Technik im Moment des Sprechens spinnt oder die deklarieren, mit einer Task nicht rechtzeitig fertiggeworden zu sein weil, äh,.. zu komplex (Höchststrafe).

Ich sehe einen organisatorischen Überbau in größeren Teams dabei nicht unbedingt negativ. Es ist notwendig dass jemand, der nicht aktiv bis ganz unten eingebunden ist einen Gesamtüberblick behält und Arbeit in kritischen Fällen umverteilen kann. Einer, der offene Fragen schnell aus dem Weg räumt. Kurios ist aber die Eigendynamik, die so etwas zwangsläufig zu erhalten scheint, sobald man diesen Prozeß formalisiert.

Es verhindert auch ein Vorarbeiten bei Unterbelastung. Warum schon Tickets aus dem nächsten Sprint angehen? Das hebt nur die Erwartung des Sprint Masters und man bekommt in der nächsten Iteration mehr zu tun. Das wiederum erhöht die Gefahr der Verfehlung des Sprint-Ziels, des Leistungsmaßstabs des Sprint Masters gegenüber seinen Vorgesetzten.
Bizarrerweise gibt dieser nun selbst dieses Ziel vor. Wird es verfehlt, ist er also doppelt unfähig: Weder kann er aus seinen Leuten die passende Leistung herausholen, noch ihre Möglichkeiten richtig einschätzen. Dementsprechend reagiert er in kritischen Situationen extrem dünnhäutig und ist inhaltlich von der korrekten Präsentation der jeweiligen Arbeitsabschnitte getrieben.

Diese Logik verfolgen auch die Mitarbeiter, die, an ihren abgeschlossenen Tasks gemessen, die Abarbeitung derselben perfektionieren. Seht her, liebe Kollegen, das alles ist seit gestern von "Active" über "Review" nach "Done" geflossen. Genial, oder? Wie in einer Simulation eines Arbeitsablaufs ohne Störungen. Eine Inszenierung. Performance. Performative Work!