Stewardship in der Produktentwicklung

Als Product Owner maximierst du den Nutzen deines Produktes. Na klar, so steht es im Scrum Guide. Ich würde ergänzen, dass der Nutzen dabei größer als die Kosten sein sollte. Aber mit Blick auf welchen zeitlichen Horizont? Hast du die nächsten 2 Wochen, 2 Monate, 2 Jahre oder 2 Jahrzehnte im Blick? Aus meiner Sicht solltest du sowohl die kurzfristige als auch die langfristige Perspektive austarieren. Warum und wie das funktionieren kann, erläutere ich in diesem Beitrag.

Früher habe ich für das Unternehmen Accenture gearbeitet. Zwei Aussagen oder Leitlinien haben mich nachhaltig geprägt und passen wunderbar auf die Produktentwicklung. Es gab Unternehmenswerte, die von allen Mitarbeitern geteilt werden sollten. Einer dieser Werte war “Stewardship”, sinngemäß die Aussage “Hinterlasse das Unternehmen in einem besseren Zustand, als du es vorgefunden hast”.

Das passt auch auf die Produktentwicklung. Hinterlasse dein Produkt in einem besseren Zustand, als du es vorgefunden hast. Diese Aussage ist einerseits so allgemein, dass vermutlich jeder zustimmen kann. Andererseits ist sie auch so unkonkret, dass du wenig Handlungsfelder ableiten kannst. Lass uns den “besseren Zustand” daher noch ein wenig mehr konkretisieren und auf drei Dimensionen schauen:

1. Der Nutzen für deine Anwender und dein Unternehmen
2. Das Team, welches das Produkt weiterentwickelt und betreibt
3. Die Technologie, die ihr nutzt, um einen Nutzen zu generieren

Nutzen

Wie könnte nun ein besserer Zustand in der Dimension Nutzen aussehen? Das hängt natürlich stark von den Zielen ab, die du mit deinem Produkt erreichen willst. Du könntest die Anzahl deiner Anwender erhöhen oder neuer Nutzergruppen ansprechen. Die Logik wäre hier “mehr Nutzer = mehr Nutzen”. Du könntest auch den individuellen Nutzen pro Anwender erhöhen, indem du weitere Probleme löst und/oder die Problemlösungen verbesserst und verfeinerst. “Ah... mehr Features” denkst du jetzt vielleicht. Ja, unter Umständen - wenn diese Features tatsächlich einen Zusatznutzen haben. Schließlich noch der Nutzen für dein Unternehmen. Es spielt keine Rolle, ob ihr ein finanzielles Ergebnis abliefern wollt, mit Technologie kosten senken wollt, die Prozessgeschwindigkeit erhöhen wollt, die Reputation erhöhen wollt oder was auch immer – der angestrebte Nutzen für das Unternehmen sollte größer werden.

Das gerade Gesagte ist logisch, oder? Keine Raketenwissenschaft, genau darum geht es ja in der kontinuierlichen Produktentwicklung, gerade auch in Abgrenzung zum einmaligen Projektgeschäft.

Team

Dann lass uns auf die zweite Dimension blicken: Das Team. Du solltest das Team in einem besseren Zustand hinterlassen, als du es vorgefunden hast. Das Team ist schließlich der Dreh- und Angelpunkt. Es gibt üblicherweise keine weiteren Produktions-”Ressourcen” als das Team. Je besser der Zustand des Teams, desto besser die Produktentwicklung. Aber... wie definiert man den Zustand eines Teams? Als Anhaltspunkte könnten die folgenden fünf Kriterien dienen:

1. Effektivität
2. Effizienz
3. Fähigkeiten
4. Vertrauen
5. Motivation

Ein Team ist effektiv, wenn die umgesetzten Features einen tatsächlichen Impact generieren. Du willst einen Nutzen für Anwender und Nutzen generieren. Features sind kein Selbstzweck, sondern nur Mittel zum Erreichen des Ziels. Wenn jedes neue Feature messbar den Nutzen erhöht, seid ihr extrem effektiv. Wenn ihr Software liefert, die theoretisch funktioniert, aber von niemandem genutzt wird, produziert ihr nur waste. Um hier besser zu werden, könntet ihr einerseits in Richtung Validierung schauen, also wie ihr mögliche Ideen bereits vor der Umsetzung auf ihren Impact überprüft, und andererseits natürlich messen, messen und messen.

