Idee Nr. 1 ist also:
Miss nicht Agilität, sondern, wie gut du deine Ziele erreichst. Ziele können Optimierung bzgl. deiner KPIs sein oder eine bessere Ökobilanz oder glücklichere Mitarbeiter oder einfach mehr Geld verdienen.
Abb1: Agilität nicht messen!
Gehen wir jetzt erst einmal davon aus, dass wir wissen, was unsere Ziele sind. Und wie wir messen, ob wir ihnen näher kommen oder nicht.
Mappe dein Verhalten auf deine Ziele
Das ist Idee Nr. 2:
Dein Verhalten, also was deine Organisation macht, welchen Prozessen sie folgt usw., das sollte ja in irgendeiner Beziehung stehen zu deinen Zielen.
John Cutler hat kürzlich über ein „Random Ticket Game“ geschrieben, wo er jedes beliebige Ticket in deinem Issue Tracker (z.B. JIRA, Mantis oder Redmine) auf die Ziele des Unternehmens mappen will. Ich finde, wir können diesen Gedanken noch einen Schritt weitertreiben, wir können auch die Art, wie wir Dinge tun, auf unsere Unternehmensziele mappen. Etwa unsere Prozesse, unsere Art, Entscheidungen zu treffen, unsere Art, zu kommunizieren usw.
Die „Gretchen-Frage“ ist dann einfach: Hilft uns das, unsere Ziele besser zu erreichen? Hilft uns z.B. ein zentralisierter Entscheidungsprozess der Budgetvergabe, bei dem ein Mal pro Quartal getagt und entschieden wird, unsere Produkte schneller auf dem Markt zu bringen als die Konkurrenz? Vermutlich nicht.
Hilft uns ein tägliches Synchronisieren und Update im Team (wir machen das 15 Minuten im Stehen vor dem Task-Board), schneller bessere Ergebnisse zu erzielen? Vermutlich schon.
Cutler schlägt beim „Random Ticket Game“ vor, das Mapping sogar mit Schätzungen auszustatten: Die Standups bringen uns 2.3 Mal bessere Ergebnisse. Schwierig zu schätzen und schwierig zu messen. Aber sinnvoller, als zu sagen: Wir machen Standups, weil Scrum es vorschreibt.
Abb2: Wenn ich höre „Das ist nicht agil“, stirbt eine Elfe!
So kommen wir auch wunderbar weit weg von der unsinnigen Diskussion: Ist X agil?! Wieso ist es wichtig, ob X agile ist oder nicht? Wichtig ist, ob es uns hilft oder nicht.
Nie wieder: Das ist agil vs. das ist nicht agil
Das ist Idee Nr. 3:
Redet nie wieder darüber, ob etwas agil ist oder nicht. Aus. Ende. Nie wieder. Wie oft habe ich Diskussionen beigewohnt, in denen jemand sagte „Das ist dann aber nicht agil“. Oh weh, ich habe das früher selbst so gesagt. Als sei das ein Argument?! Oder „Machen wir es so, das ist Agil“. Als sei das ein Argument?! Oder noch schöner: „Wenn du das machst, ist es nicht Scrum“. Als sei das ein Argument?! Wenn wir etwas nur tun, weil Scrum es uns sagt, dann haben wir das Zentralste am sinnvollen (agilen;) Vorgehen vergessen: Prüfen und anpassen (Inspect & Adapt). Mach Dinge, weil sie einen Effekt und Sinn haben – gemessen an der Realität.
Abb3: Shu Ha Ri
Die Shu-Ha-Ri-Verfechter werden uns jetzt sagen: Halt, Leute, ihr müsst Scrum erst buchstabengetreu befolgen, bevor ihr es ändern dürft. Weil ihr ja erst einmal lernen müsst, wie Scrum funktioniert! Und ich glaube nicht, dass das falsch ist. Ich glaube aber, es ist besser, in einer Retro rauszufinden, dass man anscheinend doch einen Daily Standup braucht, als einen Daily Standup zu machen (weil man das halt macht), bei dem alle sich nur erzählen: Ich habe gestern brav gearbeitet und ich werde heute auch brav arbeiten. Denn das bringt uns sicher keinen Millimeter näher an unsere Ziele heran.
