The garbage man can! Eine Story über Output, Outcome, Velocity und die Simpsons

„Who can take this diaper?“ fragt Marge Simpson mit ihrer Reibeisenstimme.

„I don't mind at all!“ singt der Müllmann, greift sich die Babywindel und verschwindet lächelnd durchs Fenster. Homer hatte damit ein populistisches Wahlversprechen eingelöst, dass die Müllmänner von Springfield künftig alle unangenehmen Arbeiten übernehmen würden. Die Geschichte geht nicht gut aus, wie man sich wohl denken kann. Trotzdem hege ich große Sympathie für den Müllmann, der den Dreck einfach anpackt.

Im Produktbereich Finanzmanagement besprechen wir momentan das Buch Continuous Discovery Habits von Teresa Torres, welches ich bislang sehr empfehlen kann. In unserem letzten Meeting haben wir in der Runde von Produktmanager:innen und Product Ownern wieder einmal lebhaft über die Anwendbarkeit der dort vorgestellten Methodik des Opportunity Solution Tree und der dahinterstehenden Annahmen diskutiert.

Ein zentrales Ziel moderner Produktpolitik ist es demnach, die Produktentwicklung auf das Ergebnis (Outcome) des Produktes auszurichten und nicht mehr ausschließlich auf die Menge (Output) an programmierten Funktionen. Es geht also nicht mehr darum, wie hoch die Geschwindigkeit (Velocity) eines Teams ist, sondern dass in jeder Iteration ein Kundenproblem gelöst (oder zumindest gemildert) wird.

Das ist bestechend einfach und einleuchtend. Und dann schauen wir uns um und merken schnell, dass es trotzdem nicht leicht ist, diese Fokussierung auf den Output aufzulösen.

Warum ist das so?

Ich arbeitet seit 2018 als Product Owner bei der MACH AG. Im Mai desselben Jahres haben wir im ERP-Umfeld die Kooperation mit dem Nearshorer CROZ in Kroatien gestartet. Der Hauptgrund war, dass MACH als Ergebnis zweier Ausschreibungen einen großen Bedarf an zusätzlichen Kapazitäten in der Entwicklung hatte. Im Rahmen der Arbeit an diesen Großprojekten habe ich meinem Team mehr als einmal gesagt: „Wenn wir es nicht machen, macht es keiner!“

Rückwirkend ist es überraschend, wie motivierend so etwas sein kann. Unsere Aufgabe als Team war es also am Anfang nicht, die ausgeklügeltsten und schönsten Lösungen zu entwerfen, sondern unsere Verpflichtungen zur Bereitstellung von Software mit einem festgezurrten Funktionsumfang zu einem Stichtag zu erfüllen.

Wir konnten viele neue Funktionen zur Verfügung stellen. Die Komplexität der Aufgaben stieg mit der Zeit, so integrierten wir jüngst ein 4-Augen-Prinzip im Bereich der Partnerverwaltung. Selbst wenn wir als Team das Gefühl bekommen, dass wir Dinge tun, die sonst einfach kein anderer machen will, lachen wir darüber und sind dann erfolgreich. Es braucht also eine gewisse Einstellung und einen gesunden Optimismus: „The garbage man can and he does it with a smile“.

Die Velocity, also die durchschnittliche Menge an Storypoints pro Sprint, ist so eine traction metric. Wenn wir also eine Aufgabe haben, bei der die Freiheitsgrade aufgrund vertraglicher Regelungen, technischer Zwänge oder anderer Abhängigkeiten sehr klein sind, dann ist die strikte Outputorientierung des Teams ein zulässiger Weg. Wichtig ist dabei aus meiner Sicht trotzdem, dass wir einen hohen Qualitätsanspruch an die Einheitlichkeit der Lösungen (in Code und Design) und die Dokumentation legen. Gerade bei einem erhöhten Durchsatz dürfen in diesen Punkten keine Abstriche gemacht werden. Andernfalls lassen sich die Änderungen später nicht mehr nachvollziehen und die Wartbarkeit der Software leidet ungemein.

Fazit

Es darf diese zwei Welten also geben. Vielleicht muss es sie sogar geben. Denn wo es auf der einen Seite darum geht, in einem wachsenden Markt Anteile zu gewinnen und Standards zu etablieren, wo es also noch keine etablierten Lösungen gibt und man auf der grünen Wiese Kundenwerte maximiert, so braucht es in einem gesättigten Umfeld mit Industriestandards und hohen Erwartungen der Kundschaft effiziente Lösungen, die in Zeit, Kosten und Qualität zur Verfügung gestellt werden.

Outputorientierung ist auf Dauer nicht erfüllend. Wir wollen in Zukunft mehr mit dem Kunden zusammenarbeiten, uns austauschen und im Rahmen eines bestimmten Budgets gemeinsam die Lösungen definieren, welche den größten Nutzen für ihn schaffen. Wir wollen diesen Wandel gestalten und tun dies bereits mit einem nutzerzentrierten Vorgehen.

Jedoch, bis wir so weit sind, braucht es manchmal einfach jemanden, der die Windeln rausbringt. Es braucht einen Müllmann.