Bei Agilität denken die meisten an Kanban oder Scrum auf Ebene der Teams. Und dann natürlich an die vielen Skalierungs-Frameworks wie LeSS, SAFe, DAD oder Nexus. In erster Linie adressieren diese Frameworks die Frage, wie die Arbeit von mehreren oder vielen Teams an einem oder mehreren Produkten koordiniert und synchronisiert werden kann. Gerade in gewachsenen IT-Landschaften mit vielen Abhängigkeiten eine berechtigte und oft gestellte Frage, die leider oft die viel wichtigere Frage nach der Entkopplung verdrängt, aber das ist eine andere Geschichte. Hier soll es nun eher um die Frage gehen, wie man agilen Organisationen auf verschiedenen Flughöhen mit entsprechenden Planungshorizonten Orientierung geben kann. Und darum, dass dabei Strategie immer ein leerer Handlungsrahmen bleiben muss der von unten nach oben mit Inhalt gefüllt wird.
Klaus Leopold, der den Begriff der verschiedenen Flughöhen geprägt hat, unterscheidet drei Verbesserungsebenen der Organisation. Auf der operativen Ebene arbeiten die einzelnen Teams nach ihren jeweiligen agilen Methoden (bei Klaus sicherlich eher Kanban als Scrum, aber das spielt hier keine Rolle). Auf der Ebene darüber findet die notwendige Koordination zwischen den Teams und Produkten statt, um gemeinsam einen Wert für den Kunden zu generieren. Und auf der strategischen Ebenen ganz oben wird die grobe Richtung für alle festgelegt. In etwa so wie in dem Bild.

Diese Ebenen entsprechen unterschiedlichen Planungshorizonten. Auf der obersten Ebene werden die strategischen Ziele für die nächsten Monate festgelegt während auf der operativen Ebene der Teams in Sprints von wenigen Wochen Beiträge zu diesen Zielen geliefert werden, die durch die mittlere Ebene koordiniert ein stimmiges und nützliches Ganzes ergeben. Alle Ebenen haben also einen agilen Rhythmus, aber entsprechend ihrem Planungshorizonten sind die Zyklen unterschiedlich lange.
Ganz ohne Hierarchie kommt Agilität in diesem Sinne also nicht aus. Im Gegenteil werden agile Teams in ihrer Selbstorganisation ja erst durch diese gemeinsame Ausrichtung effektiv und schlagkräftig. Jede (neue) Hierarchie hat aber gerade im Zuge einer Transformation einer hierarchischen Organisation in eine agile seine Tücken. Sie kann auch missverstanden oder bewusst missbraucht werden.
Ziel ist es eben gerade nicht, von oben nach unten Aufträge zur Ausführung zu geben. Ziel ist es, der Autonomie Orientierung zu geben. Und das setzt voraus, dass zwar die grobe Richtung von oben nach unten vorgegeben wird, aber die Details was und wie genau und in in welcher Reihenfolge getan werden sollte von unten nach oben hinzukommen. Die Strategie bildet einen leeren Handlungsraum begrenzt durch gemeinsam entwickelte emergente Prinzipien der Zusammenarbeit, den die Teams selbstorganisiert mit Inhalten zur Zielerreichung füllen.
Strategie ist ein zunächst leerer Handlungsraum, begrenzt durch Prinzipien. Er wird für den unbekannten Teil des Weges benötigt. Für den bekannten Teil genügt ein Plan, gebildet aus Regeln.
Gerhard Wohland
4 Kommentare
Die Beschreibung von G. Wohland ist (wie meist immer ‚-)) sehr treffend. ! Es geht auch darum bei einer Strategie festzulegen was man eben nicht tun soll, welche Pfade nicht beschritten werden sollen. Wenn das einmal klar wird, kann man Die Strategie mit Inhalten füllen..
Interessant für mich der Umsetzungsvorschlag von Leopold. Sehr guter Artikel.…
Vielen Dank! Freut mich sehr. Vielleicht geht es wirklich eher darum Grenzen zu setzen und größten Freiraum zu lassen.
Hallo Marcus, was hälst Du vom Ansatz Hoshin Kanri? Ist das Deines Erachtens eine Antwort auf zielführende Orientierung im Agilen Kontext?
Hallo Steffen, bisher habe ich mich nur mit Objectives & Key-Results auseinandergesetzt und angewendet. Hoshin Kanri steht auf meiner Liste, hatte aber bisher noch keine Zeit es mir genauer anzusehen. Irgendwelche Tipps dazu?