Voraussichtliche Lesedauer: 6 Minuten
Ich habe immer wieder Diskussionen rund um das Thema Output vs. Outcome. Eine der zentralen Änderungen im agilen MindSet im Vergleich zu klassischen Organisationen ist die Metapher „des Erreichens“. Es geht nicht um das was wir tun, sondern um die Wirkung, die wir erzielen (oft in Form von Business Value). Wenn ich darüber spreche, schauen mich oft verständnislose Blicke an:
- Es geht nicht darum wie viele Kunden wir anrufen (machen), sondern wie viele Kunden wir abschließen (erreichen).
- Es geht nicht darum welche Anzahl an Stunden wir arbeiten (machen), sondern wie wir die Ergebnisse erfüllen (erreichen).
- Es geht nicht darum wie viele Features Software wir entwickeln (machen), sondern welchen Business Value wir erzeugen. (erreichen).
Dann lasse ich die Teilnehmer das mal ausprobieren, denn meine Überzeugung ist (normalerweise) agile Denkweisen sind leicht zu verstehen, aber schwer zu leben. In diesem Fall ist wohl der Schritt des Verstehens schon etwas übungsbedürftig.
Beispiel Output
In Workshops gehe ich mit den Teilnehmern gerne einen plakativen Weg. Ich frage zuerst: „Ihr wart alle in der Schule, seid sozusagen Schulexperten. Was würdet Ihr am heutigen Schulsystem verändern?“ Dabei geht es ganz klar um machen, um Output. Ich sammle die Antworten.
Workshop Ergebnisse zu „Output“
Beispiel Outcome
Im zweiten Schritt stelle ich eine ähnliche Frage: „Jetzt nochmal, ihr seid Schulexperten. Wie wollt ihr, dass Eure Kinder die Schule verlassen?“. Da kommen auf einmal ganz andere Antworten.
Workshop Ergebnisse zu „Outcome“
Das zeigt sehr deutlich den Unterschied zwischen:
Machen vs. Erreichen
Output vs. Outcome
Aber auch wie wir uns programmieren bzgl. unserer Gedanken, welche Fragen wir stellen.
Ergebnisse für das Unternehmen
Keine Führungskraft (auch nicht vor 30 Jahren) hätte mir beim Ziel, Ergebnisse zu erreichen widersprochen. Schon zu Taylors Zeiten sind die KPI ins Rampenlicht gerückt. Gleichzeitig ist das Gedankengut als Organisation gesamtheitlich in Outcome / Erreichen zu denken immer noch ungewohnt.
Hier sehe ich einen zu beschreitenden Entwicklungspfad für Organisationen. Der klassische Anfang ist die Abteilungsdenke in Silos. Das Ziel ist eine wohlwollende Denke als Organisation. Um dahin zukommen braucht es drei Grundlagen:
- Viel gegenseitiges Verständnis und Transparenz: wer an welchen Themen arbeitet, wie das läuft und wo es gerade hakt.
- Eine gesamtheitliche Einstellung, frei von Eigeninteressen, geprägt von Verständnis.
- Weil man eben nicht genau versteht und weiß, wie jeder Bereich arbeitet auch ein hohes Maß an Vertrauen, dass jeder sein/ihr Bestes gibt.
Ist das in der Kultur nicht durch und durch verankert (was meist nicht der Fall ist), wäre es hilfreich am Miteinander kontinuierlich zu arbeiten.
Mein Bild ist: der Start einer agilen, Outcome-orientierten Organisation beginnt in einer Keimzelle oder vielleicht mehreren Keimzellen. Stück für Stück können diese wachsen und sich ausbreiten. Bis sie am Ende zusammenwachsen und eine Einheit bilden.
Das nenne ich den Reifeprozess einer ergebnisorientierten Organisation.
Reife der Organisation
Stufe 1: Abteilungen bilden Silos
Hier erlebt man oft, dass Wünsche und Anforderungen über den Zaun geworfen werden. Nach der Umsetzung wird das Ergebnis zurückgespielt. Manchmal ist man glücklich damit, manchmal auch nicht. Ist aber auch egal, denn es herrscht ein „Die“ und „Wir“ – organisatorische Silos. Es kann also nur innerhalb eines Silos nach „Erreichen“ gestrebt werden. Meist sind hier erste Züge agilen Arbeitens nur vereinzelt oder gar nicht vorzufinden.
Stufe 2: Silos werden aufgelöst
Ist ein Bestreben im Unternehmen an kontinuierlicher Verbesserung zu arbeiten, werden Silogrenzen und Hürden dafür sehr schnell deutlich. Bessere Kommunikation zwischen den Bereichen und interdisziplinäre Teamansätze sind häufig die Folge. Eine Struktur von Team-Product Owner-Stakeholder prägt sich aus. Wird mit regelmäßigen Retrospektiven auf allen Ebenen gearbeitet, verschwimmen die Silos. Es entsteht mehr und mehr übergreifendes Denken und Verständnis für Abläufe und Ziele der anderen Teams. Es kann übergreifender gedacht werden. Wenn dann noch partikulär Interessen in den Hintergrund rücken, wächst die Organisation über erreichbare Ziele von einzelnen Teams hinaus, es kann gesamtheitlich gehandelt werden.
Stufe 3: Gesamtheitliches Denken
Bei internen Produkten, wie IT Systeme für das Unternehmen, können die Stakeholder und umsetzenden Teams soweit zusammenwachsen, bis hin zur vollkommenen Überflüssigkeit des Product Owners. Das erfordert ein tiefes Verständnis über das zu Erreichende aus dem Team und ein tiefes Produktverständnis sowie der Art und Weise der Umsetzung bei den Stakeholdern. Weiterhin hier notwendige kulturelle Grundlagen
- ein hohes Maß an Vertrauen: jeder gibt sein Bestes und
- ein sehr positives Miteinander.
Dieser Reifegrad erfordert viel Kulturarbeit und Übung agilen Methoden. Das bedeutet auch nicht persé die Überflüssigkeit des Product Owners. Vor allem wird diese Rolle immer notwendig sein in Richtung externer Stakeholder.
Die Grenzen sind fließend und nicht diskret, wie hier vielleicht der Eindruck entstehen kann. Dennoch können diese drei Stufen animieren mal zu reflektieren, wo jedes Unternehmen oder jeder Bereich gerade im Reifespektrum steht und wo es Potenzial gibt.
Entwicklungsschritte zu Outcome denken
Basis bilden die 3 Grundlagen (siehe oben). Diese Grundlagen gilt es gemeinschaftlich zu entwickeln. Das kann zum Beispiel über gemeinsame Retrospektiven erfolgen, über einen „Schüleraustausch“ in andere Bereiche oder über übergreifende Fachverantwortliche. Am Ende geht es um ein gemeinschaftliches Verständnis, positives Bild der mitwirkenden Abteilungen. Bis sich vielleicht Abteilungen auflösen und eine amorphe Organisation entsteht.
Weiterführende Artikel
