Gebraucht der Zeit, sie geht so schnell von hinnen, doch Ordnung lehrt Euch Zeit gewinnen. – Johann Wolfgang von Goethe

Letzten November besuchte ich einen Kurs zum Thema agiles Requirements-Engineering mit abschliessender IREB-Zertifizierung. Wie es so üblich ist, gehört dazu auch eine Vorstellungsrunde. Alle Kursteilnehmer hatten die Aufgabe, sich mit Lego Serious Play kurz vorzustellen. Wer mich fragt was ich mache, den antworte ich: IT-Firefighter. Was machte ich also mit Lego Serious Play? Richtig, ich steckte einen Feuerwehrmann mit Schlauch zusammen. Als ich an der Reihe war, stellte ich auch einige meiner Werkzeuge vor, welche ich im Zusammenhang mit der Anforderungserhebung verwende.

In diesem Beitrag werde ich eines meiner Arbeitsmittel vorstellen, dass Cynefin-Framework. Dabei handelt es sich um ein Wissensmanagement-Modell mit dem sich Probleme, Situationen und Systeme besser beschreiben und einordnen lassen.

Ich will dieses Modell aufgreifen, weil in letzter Zeit die «Best Practices» zunehmend in Kritik geraten. Mit dem Cynefin-Modell kann ich in diesen Diskussionen recht schnell feststellen, ob der Gesprächsteilnehmer aus eigener Erfahrung spricht oder einem aktuellen Hype folgt.

Das Cynefin Framework besteht aus fünf Domänen und für vier gibt es entsprechende Handlungsempfehlungen.

Die Unordnung

Beginnen wir mit der Domäne Unordnung (Disorder). Bei einem neuen Projekt bzw. Einsatz besteht am Anfang der Zustand des «Nicht Wissens». In dieser Zone treffe ich viele Annahmen, muss darauf achten nicht vorschnell zu handeln. Zugegeben es gibt Situationen da ist dies einfacher gesagt als getan.

Die Domäne Unordnung bezeichne ich auch gerne als Chamäleon, da diese auch als Komfortzone zum Rückzug in ein stilles Kämmerlein einladen kann. Entscheide die in dieser Domäne getroffen werden, basieren meist aus Erfahrungen der Vergangenheit. Das haben wir schon immer so gemacht ist ein Erkennungsmerkmal dieser Domäne.

Mein Ziel ist natürlich, die Arbeit in den anderen vier Domänen und da idealerweise die Themen von links nach rechts zu schieben und einzuteilen.

Das Chaos

Nicht selten treffe ich dabei die Domäne Chaos an. In dieser ist es für mich sehr schwierig die Ursache-Wirkungs-Beziehungen zu erkennen. Ein gezieltes bzw. gesteuertes Vorgehen ist sehr schwierig, da die Umgebung mit identischen Vorgehen sehr unterschiedlich reagieren kann. Mein Vorgehen ist meist nicht wiederholbar und ist dadurch wenig effizient. Erkennbar wird diese Domäne beispielsweise durch hohe Turbolenzen oder viele Entscheide unter hohem Zeitdruck.

Um damit umgehen zu können wird das Handlungsmuster Act-Sense-Response zu Deutsch Handle-Erkenne-Reagiere empfohlen. Der Schwerpunkt im Handlungsmuster liegt dabei auf handeln.

Eines meiner Erlebnisse, welches schon ein paar Jahre zurück liegt, war in einem Projekt, dass bereits in Schieflage war als ich dazukam. Meine Aufgabe bestand darin es wieder auf Kurs zu bringen. Zu dieser Zeit wollte ich natürlich auch Projekte nach agiler Methodik umsetzen. In einem ersten Meeting mit Stakeholdern brachte ich diesen Vorschlag und die Reaktion war für mich zufriedenstellend. In einem weiteren Meeting mit anderen Stakeholdern führte der gleiche Vorschlag zur Eskalation. Um zu verstehen was da gerade passierte, wechselte ich ins aktive Zuhören. Nach dieser Reaktion war mir klar, dass unser Vorgehen eine Anpassung benötigte. Wir erfuhren von Ereignissen mit früheren Lieferanten, welche den gleichen Vorschlag machten und dass sie genug von den agilen «Zeug» hatten. Der letzte Lieferant betonte auch dass er Scrum könne, aber richtig. Am Ende funktionierte das auch nicht. Mir wurde klar, hier reizte ich Stakeholder, wenn ich von Scrum redete. Damit mir das Wort «Scrum» nicht nochmal über die Lippen fuhr, wechselte ich es in meinen Gedanken mit «in die Fresse hauen» und lies mir den Satz des früheren Lieferanten nochmals durch den Kopf gehen, verwendete dabei aber das ausgetauschte Reizwort. Es hörte sich dann so an: Wir können dir «in die Fresse hauen», aber richtig. Das will ich natürlich nicht, es hilft mir aber die Reizsituationen zu visualisieren. So fällt es mir einfacher die Bedürfnisse und Reaktionen meines Gegenübers besser zu verstehen. Du kennst das sicherlich von Namen die in dir ein negatives Gefühl auslösen können. Genauso ist es mit Methoden auch wenn du es gemäss den Empfehlungen machst. Wenn dein Gegenüber negative Erfahrungen damit gemacht hat, dann passe deine Wortwahl an.

