Startseite » Output vs. Outcome

Output vs. Outcome

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.

Outcome vs.OutputPin
Outcome vs.Output

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 OutputPin
Beispiel 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“

Beispiel OutcomePin
Beispiel 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:

  1. Viel gegenseitiges VerstÀndnis und Transparenz: wer an welchen Themen arbeitet, wie das lÀuft und wo es gerade hakt.
  2. Eine gesamtheitliche Einstellung, frei von Eigeninteressen, geprÀgt von VerstÀndnis.
  3. 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

  1. ein hohes Maß an Vertrauen: jeder gibt sein Bestes und
  2. 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


Schreibe einen Kommentar

Neues per E-Mail?

Synapsenstau.deAgile Business Development. Agile Transformation. hat 4,78 von 5 Sternen11 Bewertungen auf ProvenExpert.com