Mit Effizienz meine ich die Schnelligkeit und den Aufwand, mit dem neue Ideen entwickelt, validiert und umgesetzt werden können. Wie gut ist das Team darin, aus einer Vielzahl von Problemen, Anforderungen und Lösungsideen die erfolgversprechendsten auszuwählen?  Können diese Ideen schnell und günstig umgesetzt werden? Wenn ihr Retros durchführt, dann arbeitet ihr eigentlich kontinuierlich an der Verbesserung der Effizienz. Ihr müsst nur dafür sorgen, dass die Retros nicht zu einer Scheinveranstaltung degradieren.

Die nächsten drei Punkte haben auch einen Einfluss auf Effektivität und Effizienz, ich möchte sie auf Grund ihrer Bedeutung aber explizit hervorheben.

Fähigkeiten sind die individuellen Fähigkeiten von dir und deinen Teammitgliedern. Es sind sowohl soziale Fähigkeiten wie z.B. Kommunikation, es sind methodische Fähigkeiten wie Product Discovery und natürlich fachlich/technische Fähigkeiten wie Datenbankdesign. Dein Team soll in einem besseren Zustand als vorher sein? Dann sollte jedes Teammitglied seine individuellen Fähigkeiten verbessern. Learning on the job, Schulungen, job rotation... die Möglichkeiten sind grenzenlos. Ihr müsst es nur tun.

Kommen wir zu Vertrauen. Eine Atmosphäre der Sicherheit und des Vertrauens im Team ist Voraussetzung dafür, dass Probleme überhaupt angesprochen werden und nicht unter den Teppich gekehrt werden. Vertrauen ist Voraussetzung dafür, dass ihr euch gegenseitig konstruktives Feedback gebt. Vertrauen ist Voraussetzung dafür, dass Verbesserungsvorschläge (der sprichwörtliche “Elefant im Raum”) tatsächlich angesprochen werden. Sorgt insofern dafür, dass der Grad des Vertrauens steigt.

Und schließlich Motivation. Als Product Owner bist du darauf angewiesen, dass ihr alle, das gesamte Team, aus eigenem Antrieb handelt. Ihr arbeitet nicht, weil man euch zwingt oder belohnt, sondern weil ihr es wollt. Nur so könnt ihr komplexe Probleme lösen und kreative Ideen entwickeln - Kreativität kann man schließlich nicht anordnen (so, jetzt sei bitte mal 2 Tage kreativ). Arbeitet daher gemeinsam daran, ein Umfeld zu schaffen, welches eure jeweiligen Motivatoren befeuert. Das ist echte Arbeit, die du genau wie die eigentliche Produktentwicklung einplanen kannst.

Mit diesen fünf Anhaltspunkten kannst du einschätzen, ob du dein Team langfristig in einem besseren Zustand hinterlässt, oder ob du kurzfristigen Raubbau betreibst.

Technologie

Mit Blick auf Technologie beobachte ich immer wieder ein Verhalten, welches a) überhaupt nichts mit Stewardship zu tun hat und b) ich auch aus Unternehmenssicht für völlig irrational halte. Lass mich hier mal etwas ausholen.

Informationstechnologie begleitet uns inzwischen seit Jahrzehnten. Ungefähr seit den 70er Jahren werden die Kernprozesse von Unternehmen durch IT unterstützt. Diese zentralen Anwendungen wurden und werden immer wieder technisch modernisiert, z.B. Mainframe – Client/Server – Cloud oder auch Assembler – Cobol – Java. Außerdem wurde und wird der Funktionsumfang mehr oder weniger kontinuierlich erweitert oder adaptiert. Interessanterweise erfolgt die technische Modernisierung meistens in der Form von gigantischen Projekten.

Vielleicht hast du das folgende Szenario auch schon einmal erlebt.

