Aspektorientiert diskutieren - Weg und Ziel entkoppeln vermeidet Konflikte [OOP 2009]

Warum fällt Veränderung oft schwer? Liegt es wirklich vor allem daran, dass alte Gewohnheiten schwer zu "entlernen" sind? Teaching an old dog new tricks: ist das wirklich so mühsam? Gestern meine ich einen Zipfel von der Erkenntnis erhascht zu haben, dass das nicht wirklich der Grund ist. Wir machen uns Veränderung vielmehr selbst schwer.

Gestern saß ich in meinem Lieblingscafé in Hamburg, dem elbgold am Mühlenkamp, und wollte eigentlich nur meinen Lieblingskuchen genießen, Schokosahne - leider nur am Wochenende -, da bekam ich leider keinen Platz. Zunächst. Dann bot mir aber ein mir vom Sehen her bekannter anderer "elbgold-Bewohner" einen Hocker bei sich an und wir kamen ins Gespräch. Kaum sah er, dass ich ein C#-Buch unterm Arm hatte, outete er sich als Java-Jünger. So kamen wir denn unvermeidlich auch auf Clean Code Developer (CCD) als plattformunabhängige Qualitätsoffensive.  Und wir kamen auf die Defizite im Vorgehen in seiner Firma.

Issue Tracking als Veränderungsproblem

Da ist zum Beispiel das Thema Issue Tracking. Damit hat man dort noch nicht soviel am Hut. Man beginne gerade sich zu bemühen, Aufgaben im Nachhinein zu erfassen, also das, was man schon getan hat. Aber mit einer proaktiven Liste von Fehlern oder gar Anforderungen... nein, darüber diskutiere man noch. Es sei alles nicht so einfach: der Chef müsse noch überzeugt werden, ein Tool sei zu entscheiden, das Team hätte unterschiedliche Vorstellungen usw.

Ich habe meinem Gesprächspartner dann natürlich aus aktuellem Anlass gleich den soziokratischen Konsent als Hilfsmittel für die Entscheidungsfindung nahegelegt. Statt die Verantwortung auf den Chef abzuwälzen (Autokratie) oder langwierig unter allen einen Konsens für eine Abstimmung zu erzielen (Demokratie) sei auch ein anderes Vorgehen möglich - und wahrscheinlich sogar zielführender.

Mit diesem Rat bin ich immer noch zufrieden. Konsent ist ein allgemein hilfreiches Instrument zur Entscheidungsfindung. Dennoch oder gerade deshalb geht Konsent nicht die Wurzel des Übels an.

Was macht die Situation in der Firma meines Gesprächspartners so unerquicklich. Was macht die Veränderung zu konsequentem Issue Tracking so schwer? Die neue Gewohnheit, eine qualitätssteigernde Praktik des orangen Grades des CCD, hat es schwer Fuß zu fassen im immer eiligen Tagesgeschäft, bei dem alles wichtig+dringend ist - außer eben solcher Veränderung.

Ist Issue Tracking an sich schwierig? Braucht man dafür schwer zu erlernde Fertigkeiten? Ist es Professoren vorbehalten, Issue Tracking zu verstehen? Oder kostet Issue Tracking schlicht soviel Zeit, dass man dafür eigentlich tagelang den Betrieb schließen müsste?

Alles quatsch! Issue Tracking ist kinderleicht und schnell gemacht.

Also nochmal: Wo liegt das Problem?

Weg und Ziel entkoppeln

Ich glaube, die Veränderung hin zu Issue Tracking ist so schwierig, weil das Team ein undifferenziertes Bild davon hat. Issue Tracking erscheint als großer Klumpen, den es ganz oder gar nicht zu schlucken gilt. Man versucht eine die Entscheidung zu treffen und umzusetzen "Wir machen Issue Tracking so und so. Punkt."

Hört sich doch auch ganz normal an. Man entscheidet sich für oder gegen Issue Tracking in einer bestimmten Weise. Was sonst?

Und genau da liegt der Hase im Pfeffer. Das ist nicht-agiles Denken. Das ist Denken aus einer Welt, die erstens überschaubarer war und zweitens viel langsamer und weniger vollgepackt.

So ist es ja aber eben nicht in der Firma meines Gesprächspartners. Dort steht man ständig unter Kundendruck. Neue Features eben noch einflicken, Releases schnell noch zusammenbasteln, Fehler korrigieren, dann wieder neue Features und die Aufwandsabschätzung für das Angebot des Chefs nicht vergessen... Wie so oft findet die Arbeit im ständigen "emergency mode" statt. Da ist die Welt einfach nicht überschaubar, weil man sie durch einen Tunnel sieht. Es gibt kaum Spielräume.

Das kann und soll man beklagen. Am Ende lässt sich diese grundlegende Situation selbst aber nicht schnell ändern. Sie definiert die Rahmenbedingungen für die Einführung von Issue Tracking und sonstigen Veränderungen.

Was also tun? Wie kann es sich das Team einfacher machen, Issue Tracking einzuführen?