Das war jedoch nicht das einzige Problem. Die Lösung, welche eingeführt wurde, reagierte auf jeder Umgebung anders. Es gab zwar ein paar Unit-Tests, in diese hatte der Kunde das Vertrauen verloren. Die Anwendung lief auf seiner Umgebung nicht.

Die Komplexität

In einen weiteren Schritt analysierten wir die Probleme der Lösung. Diese bestand zu einem Grossteil aus Standardprodukten wie zum Beispiel SharePoint und weiteren Zusatzprodukten. Das Zusammenstecken und die Konfiguration klang einfach. In dieser Umgebung war es jedoch sehr komplex geworden.

Für komplexe Systeme empfiehlt das Cynefin-Framework das Handlungsmuster Probiere-Erkenne-Reagiere. Der Schwerpunkt liegt dabei auf reagieren. Als erstes probierten wir die Installation, hier mussten wir zuerst den Administrator überzeugen, da wir in seinen Tätigkeitsbereich eingriffen. Das Installationsskript funktionierte, die Lösung jedoch nicht. Wir fanden dabei heraus, dass ein Feature auf SharePoint nicht aktiviert wurde. Dieses Verhalten war speziell, da es auf einer anderen Instanz funktionierte. Was jedoch klar wurde, der Administrator brauchte mehr Feedback von der Installationsroutine. Ein weiteres Problem trat beim Deployment der Formulare auf. Diese wurden mit einem Zusatzprodukt für SharePoint gemacht. Es stellte sich dabei heraus, dass diese nicht für das Szenario Deployment via Dev, Test, Int und Prod gemacht waren. Es gab keine Fehlermeldungen, es veränderten sich jedoch Werte welche für die Identifizierung notwendig waren. Die manuellen Tests konnten aus diesen Gründen nicht erfolgreich durchgeführt werden. Fehler mit solchen Verhalten sind herausfordernd. Erkennungsmerkmale dieser Domäne sind häufig konkurrierende Ideen, es gibt etliche Unbekannte und Ursache-Wirkungsbeziehungen sind nur im Rückblick erkennbar.

Das Komplizierte

Unser Ziel war jedoch klar, wir mussten einige Dinge überarbeiten. Vereinfachen hin zur Best Practice «Test Driven Development» war beispielsweise nicht möglich. Wir mussten nach der Installation auf der jeweiligen Umgebung die neuen Werte ermitteln und anpassen. Das war kompliziert. Wir waren also für dieses Szenario in der komplizierten Domäne eingetaucht. Das Handlungsmuster Sense – Analyze – Respond, zu Deutsch erkenne – analysiere – reagiere. Der Schwerpunkt in diesem Handlungsmuster liegt dabei auf analysieren. Unsere Reaktion nach der Analyse des Systems war die Anpassung der Installationsdokumente mit dem entsprechenden Vorgehen. Mit entsprechenden Fachwissen lassen sich die Ursache-Wirkungsbeziehungen in dieser Domäne erkennen. Unser produktspezifisches Fachwissen in Bezug auf solche Besonderheiten bauten wir damit erst auf.

Das Einfache

Um den Administrator mehr Feedback während der Installation zu geben, war es notwendig die Schritte zu protokollieren und die Fehler zusammenzufassen. Im Vergleich zu den anderen Aktionen war das eine einfache Aufgabe. In diesem Bereich befanden wir uns in der einfachen Domäne. Das empfohlene Handlungsmuster für diesen Fall ist Sense – Categorise – Respond, zu Deutsch erkenne – beurteile (ordne ein) – reagiere. Der Schwerpunkt liegt in diesem Handlungsmuster bei beurteile.

Wir entschieden uns für ein Best Practice – Logging, welches in anderen Projekten bereits zur Anwendung kam. Das machte die Umsetzung effizienter. Dir Ursache-Wirkungsbeziehung war klar erkennbar, es bestanden wiederholbare Muster und eindeutige Ereignisse.

Jetzt denkst du dir, logisch mache ich zum Teil so? Super, dann wirst du sicherlich nicht auf die Idee kommen, ausserhalb der einfachen Domäne mit Best Practices zu hantieren oder in der einfachen Domäne die Best Practices in Frage zu stellen.

Während du in den Domänen Chaos und Komplex mit Konfliktpotential rechnen musst, hast du in den Domänen Kompliziert mit Good Practices und Einfach mit Best Practices hohes Effizienzpotential. Wichtig dabei ist natürlich, die Qualität durch kontinuierliche Verbesserung regelmässig zu hinterfragen. So verbessern sich am Ende auch deine Best- und Good Practices.

Wie sind deine Erfahrungen in diesem Zusammenhang, dein Feedback interessiert mich!