• Eine bestehende Anwendung wird jahrelang funktional erweitert
• Hinweise auf bessere Technologien werden ignoriert
• Hinweise auf die drohende Abkündigung einer Technologie werden ignoriert
• Irgendwann hilft Ignoranz nicht mehr weiter – es muss gehandelt werden
• Ein Neubau der Anwendung wird aufgesetzt, modern, state of the art, ...
• Es wird festgestellt, dass die existierende Anwendung im Laufe der Zeit deutlicher komplexer und umfangreicher geworden ist als gedacht
  • Die Projektlaufzeit des Neubaus verlängert sich deutlich und mehrfach
  • Die Kosten explodieren
  • Die Weiterentwicklung des Altsystems stagniert, Innovationen können nicht umgesetzt werden
  • Der Neubau bietet weniger Funktionen als das Altsystem
  • Der Neubau frisst die Aufmerksamkeit des halben Unternehmens
  • Alle Beteiligten sind gestresst
• Irgendwie und mit ungeheuren Schmerzen wird der Neubau „durch die Tür“ geprügelt und alle sind froh, dass „es“ endlich vorbei ist

Klingt dieses Szenario wie ein Vorgehen, das Unternehmen anstreben sollten? Aus meiner Sicht nicht. Wieso passiert es dann? Nicht nur einmal, sondern immer wieder? Gerne auch mehrfach im gleichen Unternehmen?

Meine Hypothese ist, dass die beteiligten Personen eine zu kurzfristige Sichtweise haben und gerade nicht das Interesse haben, ihr Produkt in einem technisch besseren Zustand zu hinterlassen.

Schau dir mal die rote Linie der Skizze an. Die Kamelhöcker sind die Neubauprojekte. Viel interessanter sind aber die Zeitpunkte dazwischen:

• Zu den Zeitpunkten 5 und 6 heißt es vermutlich „wir haben so viel in das Projekt investiert, wir müssen unsere Ausgaben reduzieren“
• Zu den Zeitpunkten 7 und 8 ahnen die Verantwortlichen, dass sie sich idealerweise um eine Modernisierung kümmern müssten, aber es hält ja noch eine Weile und danach betrifft es sie wegen Jobwechsel nicht mehr
• Zu den Zeitpunkten 9 und 10 wissen die Verantwortlichen, dass sie um die Modernisierung nicht herumkommen, wollen sich den Stress aber nicht antun und setzen weiter auf das Prinzip Hoffnung

Wäre eine kontinuierliche Investition in den Erhalt, in die technische Modernisierung von Kernanwendungen, nicht sehr viel sinnvoller? Das würde vermutlich noch nicht einmal mehr Geld kosten, die Zahlungen wären nur anders auf die Zeitpunkte verteilt (siehe grüne Linie). Unternehmen würden sich aber den funktionalen Stillstand und den Stress während der Neubauprojekte sparen. Genau das meine ich mit Stewardship. Hinterlasse dein Produkt in einem besseren Zustand, als du es vorgefunden hast.

Fazit

Ich bin davon überzeugt, dass es im Interesse des Unternehmens, des Produktentwicklungsteams und auch von dir als Product Owner ist, “Stewardship” in der Produktentwicklung zu praktizieren. Es ist sinnvoll, sowohl den Nutzen, das Team und die Technologie in einem besseren Zustand zu hinterlassen. Ist das einfach? Nein. Es kommen dir immer die kurzfristigen und dringenden Anfragen dazwischen. “Kannst du nicht gerade noch XY umsetzen, bevor ihr die Testautomatisierung weiterführt?”. Der Klassiker. Nicht falsch verstehen: Die Zukunft ist nicht alles. Wenn du heute keinen Nutzen generierst, gibt es dein Produkt morgen nicht mehr. Wenn deine Technologie heute nicht funktioniert, musst du dir um mögliche Verbesserungen in 2 Jahren keine Gedanken machen. Es geht nicht um entweder-oder, sondern um sowohl-als auch. Einer meiner Mentoren hat es schön auf den Punkt gebracht: One foot in today, one foot in tomorrow.