Kanarienvögel

Bild: Pixabay / jrperes - Lizenz

In der englischen Sprache gibt es die Redewendung des "Canary in a coal mine", also des Kanarienvogels im Kohlebergwerk. Hintergrund ist das bis in das 20. Jahrhundert übliche Vorgehen, solche Vögel mit unter Tage zu nehmen. Wenn in den Stollen Gase austraten oder die Luft zu kohlensäurehaltig wurde starb zuerst der auf viel Sauerstoff angewiesene Vogel, den Menschen blieb meistens noch genug Zeit um zu flüchten. Abgeleitet davon wird der Begriff des Canary in a coal mine auf alle Regeln und Praktiken angewandt, deren Verschwinden ein starker Indikator dafür ist, dass deutliche Verschlechterungen unmittelbar bevorstehen.

Auch im Kontext agiler Transitionen gibt es Kanarienvögel, deren Verschwinden ein deutliches Signal eines kommenden oder bereits stattfindenden Rollbacks sein kann. Wenn festzustellen ist, dass sie schwächer werden oder sogar ihr Leben aushauchen ist es Zeit das Weite zu suchen oder (um die Analogie weiterzutreiben) für einen neuen Zufluss frischer Luft zu sorgen, mit dem die Transition wiederbelebt wird. Zu den agilen Kanarienvögeln gehören:

Die Ausgestaltung des Scrum Masters als Vollzeitstelle

Jedem der diesen Job (oder den eines Kanban-Delivery Managers) einmal ausgeübt hat ist es klar, dass er anders als in Vollzeit gar nicht auszuüben ist. Eher noch ist es so, dass die zahlreichen Tätigkeiten im Dienst des Teams, des Product Owners und der Organisation in Überstunden ausarten oder in das Privatleben hineinwuchern können. Das zu beschneiden kann nur Dysfunktionen zur Folge haben, mit dem häufigen ersten Ergebnis, dass der ständige Anpassungs- und Verbesserungsprozess zum Erliegen kommt, da seine Stimulierung im engen Zeitplan wegpriorisiert wird. Und oft beginnen die Probleme damit erst, zum Beispiel dann wenn ein Teilzeit-Scrum Master mit einem Teilzeit-Product Owner kombiniert wird.

Das Recht der Teams, Akzeptanzkriterien und Definition of Done frei zu definieren

Ein massiver Eingriff in die Selbstorganisation der Teams liegt vor wenn versucht wird, übergreifende "Qualitätsstandards" einzuführen. Zum einen weil diese, "um auf Nummer sicher zu gehen", die Tendenz haben unnötig detailliert-bevormundend zu sein und damit fast zwangsläufig zur Entstehung einer übergreifenden, regulierenden und kontrollierenden Bürokratieschicht führen, zum anderen weil sie aufgrund der Vielzahl der Betroffenen und Verantwortlichen nur noch sehr langsam zu ändern sind, selbst wenn die Rahmenbedingungen sich schon längst geändert haben.

Die von Team zu Team unterschiedliche Bedeutung von Story Points

Einer der großen Klassiker fehlgeleiteter Management-Bemühungen. So nachvollziehbar es ist, teamübergreifende Planzahlen haben zu wollen, so schädlich ist es auf der anderen Seite sie zu erzwingen. Das führt nämlich nicht nur zu einer festen Umrechnung in Stunden oder Personentage (alleine das wäre bereits schlimm genug), es erzeugt für viele Manager auch die große Versuchung, diesen Wert "optimieren" zu wollen, mit all dem unrealistischen Erwartungs-, Kontroll- und Erzwingungs-Overhead der damit verbunden ist.

Die direkten Feedbacks von Benutzern und Stakeholdern an das Entwicklungsteam

Ohne direkte Rückmeldung von den Anwendern und Auftraggebern wird jedes Team permanent mit dem erheblichen Risiko leben müssen, am Markt vorbei zu produzieren. Wird dieses Feedback in Management-Runden, Kommittees oder vorgelagerte Fachabteilungen verlagert, sind "Stille Post-Effekte" die Folge, durch die die Rückmeldungen nur noch verzerrt, verfälscht oder reduziert bei dem Entwicklungsteam ankommen. Auch Rückfragen und Austausch sind dann nur noch verlangsamt möglich, wodurch neben der Bedarfsgerechtheit auch die Reaktionsgeschwindigkeit abnimmt.

Der Framework-Charakter von Scrum, Kanban & Co.

Dass Scrum viele Bereiche der Umsetzung wenig bis gar nicht reguliert ist volle Absicht und soll verhindern, dass zu detaillierte Vorgaben im Einzelfall nicht mehr anwendbar sind. Auch auf XP und Lean Startup trifft das zu, und Kanban hat als "open Source Methode" überhaupt kein offizielles Regelwerk. Wird um diese Ansätze herum eines der üblichen, verpflichtend zu befolgenden Prozesshandbücher verfasst, treten verschiedene Folgen auf: zum einen kann eine zu umfangreiche Stoffmenge nicht mehr in das kollektive Gedächtnis der Organisation übergehen und gerät dadurch schnell in Vergessenheit, zum anderen regt das Vorhandensein optionaler Regeln zu permanenten Sinnfragen an und damit auch Anpassungsfähigkeit und -bereitschaft. Umgekehrt geht diese zurück wenn Regeln zu einengend und detailliert sind.

---

Was allen diesen Punkten (und einigen weiteren) gemeinsam ist: sie wirken auf den ersten Blick wie nachrangige Faktoren, an denen man relativ risikolos herumhantieren kann. Wie gesagt, auf den ersten Blick. Auf den zweiten zeigt sich, dass sie alle mit der Fähigkeit eines Teams und einer Organisation in Verbindung stehen flexibel und reaktionsschnell (also agil) zu sein. Werden an ihnen trotzdem Verschlimmbesserungen durchgeführt zeigt das, dass einige für die agile Transition bedeutsame Zusammenhänge nicht erkannt (oder bewusst ignoriert) werden. Vor diesem Hintergrund sind sie als Canary in a coal mine besonders geeignet.