Shu Ha Ri ist eine beliebte Metapher, um über den agilen Reifegrad einer Organisation oder eines Scrum Teams zu sprechen. Leider mache ich immer wieder die Erfahrung, dass diese (eigentlich sehr hilfreiche) Metapher entweder unbekannt ist oder missverstanden wird. Deshalb möchte ich Dir hier die Bedeutung von Shu Ha Ri ein wenig näher bringen und Dir zeigen, wie Du das Konzept auf die agile Transformation Deiner Organisation so übertragen kannst, dass es auch hilfreich ist.
Der Ursprung von Shu Ha Ri
Shu Ha Ri soll vom Japaner Fuhaku Kawakami entwickelt worden sein. Er entlehnte das Konzept den Arbeiten von Zeami Motokiyo, einem Dramatiker des sogenannten No-Theaters, um es auf die Kampfkunst Aikido zu übertragen.
Shu Ha Ri hat also seinen Ursprung im traditionellen japanischen Theater.
Die Bedeutung von Shu Ha Ri
Schauen wir uns die einzelnen Stufen von Shu Ha Ri etwas genauer an, um die Grundidee dahinter besser zu verstehen.
Shu
Shu (守) ist die erste Stufe des Lernens und bedeutet so viel wie bewahren oder unterwerfen.
Es geht hier also darum, existierende Regeln und Prinzipien kennenzulernen und zu befolgen. Auf dieser Stufe eignen wir uns Grundlagenwissen an und erlernen erfolgserprobte Techniken.
Falls Du so wie ich in den 80er Jahren groß geworden bist, hast Du vielleicht auch den Film Karate Kid gesehen. Die bekannte Szene Auftragen, polieren, ist ein prima Beispiel für die erste Stufe von Shu Ha Ri.
Ha
Ha (破) ist die zweite Stufe des Lernens und bedeutet sinngemäß so viel wie befreien oder aufbrechen. Auf dieser Stufe haben wir die hinter einer Tätigkeit stehenden Prinzipien durch die Befolgung der Regeln aus der vorherigen Stufe verinnerlicht. Wir sind in der Lage, einen eigenen Stil zu entwickeln oder allgemeine Standards zu variieren.
Ri
Ri (離) ist die dritte und letzte Stufe des Lernens. Ri bedeutet so viel wie verlassen, trennen oder abschneiden. Wenn wir diese Phase erreicht haben, brechen wir also bewusst mit Traditionen, um neue Wege zu entdecken, die Prinzipien zu verwirklichen. Ri steht auch für die Verfeinerung existierender Techniken.
Shu Ha Ri ist ein umfassendes Konzept
Shu Ha Ri ist jedoch keine lineare Abfolge von Stufen, bei der die Dinge der vorherigen Stufen automatisch ungültig werden, sobald wir die nächste Stufe erklommen haben. Vielmehr handelt es sich um ein umfassendes Konzept. Deutlich wird das, wenn Du Dir Shu Ha Ri als konzentrische Kreise vorstellst.
Das bedeutet, dass Shu Teil von Ha ist und dass Shu und Ha Teil von Ri sind.
Auf der höchsten Stufe Ri ändert sich lediglich die Anwendung der zugrundeliegenden Prinzipien.
Bedeutung von Shu Ha Ri für agiles Arbeiten mit Scrum
Wenn wir das Konzept Shu Ha Ri auf die Arbeit mit Scrum übertragen, gibt es zwei wichtige Dinge, die wir daraus lernen können. Zum einen sollten wir uns davor hüten, Stufen zu überspringen. Und zum anderen sollten wir nicht vergessen, dass auch bei Erreichen der höchsten Stufe grundlegende Prinzipien immer noch gültig sind.
Überspringe nicht die Stufen!
Viele Organisationen trennen sich von Scrum, weil sie sich vom Regelwerk eingeschränkt fühlen, ohne es wirklich verstanden zu haben. Sie sind der Ansicht, dass sie “schon agil genug” wären und keine Stützräder mehr bräuchten. Sie glauben von sich, schon die Stufe Ri erreicht zu haben, befinden sich allerdings in Wirklichkeit auf der Stufe Shu.
Shu Ha Ri ist eine Erinnerung daran, dass wir zunächst lernen müssen zu gehen, bevor wir damit beginnen können, zu laufen.
Löse Dich nicht von Prinzipien, sondern von Techniken
Wenn Du der Meinung sein solltest, die höchste Stufe bereits erklommen zu haben, bedeutet das nicht, dass alles Vorherige ungültig ist. Die unterliegenden Prinzipien, die wir durch traditionelle Techniken verinnerlicht haben, sind (wie oben dargelegt) nach wie vor in Kraft.
Inkrementelles Arbeiten in Iterationen oder empirische Prozesskontrolle sind grundlegende Prinzipien, die auch auf der dritten und höchsten Stufe von Shu Ha Ri immer noch gültig sind. Das heißt, dass Du vielleicht neue Techniken entwickelst, um am Ende eines Sprints ein fertiges und nutzbares Increment zu liefern. Oder dass Du mit Deinem Team Aufwände nicht mehr mit Hilfe von Story Points schätzt. Oder eine neue Methode entwickelst, um Dein Product Backlog zu priorisieren.
Aber Du wirst die empirische Prozesskontrolle, iteratives Arbeiten und den Sinn einer Definition of Done nicht in Frage stellen.