Meine Erkenntnis derzeit ist, ein großer "Veränderungsklumpen" sollte zunächst grundsätzlich aufgeteilt werden in die Aspekte Ziel und Weg. Der Weg ist also mal nicht das Ziel. Weg und Ziel sind vielmehr deutlich zu unterscheiden. Die Zugspitze ist nicht die Zugspitzbahn. Mir reicht auch nicht die Fahrt mit der Zugspitzbahn ohne längeren Aufenthalt auf dem Gipfel. Und für den Aufenthalt auf dem Gipfel muss ich nicht unbedingt mit der Zugspitzbahn dorthinkommen.

Was ist mit dieser Unterscheidung gewonnen? Das Team kann jetzt zwei Fragen diskutieren:

1. Wollen wir Issue Tracking einführen?
2. Wie wollen wir Issue Tracking einführen?

Der Vorteil liegt erstens in einem viel besseren Verständnis davon, was alle Beteiligten unter Issue Tracking überhaupt verstehen. Da mögen die Meinungen nämlich schon auseinandergehen. Solche Meinungsdifferenzen, wenn sie nicht aufgedeckt werden, behindern ansonsten den Veränderungsprozess im Sinne eines "Veränderungsklumpens".

Aus der Diskussion darüber, was Issue Tracking ist, welche Formen es gibt, wo die Vor-/Nachteile liegen usw. ergibt sich dann ein Ziel. Dazu kann das Team einen ersten Beschluss fassen - im besten Fall mittels Konsent. Der Beschluss kann z.B. lauten: "Wir führen Issue Tracking für Anforderungen und Fehler für alle Projekte ein."

Der Trick dabei: Dieser Beschluss ist viel einfacher zu fassen als der über den bisherigen "Veränderungsklumpen". Die Vorteile von Issue Tracking ja liegen auf der Hand. Dass jemand es nicht haben möchte - ganz unabhängig davon wie man das schaffen kann -, ist schwer vorzustellen. Nichtsdestotrotz ist es wichtig, genau solche Einmütigkeit explizit zu machen. "In Notzeiten", wenn die Veränderung mal wieder schwer fällt, kann man sich dann nämlich gegenseitig daran erinnern. "Wir haben doch alle dasselbe Ziel. Wir sind alle für Issue Tracking. Lasst uns das Ziel jetzt nicht aus den Augen verlieren."

Wenn nun das Ziel klar ist, dann kann sich das Team an die zweite Frage machen. Wie wollen wir das Ziel erreichen? Welche Schritte wollen wir in seine Richtung machen?

Das ist eine ganz andere Frage als die erste, grundsätzliche, was das Ziel eigentlich sei. Während man den Weg diskutiert, kann man jetzt auch gewiss sein, einer Meinung zu sein, dass das Ziel überhaupt erreicht werden soll. Die Diskutanten richten kohärent ihre Energie darauf, einen Weg zu finden, um gemeinschaftlich ans Ziel zu kommen.

Oft ist es nun gerade diese Diskussion, die von Differenzen und Missverständnissen geplagt ist. Aber das ist jetzt nicht mehr so schlimm. Denn da sich alle einig über das Ziel sind, haben alle ein Interesse, den "Sand im Getriebe" aufzuspüren und unschädlich zu machen.

Baby Steps

Mit dem Fokus auf dem Weg ist es nun auch einfacher, eine sehr praktible Technik anzuwenden, um ihn zu gehen: die Technik der kleinen Schritte. Der gleichermaßen komische wie tiefgründige Film "Was ist mit Bob?" ("What about Bob?") mit Bill Murray und Richard Dreyfuss sagt dazu "Baby Steps".

Veränderungen lassen sich am besten mit kleinen Babyschritten erreichen. Sich nicht zuviel vorzunehmen, sich Unsicherheiten und Fehlschläge zu gestatten, das ist eines der Geheimnisse erfolgreicher Veränderung. Wer nur kleine Schritte macht, kann seinen Weg auch immer wieder korrigieren. Denn Korrektur ist sicher nötig: unvorhergesehenes passiert, auf das man reagieren muss; Feedback unterschiedlicher Art signalisiert, dass man vom Weg abgekommen ist.

Der ursprüngliche undifferenzierte Entschluss für Issue Tracking mag so ausgesehen haben: "Wir führen Issue Tracking ab dem 1.10.2008 für alle Projekte ein und benutzen Bugzilla für alles: Anforderungen und Fehler und Design Issues." Dass führt notwendig zu Problemen. Jedes Problem mit dem Wie (z.B. Bugzilla) stellt dann auch das grundsätzliche Was (Issue Tracking) in Frage.

Wenn Was (Ziel) und Wie (Weg) aber getrennt sind und der Weg auch noch in Baby Steps aufgeteilt ist... dann ist es viel einfacher. Was und Wie geraten nicht mehr in Konflikt. Teammitglieder geraten nicht mehr in Konflikt. Naja, zumindest nicht mehr so leicht.

Mit der konsentbasierten Grundsatzentscheidung - "Wir führen Issue Tracking für Anforderungen und Fehler für alle Projekte ein." - ist das Team viel freier, kleine, auch im Tagesgeschäft gangbare Schritte festzulegen. Die könnten z.B. sein:

