Shuhari (und Harikiri)

Grafik: Wikimedia Commons/Jossi - CC0 1.0

Ich weiß nicht ob es an Hirotaka Takeuchi und Ikujiro Nonaka liegt, aber in Teilen der agilen Szene sind japanische Begriffe beliebt geworden. Kanban, Kaizen und Kata gehören dazu, aber auch ein anderer, den ich in letzter Zeit in vielen Diskussionen wiedergefunden habe: Shuhari (auch Shu-Ha-Ri, 守破離). Vereinfacht gesagt verbirgt sich dahinter ein aus dem Aikido stammendes Lernkonzept, das dem Vernehmen nach von Alistair Cockburn in die IT übernommen wurde und aus drei namensgebenden Stufen besteht:

1. Shu (守): Das Erlernen der Regeln
Auch beschrieben als die Phase des Lernenden. Hier werden die bereits bestehenden Regeln befolgt und verinnerlicht - und zwar nicht "weil der Chef das befohlen hat" oder "weil man das immer so macht" sondern um zu erfahren, zu verstehen und den Sinn darin zu erkennen.

2. Ha (破): Der Bruch mit den Regeln
Auch beschrieben als die Phase des Meisters. Im Bewußtsein der Folgen und Konsequenzen kann man versuchen die Regeln zu variieren und dadurch zu verbessern, so dass sie ihren Sinn noch besser erfüllen.
3. Ri (離): Das Überwinden der Regeln
Auch beschrieben als die Phase des Großmeisters. Wichtig ist nur noch der Sinn der hinter allem steht. Da er umfassend verstanden und durchdrungen wurde, sind Regeln nicht mehr notwendig, weil ohnehin nur noch so gehandelt wird wie er es erfordert.

Von Cockburn war Shuhari ursprünglich angedacht um das Erlernen von Programmiertechniken zu optimieren, mittlerweile empfehlen viele Coaches dieses Vorgehen aber auch beim Erlernen agiler Methodiken. Gerade im Fall von Scrum, das eine Vielzahl von Regeln aufweisen kann, deren Sinn sich nicht immer sofort erschließt, ist es sehr naheliegend. Im Normalfall folgt hier nämlich auf die Einführung eine Phase der Unsicherheit, in der Vieles nur halbherzig oder noch nicht richtig umgesetzt wird und der Nutzen deshalb noch nicht erkennbar ist. Das führt zum Hinterfragen der unverstandenen und als sinnlos empfundenen Prozesse und Artefakte, und oft zum Wunsch sie "an die Bedüfnisse anzupassen" oder gleich abzuschaffen.

Wird nach die Methoden-Einführung eine Shu-Phase gelegt, kann diese dazu beitragen das Team von derartigen gut gemeinten, in der Konsequenz aber verheerenden Fehlern abzuhalten. Die optimale Länge dieser Phase ist zwar nicht definiert, es dürfte aber unstrittig sein, dass sie mehrere Sprints andauern sollte¹. Wenn auf der anderen Seite Teams kurz nach dem Einführungsworkshop alleine gelassen werden, neigen sie erfahrungsgemäß zu einem Verhalten, dass ich gerne als "Harikiri" bezeichne (zusammengesetzt aus den Phasen Ha und Ri und dem Harakiri). Gemeint ist damit ein versehentlicher "Selbstmord" der Scrum Methodik durch den Versuch, gleich zu Projektbeginn Verbesserungen vorzunehmen. Wenn dabei zentrale Elemente wie z.B. der Sprint, die Retrospektive oder die Rolle des Product Owners abgeschafft oder verschlimmbessert werden, dann können Blockaden, Ineffizienz oder permanente Konflikte die Folge sein.

Immerhin eines ist dabei aber positiv hervorzuheben - anders als der echte Harakiri hat der Harikiri nicht das dauerhafte Ableben zur Folge. Die gemachten Fehler lassen sich durchaus korrigieren, sei es durch eine (späte) Selbsterkenntnis des Teams oder durch externes Coaching. Da diese Kurskorrektur aber mit dem Eingeständnis verbunden ist Fehler gemacht zu haben, kann sie für manche Teams eine schmerzliche Prozedur sein, die man sich durch eine vorgelagerte Shu-Phase hätte ersparen können.


¹Ich kenne Scrum Master die in dieser Zeit mehere aufeinanderfolgende einwöchige Sprints ansetzen, um die Frequenz und damit den Lerneffekt zu erhöhen. Ich sehe das eher kritisch, weil so kurze Abschnitte sehr hohe Meeting-Anteile haben, was erfahrungsgemäß zu Abwehrreaktionen der Teammitglieder führt.