Radare zum Steuern komplexer Systeme – Navigieren statt Driften
Um komplexe Produkte zu bauen, braucht es Organisationen, die ihre eigene Komplexität konstruktiv nutzen können. Ein Merkmal komplexer Systeme ist jedoch, dass sie in ihrem Verhalten nicht eindeutig vorhersagbar sind. Dennoch müssen sie gesteuert werden, wenn man ein bestimmtes Ziel erreichen möchte. Für uns haben sich objektive und subjektive Radare als ausgezeichnete Navigationsinstrumente zur Steuerung bewährt.
Der Gedanke ist nicht neu: Ashby’s Law besagt, dass die Varietät des Systems, das ein komplexes System steuert, mindestens ebenso groß sein muss, wie die Varietät der auftretenden Störungen, damit es angemessen reagieren kann [1]. Es wurde bereits 1958 von W.R. Ashby formuliert und prägt seither die Kybernetik. Melvin Conway postulierte, dass die Produkte eines Unternehmens so gebaut sind, dass man dessen Organisationsstruktur darin wiederfinden kann [2]. All das deutet darauf hin, dass die Fähigkeit eines Unternehmens, mit seiner Organisationskomplexität wertschöpfend umzugehen, die Grundlage dafür ist, komplexe Produkte zu bauen und in einem dynamischen Umfeld dauerhaft zu existieren. Doch wie kann ein Unternehmen so aufgestellt sein, dass es der notwendigen Komplexität seiner Produkte gerecht wird und langfristig in einem sich verändernden Markt Wert für den Kunden erzeugt?
Nehmen wir zunächst ein Beispiel aus der nicht-komplexen Welt: Wenn mein Kühlschrank kaputt ist, brauche ich eine Vorstellung, wie er funktioniert, damit ich den Fehler finden und beheben kann. Wenn ich keine Ahnung von der Existenz von Temperaturfühlern oder der Wirkungsweise des Kompressors habe und die Zusammenhänge nicht verstehe, ist es eher zufällig bis unwahrscheinlich, dass ich angemessen handeln kann. Dabei ist das Systemverhalten eines Kühlschranks noch relativ überschaubar. Sein Aufbau ist möglicherweise kompliziert, aber wenn man genug Kenntnis davon hat, kann man dessen Verhalten vorhersagbar beschreiben.
Genau das kann man bei einem komplexen System nicht. Hier hat man viele Akteure im System, die selbständig handeln und gleichzeitig miteinander verbunden sind. Dadurch entstehen Rückkopplungseffekte, die wieder Einfluss auf das System haben. Wirklich vorhersagen kann man sein Verhaltensweise nicht. Aber man kann eine Modellvorstellung davon bekommen, welche Eingriffe welche Wirkung haben und durch eingebaute Feedbackschleifen diese Vorstellung kontinuierlich verfeinern, erweitern und anpassen.
Auf das Management komplexer Systeme übertragen bedeutet dies, dass man zum einen eine gute Vorstellung davon braucht, wie das System – in diesem Falle die Organisation und ihr Umfeld – reagieren sollte und überdies noch eine Menge Handlungsalternativen zur Verfügung haben muss, mit denen man das System beeinflussen kann.
Auch in den vergangenen Jahrzehnten wurden komplexe Produkte erschaffen und komplexe Projekte bewältigt. Doch durch die Globalisierung und den technischen Fortschritt erhöht sich die Anzahl der "Teilnehmer" am jeweiligen System immer weiter (z. B. durch neue Kunden, Wettbewerber, neue Technologien) und die Aktivität und die Vernetzungsdichte nehmen zu. Die steigende Dynamik erhöht den Zeitdruck und lässt die Vorhersagbarkeit sinken. Das Ausmaß an Komplexität, mit der Organisationen und Mitarbeiter umgehen müssen, überschreitet bereits jetzt vielfach die derzeitigen Bewältigungsmöglichkeiten. Und nichts deutet darauf hin, dass dies ein vorübergehender Prozess ist und die Komplexität wieder sinken wird.
Zentrale Entscheider-Instanzen limitieren die Komplexität, die bewältigt werden kann
Das ist ein wichtiges Argument für dezentrale Entscheidungsfindung in einer Organisation: Eine zentrale Entscheider-Instanz, die auf traditionelle Weise in der hierarchischen Linie Entscheidungen alleine oder im ausgewählten Führungsteam trifft, ist eine harte Limitierung des Potentials. Die mögliche Komplexität, die es zu bewältigen gilt, ist immer nur auf das Maß beschränkt, das diese Entscheider-Instanz selbst zu bewältigen vermag. Was nichts anderes bedeutet, als dass die gewohnten Hierarchien eine Organisation hinsichtlich des konstruktiven Umgangs mit Komplexität beschränken. Noch gravierender ist, dass die Komplexität, die die Führungsebene bewältigt, das Limit für die Organisation und ihre Produkte darstellt.
Das gilt sowohl für die Organisation selbst, als auch für ihre Interaktion mit ihrer Umwelt. Je komplexer die zu bewältigenden Aufgaben, je dynamischer das Marktumfeld, um so stärker die Einschränkungen. Eine plausible Lösung wäre, möglichst alle Köpfe des Unternehmens miteinzubeziehen und eine Struktur zu schaffen, die dies nicht nur fördert, sondern sich selbst dabei ständig verbessert. Keine Sorge, wir fordern hier nicht die sofortige Abschaffung aller Hierarchien. Es geht auch nicht darum, dass weitreichende Entscheidungen nicht in einer zentralen Instanz getroffen werden sollten. Wichtig ist vielmehr, wahrzunehmen, welche Einschränkungen es durch Hierarchien gibt und Wege zu finden, die Einschränkungen auf ein Minimum zu reduzieren und das im Unternehmen zur Verfügung stehende Wissen zur Wertschöpfung zu nutzen.
Dezentrale Entscheidungsfindung weckt besonders in sehr traditionellen Führungsebenen Ängste vor dem Versinken in Anarchie oder Chaos. Doch wenn das der Fall wäre, wäre es auch für die Komplexitätsbewältigung kontraproduktiv: Mit einem System, in dem jeder tun und lassen kann, was er möchte und Vorgaben nach eigenem Gutdünken interpretieren kann, erreicht man kein gemeinsames Ziel und generiert keine Werte, für die Kunden bezahlen. Systeme müssen dazu gesteuert werden. Um dies mit dezentraler Entscheidungsfindung zu organisieren, braucht ein System vor allem eine klare gemeinsame Ausrichtung, damit alle Köpfe in der Organisation sich in ihrem Handeln daran orientieren können. Aber das ist nur eine der Zutaten zum Kuchen, die Liste ist länger. Dazu gehören:
- Strukturen, die eine kontinuierliche gemeinsame Ausrichtung auf die Wertschöpfung in der Organisation ermöglichen,
- eine Modellvorstellung, wie das System reagiert, wenn man es steuert,
- Rückkopplungsmechanismen, die diese Vorstellung verfeinern helfen und
- eine große Bandbreite von Handlungsalternativen, mit denen man auf das System einwirken kann.
Das klingt schon nicht so einfach, doch unverzichtbar beim Kuchen ist das Backpulver, das dafür sorgt, dass der Teig nicht sitzen bleibt. Das Triebmittel in der Organisation ist der kontinuierliche Verbesserungsprozess. Weder die gemeinsame Ausrichtung noch die Modellvorstellung des Systems noch der Werkzeugkasten von Handlungsmöglichkeiten dürfen statisch sein. Sie müssen ständig nachgeschärft und ergänzt werden, denn die Welt, in der das System existiert, ist selbst auch nicht statisch. Die Ziele ändern sich, Einflussfaktoren auf das System ändern sich und die Erfahrungen im Umgang mit dem System wachsen.
Dieser Prozess sollte sich in der DNA der Organisation verankern, denn diese gemeinsame Ausrichtung muss nicht nur von allen mitentwickelt und getragen werden. Sie muss auch von allen Beteiligten ständig an das dynamische Marktumfeld angepasst werden. Die Frage: "Wo wollen wir hin?" wird begleitet von den Fragen "Welcher nächste Schritt könnte uns bei der Zielerreichung am besten helfen?" und "Was brauchen wir, um diesen Schritt gehen zu können?". Diese Vorgehensweise gilt für übergeordnete strategische Ziele genauso, wie für taktische Entscheidungen auf der Umsetzungsebene in jedem Bereich der Organisation.
Wie kann eine Organisation konstruktiv mit Komplexität umgehen?
Also lauten die zu lösenden Aufgaben:
- Wie kann man die gesamte Organisation auf ein gemeinsames Ziel ausrichten?
- Wie kann man die Komplexität der Organisation konstruktiv nutzen?
- Wie kann man diese Ausrichtung auf Wertschöpfung kontinuierlich anpassen?
- Wie bekommen die Mitarbeiter und Entscheider eine sich ständig aktualisierende Vorstellung davon, wie die Organisation als System reagiert, damit sie gesteuert werden kann?
Um einer Organisation diese Modellvorstellung über ihre inneren Vorgänge und ihr Umfeld bereitzustellen, sind ausgefeilte Navigationsinstrumente notwendig, die den Kompass für diese Reise bereitstellen. Bauchgefühle sind zwar hervorragende Frühwarnsysteme, doch nur in Kombination mit datenbasierten Rückkopplungsschleifen wird Blindflug verhindert [3]. Notwendig für jede datenbasierte Steuerung sind kontinuierlich erhobene Daten (Flowdaten), sowie subjektive und objektive Daten [4]. Wir schauen uns an dieser Stelle vor allem letztere an.
Was dabei in einem bestimmten Fall genau gemessen werden soll, wird durch das jeweilige Ziel und die Hypothesen zu seiner Zielerreichung definiert. Die Frage ist grundsätzlich: Welche Metrik hilft mir, eine passende und schnelle Information über die Auswirkungen meiner Entscheidung zu erhalten? Es geht nicht darum, möglichst viele Daten zu sammeln, sondern die aktuell wichtigen. Datenerhebung um der Datenerhebung willen ist Zeit- und Energieverschwendung. Wenn ein Unternehmen seine Time-to-market verbessern möchte, um Marktanteile zu sichern und dazu eine DevOps-Pipeline aufbauen möchte, sind vermutlich andere Dimensionen notwendig, als für eine Organisation, die in ein neues Marktsegment vorstoßen möchte und dazu ihre Mitarbeiter qualifizieren muss. Also müssen an das Ziel angepasste, aussagefähige Metriken her.
Wie kann diese Datengrundlage hergestellt werden?
Ein einfaches Beispiel: Eine Organisation hat das Ziel, effektiver zu arbeiten und nur noch wirklich wichtige Meetings durchzuführen (vgl. Abb. 2). Die Hypothese dahinter lautet, dass der schlechte Informationsfluss aus den Meetings heraus zur Folge hat, dass mehr Meetings abgehalten werden, als notwendig. Ein verbesserter Informationsfluss müsste demnach die Anzahl der Personenstunden in Meetings verringern. Das ließe sich dadurch messen, dass die Meetingstunden mit der jeweiligen Anzahl der Teilnehmer über eine gewisse Zeit notiert würden und man pro Maßnahme sehen könnte, ob sie eine Auswirkung auf die Messwerte hat.
Zunächst wird eine gemeinsame Vorstellung davon benötigt, was die Dimension "Informationsfluss verbessern" bedeutet. Daraus ergibt sich die Frage, mit welchen Maßnahmen sich der Informationsfluss aus den Meetings heraus verbessern lässt.
Gemeinsam wird ein einfaches Reifegradmodell für die Dimension "Informationsfluss verbessern" entwickelt [4]. Dieses gemeinsame Entwickeln hat zur Folge, dass sich ein Verständnis für die unterschiedlichen Perspektiven entwickelt, neue Ideen entstehen und man zu einer tragfähigen gemeinsamen Ausrichtung kommt. Diese Diskussionen sind dabei genauso wichtig wie das Ergebnis selbst. Ein Reifegradmodell beschreibt den mehrstufigen Entwicklungspfad für eine Dimension. Wie viele Stufen das jeweilige Modell haben soll, ist ebenso gemeinsam zu diskutieren, wie die genauen Inhalte der Stufen.
Ein Reifegradmodell könnte für die Dimension "Informationsfluss verbessern" möglicherweise so aussehen:
- Stufe 1:
- Agenda wird vor dem Meeting verschickt
- Ergebnisse werden zusammengefasst und nach dem Meeting verschickt
- Stufe 2:
- Ergebnisse werden transparent mitprotokolliert und mit Abschluss des Meetings an die Teilnehmer verschickt.
- Stufe 3:
- Alle dokumentierten Meeting-Ergebnisse werden bereichsweit in einem Tool veröffentlicht.
- Stufe 4:
- Alle Meetings des Bereichs werden zentral erfasst.
- Es wird bereichsweit veröffentlicht, wie viel Prozent der Meetings öffentlich dokumentiert wurden.
- Stufe 5:
- Alle wichtigen Meetings und ihre Ergebnisse werden zentral von einem Projektjournalisten dokumentiert.
Ein Reifegradmodell sollte sich mit allen Erfahrungen, die die Betroffenen damit machen, kontinuierlich weiterentwickeln und in gemeinsamer Diskussion angepasst werden. Wenn sich beispielsweise trotz Erreichen der Stufe 4 die Hypothese nicht bestätigt, sollte eine Ursachenanalyse Aufschluss darüber geben, was ein sinnvoller nächster Schritt zur Zielerreichung sein könnte. Vielleicht ist die mangelnde Informationsbereitstellung gar nicht die Ursache für die diagnostizierten Probleme? Vielleicht stehen noch immer nicht die richtigen Infos zur richtigen Zeit in der richtigen Art und Weise bereit?
In der Regel gibt es jedoch mehrere Dimensionen für ein Ziel. Das Ziel aus unserem Beispiel "Effektive Meetingkultur" könnte neben dem Informationsfluss auch Dimensionen wie "Struktur in den Meetings" oder "Vorbereitung der Meetings" haben. Reifegradmodelle für mehrere Dimensionen, die zu einem bestimmten Bereich gehören, werden in einem Radar abgebildet. Welche Dimensionen für wichtig befunden werden, muss der betroffene Bereich für sich selbst definieren. Input können dabei auch Forschung und Erfahrungswerte liefern. Dieser Prozess der gemeinsamen Ausrichtung, den wir mit "Alignment" bezeichnen, ist für die Zusammenarbeit und die gemeinsame Zielerreichung grundlegend.
Wenn wir Radare als Rückkopplungssensoren nutzen, um das komplexe Verhalten des Systems besser verstehen und steuern zu können, stellt sich auch die Frage, mit welcher Häufigkeit man welche Information abfragt, gewissermaßen die Abtastrate. Auch hier braucht man Modellvorstellungen, wann Rückmeldungen sinnvolle Ergebnisse bringen können und auch diese Modellvorstellungen müssen ständig an die Informationen der Realität angepasst werden.
Subjektive und objektive Radare
Radare können verschiedene Arten von Daten liefern. Für eine datenbasierte Steuerung des komplexen Systems liefern die unterschiedlichen Arten von Daten jeweils einen ganz eigenen Beitrag: Subjektive Radare fragen die persönliche Einschätzung der Situation ab. Wie sieht der einzelne Mitarbeiter die Lage, wie beurteilt er die Situation? Diese "weichen" Informationen sind wichtige Hinweisgeber, was wirklich im Unternehmen bei den Mitarbeitern ankommt und gelebt wird – aus der ganz persönlichen Perspektive jedes Beteiligten.
Objektive Radare basieren auf Hypothesen und Metriken und sind damit hervorragende Werkzeuge, um eine gemeinsame Ausrichtung zu finden. Sie hinterfragen: Was bringt uns diese Maßnahme bzw. wie zahlt sie auf unseren Geschäftszweck ein? Das angeführte Beispiel "Effektive Meetingkultur" mit Dimensionen wie "Informationsfluss verbessern" oder "Vorbereitung der Meetings" wäre ein objektiver Radar, dessen Ausrichtung und Dimensionen gemeinsam erarbeitet werden müssen und so ein gemeinsames Verständnis entsteht, was eine effektive Meetingkultur ist, welche Dimensionen dabei wichtig sind und welche Ausprägungen die Reifegradstufen haben.
Ein weiteres Beispiel aus dem Bereich Refinement, also der Klärungs- und Detaillierungsarbeit zu kommenden Anforderungen: Wenn es darum geht, zu messen, wie gut das Refinement funktioniert, erfordert die Erstellung eines Radars Diskussionen darüber, was Refinement für die Diskussionsteilnehmer überhaupt bedeutet. Und was bedeutet "gut funktionieren"? Was könnten mögliche Dimensionen dafür sein? Schon diese Diskussion zeigt die unterschiedlichen Standpunkte und Ideen, aus denen am Ende ein Radar entstehen wird, mit dem sich alle einverstanden erklären können und der kontinuierlich weiterentwickelt wird. Die Diskussion ist kein Selbstzweck, sondern basiert auf einem immer besseren gemeinsamen Verständnis, welche Geschäftsziele das Unternehmen verfolgt und wie ein besseres Refinement es dabei unterstützen könnte.
Dazu braucht das Team für jede Dimension grundsätzlich eine Hypothese, die es validieren kann und die mit den strategischen Zielen des Unternehmens abgestimmt ist. Es kann also nicht darum gehen, das Refinement zu verbessern, weil das vielleicht gerade jemand wichtig findet, sondern einen bestimmten Beitrag zum Geschäftszweck zu liefern. Wenn möglicherweise die Time-to-market verbessert werden soll, um die Kunden schneller zu beliefern und damit einen größeren Marktanteil zu gewinnen, könnte die zu überprüfende Hypothese beispielsweise lauten: "Wenn wir ein besseres Refinement haben, wird sich die Durchlaufzeit der Items um 30 Prozent verringern."
Wie entsteht ein Radar?
Radare werden immer mit mehreren Teilnehmern zusammen im Team entwickelt und angepasst. Wir verwenden dazu ein Workshop-Konzept mit mehreren kurzen Workshops (jeweils 60 Minuten) und Zwischenphasen, in denen die Arbeitsergebnisse reifen können. In einer sehr ähnlichen Struktur können auch das Ziel und erste Hypothesen erarbeitet werden [5]. In diesen kurzen Workshops wird mit hoher Energie am Radar gearbeitet, danach wirken die Ergebnisse noch nach und weitere Ideen können reifen, die im Folgeevent berücksichtigt werden. Bleiben wir bei unserem Beispiel und gehen davon aus, dass die Organisation das Ziel hat, eine effektive Meetingkultur zu etablieren.
Starter-Workshop (Timebox 60 Minuten)
In einem Starter-Workshop werden die Teilnehmer gebeten, innerhalb von z. B. fünf Minuten jeweils für sich auf Klebezettel aufzuschreiben, welche Aspekte ihrer Meinung nach auf das ausgewählte Ziel oder Problem einzahlen. Jeder Teilnehmer geht nach vorne und klebt seine Zettel an die Wand. Bei jedem Zettel erklärt er, warum er dieses Problem für wichtig hält. Diese Zettel werden gemeinsam diskutiert und dabei zu Kategorien zusammengefasst. Für jede Kategorie wird eine Überschrift gefunden. Das Ergebnis ist ein Affinitätsdiagramm [6], in dem die Kategorien die möglichen Dimensionen des späteren Radars darstellen. Das sieht im Ergebnis ganz ähnlich aus wie eine Story Map [7], nur dass keine Priorisierung erfolgt. Die Clusterung zeigt die Zusammenhänge, die im Cluster enthaltenen Items möglichen Stufe im Reifegradmodell (?). Das ist die erste Iteration des Radars.
Möglicherweise sind nach der Timebox noch nicht alle Dimensionen gefunden, vielleicht haben nicht alle Dimensionen die notwendigen Reifegrad-Stufen. Das ist völlig in Ordnung und auch beabsichtigt. Es geht nicht darum, einen perfekten Radar zu erarbeiten, sondern lediglich darum, kollaborativ ein Starter-Artefakt zu erstellen, das kontinuierlich weiterentwickelt wird. Das Starter-Artefakt sollte dennoch bereits der Organisation zur Verfügung gestellt werden, weil sich dann frühe innovative Nutzer damit auseinandersetzen und Rückmeldungen geben können.
Durch den Workshop werden intensive Denkprozesse in Gang gesetzt, die im Nachgang Ideen, Fragen und neue Gesichtspunkte aufkommen lassen, die in den Radar eingearbeitet werden müssen und seine Qualität sowie die gemeinsame Ausrichtung deutlich verbessern. Jeder neue Aspekt wird auf einem Zettel so festgehalten, dass er für die anderen Teilnehmer möglichst nachvollziehbar ist. Jeder Zettel wird zum nächsten Update-Event mitgebracht.
Update-Event (ca. 15 Minuten, täglich oder alle 2 Tage)
Die Beteiligten kommen zu einem kurzen Stand-up-Meeting vor dem Artefakt zusammen und besprechen alle Zettel, die in der Zwischenzeit erstellt wurden. Bei vielen neuen Ideen ist es sinnvoller, mehrere Stand-ups durchzuführen, als die Dauer zu verlängern. Durch die Diskussion wird ein Abgleich und Konsens erzielt und die Ergebnisse direkt in den Radar eingearbeitet, so dass das Artefakt den aktuellen Stand aller Teilnehmer widerspiegelt. Die Update-Events sind offen und werden transparent angekündigt, um allen, die Input geben möchten, die Möglichkeit dazu zu geben.
Wie kann ein Radar als Werkzeug für eine gemeinsame Ausrichtung dienen?
Diese Arbeit ist aufwändig und geht im Alltagsgeschäft der Organisation leicht unter, weil Organisationsentwicklungsmaßnahmen schnell von der Produktentwicklung kannibalisiert werden. Aufgrund der hohen Mitarbeiteranzahl und der großen Vernetzungsdichte in der Erstellung komplexer Produkte bewegen wir uns in der Regel im Bereich skalierter Agilität und verwenden im Folgenden Begriffe aus dem Scaled Agile Framework, dem derzeit weltweit am häufigsten eingesetzten agilen Skalierungsrahmenwerk [8].
In der Regel ist das LACE-Team (Lean Agile Center of Excellence) [9] oder eine Community of Practice (COP)[10] dafür verantwortlich. Dies bedeutet keinesfalls, dass sie die Besitzer der Radars sind. Doch dort wird ein Startpunkt gesetzt, beziehungsweise eine Art Produktverantwortung für die Radare übernommen. Das LACE-Team oder eine Community of Practice fungiert dabei eher wie ein Radar-Informationshub für alle Mitglieder des Unternehmens. Sie nehmen die Informationen auf, verarbeiten sie und stellen sie dem Unternehmen wieder zur Verfügung.
Ganz ähnlich wie bei agilen Methoden, die eine gemeinsame Ausrichtung erzeugen sollen (z. B. Planning Poker), werden die Aspekte für die Dimensionen gesammelt, die Argumente ausgetauscht und am Ende ein gemeinsames Verständnis und Ergebnis erzielt, das in diesem Radar ausgedrückt wird.
In einem skalierten Umfeld würden von den COPs oder dem LACE Team die Radare in einen Agile Release Train[11] oder in eine Large Solution mit mehreren Agilen Release Trains gehen und dort angewendet werden. Verbesserungsideen können direkt persönlich oder über Botschafter in die Update-Events eingebracht werden. Objektive Radare setzen in ihrer Ausführung reale Bezugspunkte, an denen man den aktuellen Status für den Bereich ablesen kann. Mit den jeweils vorliegenden Erfahrungen und Informationen werden sie in einem kontinuierlichen Verbesserungsprozess überarbeitet, weiter verbreitet und immer wieder verbessert und an die aktuellen Bedürfnisse angepasst.
Radare gehören keiner singulären Instanz, die ihren "Besitz" möglicherweise verteidigen würde. Wenn sie überhaupt einen Besitzer benötigen, dann wäre dies ein Organisationsbereich oder die Organisation selbst, in einer skalierten Umgebung wie zum Beispiel im Scaled Agile Framework der gesamte Agile Release Train oder eine Large Solution mit mehreren Agile Release Trains. Sicher aber braucht es eine Instanz, die sich für ihre Pflege und Weiterentwicklung verantwortlich fühlt, damit sie nützliche, aktuelle Werkzeuge bleiben. Wir verorten dies in einem LACE-Team oder in einer COP, die sie als Stewards betreuen.
Objektive und subjektive Radare liefern unterschiedliche Beiträge zum Ganzen
Neben den objektiven werden subjektive Radare analog eingesetzt, erfüllen aber einen anderen Zweck. Wollen objektive Radare die Datengrundlage für die gemeinsame Ausrichtung der ganzen Organisation oder eines Teilbereichs bieten, erfassen subjektive Radars die persönliche Ebene wie eine kurze Momentaufnahme. Sie erfragen das subjektive Erleben des Individuums. Dabei gibt es kein Richtig oder Falsch, sondern Ansichten, Meinungen, Einschätzungen und Perspektiven. Je nach vorherrschender Unternehmenskultur lassen sie sich mit Tools (z. B. Agility Health Radar, Crisp) [12, 13] auch anonymisiert erheben und auswerten.
Ein objektiver Radar im Bereich Vision könnte erfragen: "Gibt es eine Vision, die kommuniziert wurde?" mit Ausprägungen wie beispielsweise "Ja, es gibt eine irgendwo" oder auch "Ja, es gibt eine und sie wurde bestimmten Rollen kommuniziert" etc. Sie setzen reale Bezugspunkte und stellen kein Assessment persönlicher Meinungen dar. Ein subjektiver Radar erfasst, wie es den Mitarbeitern persönlich mit den einzelnen Dimensionen des objektiven Radars geht.
Zurück zum Beispiel Refinement: Wie könnte ein objektiver Radar an diesem Beispiel konkret aussehen? Eine mögliche Dimension auf einem objektiven Refinement Radar könnte beispielsweise die Zeit darstellen, die für den Refinement-Prozess in der Woche aufgewendet wird. Hier könnten die Stufen beispielsweise Ausprägungen von 0/30/60/90 Minuten etc. aufzeigen. Eine weitere Dimension wäre möglicherweise die Frage, ob es eine transparente Story Map gibt, die regelmäßig aktualisiert wird. In einem analogen subjektiven Radar geben die Mitarbeiter dann auf einer Skala von 1-10 an, wie es Ihnen mit den Story Maps geht. Die Antworten geben ausreichend grobe Anhaltspunkte, die der Startpunkt für genauere Erkundungen der Antwortursachen durch Gespräche sein können. Selbst detailliertere Erfassungsmethoden ersetzen unserer Erfahrung nach nicht die notwendige direkte Kommunikation zum genauen Verständnis der Antworten.
Beide Arten von Daten sind wichtig, doch es ist ratsam, grundsätzlich nicht auf objektive Radare zu verzichten und subjektive Radare als eine wichtige ergänzende Perspektive zu nutzen.
Strategische und taktische Radare
Bei der Steuerung komplexer Systeme bieten neben objektiven und subjektiven Radaren auch strategische und taktische Radare eine wichtige Navigationshilfe. Strategische Radare haben das große Ganze des Unternehmens im Blick. Sie fokussieren immer auf Aspekte der grundsätzlichen Ausrichtung einer Organisation, einer Large Solution oder eines Agilen Release Trains. Sie werden ebenfalls durch das LACE-Team konsolidiert und verwaltet. Ein Beispiel für einen strategischen Radar könnte die strategische Entscheidung sein, die Mitarbeiter selbst wählen zu lassen, wo sie arbeiten wollen und Heimarbeit (Remote Work) in der Organisation zu unterstützen.
Taktische Radare sind das klassische Werkzeug der Communities of Practice (CoP). Sie zahlen auf die strategischen Radare ein und setzen deren Ausrichtung praktisch um, damit sich diese auf den Geschäftszweck der Organisation auszahlen kann. Auch hier sind die CoPs nur die Verwalter, nicht die Besitzer, denn jeder Besitzer begrenzt seinen Besitz mit dem, was er in der Lage ist zu überschauen. Insofern ist es auch hier elementar wichtig, dass ein Radar nicht von irgendeiner Instanz vorgeschrieben wird, sondern dass alle Betroffenen den Radar "besitzen". Die verwaltende Instanz übernimmt das "Stewardship" und hilft lediglich, die Rückmeldungen und Ideen zu konsolidieren und einen kontinuierlichen Verbesserungsprozess in Gang zu halten.
In unserem Beispiel könnte es eine CoP "Remote Tools" geben, die die hilfreichsten Softwarelösungen am Markt für Remote Work auswählen. Eine weitere CoP könnte sich um Arbeitsmethoden kümmern, die die wertschöpfende und konstruktive Arbeit von verteilten Arbeitsplätzen unterstützen, wie z. B. die Pomodoro-Technik[14] oder Remote Pairing. Diese CoPs würden taktische Radare bereitstellen, die verschiedene Dimensionen der Remote Work in unterschiedliche Reifegradstufen abbilden. In der Dimension "Pomodoro-Technik" könnte man konzentriertes Arbeiten abseits des Büros in einzelnen Zeitscheiben alleine, zu zweit und im Team trainieren [15].
Zusammenfassung
Radare bieten einen hervorragenden Kompass für die Steuerung komplexer Systeme. Dabei hat jede Art von Radar seine spezifische Aufgabe bei ihrer Steuerung, wie Abb. 4 zeigt. Besonders objektive Radare leisten einen nicht zu unterschätzenden Beitrag zur gemeinsamen Ausrichtung einer Organisation oder eines Sub-Systems, da für ihre Entwicklung zunächst ein gemeinsames Verständnis des gemeinsamen Ziels notwendig ist. Die Dimensionen, die zur Zielerreichung wichtig sind und die einzelnen Schritte in Richtung dieses Ziels werden in einem transparenten Prozess gemeinsam gefunden, mit überprüfbaren Hypothesen ausgestattet und mit gemeinsam definierten Metriken überprüft und kontinuierlich verbessert.
Neben dieser gemeinsamen Ausrichtung auf ein Ziel hin bieten sie objektive Messdaten, die frühzeitige Rückmeldungen geben und als Rückkopplungsschleife die Steuerung eines komplexen Systems ermöglichen. Flankierend messen subjektive Radare das persönliche Erleben des Individuums und bieten die Möglichkeit, eine andere Perspektive auf die Situation der Organisation zu erhalten und diese Informationen in die Steuerung mit einfließen zu lassen.
Die Unterteilung nach strategischen und taktischen Radaren ermöglicht, gezielte Messinstrumente für die grundsätzliche strategische Ausrichtung des Systems und für die Qualität der Umsetzung der Strategie auszubilden. Die Steuerung komplexer Systeme benötigt schnelle Rückkopplungsschleifen aus allen Quadranten der Radarmatrix und es ist die Aufgabe des LACE-Teams, diese Radarlandschaft anzuregen, zu unterstützen, zu pflegen und zu verbessern. Das Problem ist nicht die stark ansteigende Komplexität selbst, sondern dass sich auf breiter Basis erst langsam die Werkzeuge für den nutzbringenden Umgang damit herausbilden. Noch verfügen Organisationen in der Breite nicht über ausreichend Methodenwissen und Erfahrung, um die immer weiter wachsende Komplexität konstruktiv zu nutzen, doch das wird sich in naher Zukunft durch die Dynamik der Märkte ändern. Übrig bleiben werden die, die es gelernt haben.
- W. R. Ashby; 1958: Requisite variety and its implications for the control of complex systems, Cybernetica 1:2, p. 83-99
- M. E. Conway; 1968: How Do Committees Invent? In: F. D. Thompson Publications, Inc. (Hrsg.): Datamation. Band 14, Nr. 5, April 1968, S. 28–31.
- P. Kruse; 2004: next practice. Erfolgreiches Management von Instabilität. GABAL; Auflage: 8
- S. Kainzbauer; W. Brandhuber; 2017: Eine Einführung in die Agile Organisationsentwicklung. Sigs Datacom eBook
- Informatik Aktuell – S. Kainzbauer; W. Brandhuber; 2017: Organisationsentwicklung mit Agile Organizational Moves
- K. Courage; K. Baxter; 2005: Understanding Your Users / A Practical Guide to User Requirements Methods, Tools, and Techniques. Elsevier Inc.
- J. Patton; 2014: User Story Mapping: Discover the Whole Story, Build the Right Product. O'Reilly
- Scaled Agile Framework (SAFe)
- Scaled Agile Framework: Create a Lean-Agile Center of Excellence
- E. Wenger; R. A. McDermott; W. Snyder; 2002: Communities of Practice: A Guide to Managing Knowledge
- Scaled Agile Framework: Agile Release Train
- Agility Health Radar
- Crisp
- F. Cirillo: Pomodoro Technique
- Informatik Aktuell – S. Kainzbauer; W. Brandhuber; M. Bugueno; 2015: Agile Moves: Einzeltraining für Teamkämpfer
