Der fünfte agile Wert: Outcome > Output

Benötigt das agile Manifest der Softwareentwicklung ein Update? Dazu hat sich Jeff Patton ¹ in einem Blog-Beitrag Gedanken² gemacht. Jeff sagt, dass die meisten agilen Shops in Wirklichkeit nach dem Service Provider Model betrieben werden. Und das ist leider keine gute Nachricht! Warum das so ist und wie ein fünfter Wert im agilen Manifest Abhilfe schaffen könnte, erkläre ich in diesem Artikel.

Was ist das Service Provider Modell?

Ein Dienstleister arbeitet kunden- und auftragsorientiert. Das bedeutet, für einen Dienstleister ist es wichtig eine hohe individuelle Kundenzufriedenheit zu generieren und gleichzeitig möglichst viele Stunden abzurechnen. Er macht exakt das, was der Kunde möchte. Im erweiterten Sinn ist ein Dienstleister sein eigenes Produkt.

Jeff Patton schildert als Beispiel seine Erfahrungen bei der Renovierung der eigenen Küche. Natürlich wurde er vom beauftragten Handwerker gut beraten, aber Jeff setzte sich mit seinen Entscheidungen durch. Der Handwerker setzte dann seine Wünsche exakt wie gefordert um. Mit seinen zweifelhaften Designentscheidungen lebt Jeff heute noch.

Was ist das Problem mit dem Service-Provider-Modell?

Das Service Provider Modell funktioniert für die Individualentwicklung. Hier wird nach Kundenwunsch gefertigt und der Kunde ist zufrieden oder lebt wie im Falle von Jeff mit seinen Entscheidungen. Es versagt aber für Standardprodukte, die an eine heterogene Kundengruppe gehen. Denn die direkte Bedienung der Kundenwünsche erzielt nicht immer die richtige Wirkung auf den Markt.

Warum ist das so? Ein Problem ist sicher, dass es den einen Kunden nicht gibt. In Scrum gibt es daher den Stellvertreter oder Proxy-Kunden: Das ist der Product Owner.

Ein tiefer liegendes Problem liegt in der agilen Organisation und im agilen Manifest selbst: Die Trennung zwischen dem agilen Team, das für Produktentwicklung und Lieferung zuständig ist und dem Management, das sich für die Product-Outcomes verantwortlich zeigt. Viele finden diese Trennung gut und auch Scrum legt den Fokus auf die Abarbeitung eines Backlogs und eine hohe “Produktivität”.

Durch die Fokussierung auf Lieferung entsteht ein Problem: Ein reines Lieferteam liefert. Das Team hat keinen Anreiz dafür, das möglichst richtige zu liefern. Es gibt keinen Anreiz für Experimente und die internen Stakeholder belohnen eher Produktivität. So kann es sein, dass ein agiles Team als erfolgreich gilt, weil die internen Stakeholder zufrieden sind.

Der fünfte agile Wert

Eine Lösung für dieses Problem ist das Denken in Outcomes. Statt Outputs zu planen, also Backlog-Items, wird geplant, welche Outcomes erzielt werden sollen. Übrigens, für die Definition von Outcomes nutze ich übrigens gerne den Ansatz von Joshua Seiden und Jeff Gotthelf ²:

Ein Outcome ist die messbare Veränderung des Verhaltens von Menschen (ideal Kunden), die den eigenen Geschäftszielen zugutekommt.

Jeff Patton schlägt vor, das Agle Manifest um einen fünften Wert zu ergänzen:

Fünfter agiler Wert: Outcome > Output

Die Verantwortung für diese Outcomes gehört aus Sicht von Jeff auch in die agilen Teams.

Gleichzeitig sind die meisten Produkte in der Digitalisierung keine Individualprodukte. Sie lösen Probleme für einen bestimmten allgemeineren Anwendungsfall. Und die Kunden sind in der Regel eine größere Kundengruppe und keine Individualkunden. Outcomes beschreiben die positive Wirkung, die mit den Produkten erreicht werden sollen. Outcomes führen dazu, dass Kunden ein neues nützliches und messbares Verhalten zeigen. Erst, wenn die Outcomes erzielt wurden, hat das Team Erfolg. Genau daher gehört die Outcome-Planung auch in die Hand der Teams.

OKRs helfen dabei, in Outcomes zu denken

Der große Beitrag des Zielsystems Objectives & Key Results für die agile Welt ist das Denken in Outcomes. Die Key Results von OKR sind nichts anderes als eine Wirkungsplanung und leisten ihren Beitrag dazu, dass die agile Arbeit aus dem selbst geschaffenen Hamsterrad der Lieferung herauskommt.

Sicher, das agilen Manifest hat der Software-Welt überhaupt erst eine Lieferfähigkeit ermöglicht ³. Das war historisch eine große Leistung, aber die reine Optimierung der Lieferung reicht heute nicht mehr. Jetzt geht es darum, das möglichst richtige zu liefern.

Daher bin ich bei Jeff Patton und sage auch, wir benötigen den fünften agilen Wert: Outcome ist mehr als Output.

Was ist deine Sicht auf das Thema? Kommentiere gerne hier im Blog oder auf den sozialen Medien, wo ich diesen Blog-Beitrag veröffentlicht habe.

Weiterführende Links