1. Issue Tracking nur für Fehler mit Excel für das Projekt A über 4 Wochen.
2. Issue Tracking für Fehler und Anforderungen mit Excel für das Projekt A über 4 Wochen.
3. Issue Tracking für Fehler und Anforderungen mit Bugzilla für das Projekt A über 4 Wochen.
4. Issue Tracking für Fehler und Anforderungen mit Bugzilla für Projekt A und B über 4 Wochen.
5. Issue Tracking für Fehler und Anforderungen mit Bugzilla für alle Projekte

Sieht aus wie ein Spring Backlog? Ist ein Backlog. Ein Backlog ist nichts anderes als eine Folge von geplanten Schritten. So sind wir denn also beim Wie zu einem Thema auf dem vertrauten Terrain agilen Vorgehens. Das sollte es einfach machen, die Unterscheidung zwischen Ziel und Weg zu treffen.

Jeder dieser Babyschritte kann separat beschlossen werden - im Konsent. Es müssen zunächst auch gar nicht soviele sein. Mit dem gemeinsamen Ziel könnten in einer ersten Beschlussrunde auch nur Schritte 1 bis 3 ins Backlog kommen plus einer expliziten Entscheidung über den weiteren Weg:

1. Issue Tracking nur für Fehler mit Excel für das Projekt A über 4 Wochen
2. Issue Tracking für Fehler und Anforderungen mit Excel für das Projekt A über 4 Wochen
3. Issue Tracking für Fehler und Anforderungen mit Bugzilla für das Projekt A über 4 Wochen
4. Entscheidung über Bugzilla und den weiteren Weg

Das Schöne an der Entzerrung von Ziel und Weg ist, dass damit der Weg quasi befreit ist von irgendwelcher festgefügter Konkretheit. Er muss nicht in ganz bestimmter Weise zwangsläufig verlaufen. Er kann geplant und später korrigiert werden. Jeder Schritt muss im Moment des Beschluss nur in den Augen aller einen Beitrag zur Erreichung des Zieles leisten. Stetiger Fortschritt ist wichtiger als gerade Linie.

Dass die beschlossenen Schritte auch abgegangen werden, ist dann eine Sache recht einfacher Kontrolle. Dabei kann Scrum helfen. Welche Schritte beschlossen werden sollen, wie die Prioritäten aussehen, das liegt jedoch außerhalb des Vorgehensmodells.

Bei Veränderungsprozessen gibt es keinen externen Kunden. Die Organisation selbst ist vielmehr der "Kunde" oder genauer: die Organisationsführung. Da kommt die Soziokratie wieder ins Spiel. Es sollte eine Kreishierarchie sein, die das Ziel von Veränderung und den Weg dorthin festlegt. Sie definiert die Schritte und delegiert die Ausführung dann an einen Kontrollprozess.

Veränderung = Aspektorientierung + Soziokratie + Scrum

Veränderungen aspektorientiert in Ziel und Weg zu zerlegen und dann mit Soziokratie und Scrum anzugehen, hat mehrere Vorteile:

• Durch die differenzierte aspektorientierte Sicht werden Missverständnisse/Konflikte vermieden und gleichzeitig die Energie in Richtung Ziel gebündelt. Kohärenz entsteht durch das gemeinsame Ziel.
• Durch explizite Beschlüsse für den Weg entsteht eine Schrittfolge, die korrigierbar und erweiterbar ist. YAGNI und KISS lassen sich nicht nur auf Code anwenden, sondern auch auf solche Schrittfolgen. Probleme auf dem Weg färben nicht auf das Ziel ab. Kohärenz wird erhalten und gleichzeitig Agilität gewonnen.
• Eine soziokratische Organisation all derjenigen, die von Veränderungen betroffen sind, vermeidet Konflikte, weil alle eingebunden sind und ihre Bedürfnisse einbringen können; und sie erhöht das Wissen über mögliche Hindernisse auf dem Weg.
• Eine Kreishierarchie der "Betroffenen" vereinfacht den Rahmen für Veränderung. Es gibt nicht mehr hier die Führung, dort die Betroffenen und dann einen Prozess. Im Sinne von Scrum sind da vielmehr nur noch "Kunde" (Kreishierarchie der "Betroffenen") und "Team" (operative Organisation der "Betroffenen"). Die Koordination der Beteiligten im Sinne der beschlossenen Schrittfolge ist damit sehr klar.

Veränderungen unter Druck haben durch klare Trennung der Aspekte Ziel und Weg, aber auch Führung und operatives Geschäft eine größere Chance auf Erfolg.

• Die, die sich verändern sollen, formieren sich als Führer ihres eigenen Veränderungsprozesses in einer soziokratischen Kreishierarchie.
• Die Veränderung selbst findet in kleinen Schritten in einem iterativen Vorgehensmodell im Tagesgeschäft statt. (Scrum schreint mir da sehr naheliegend.)
• Ergebnisse werden wiederum an die Kreishierarchie gemeldet, die als "Kunde" den Weg jederzeit verändern kann.

Nach Reflektion des gestrigen Gesprächs scheint mir weniger nicht mehr wirklich zielführend in der heutigen Zeit.