Agilität in der Entwicklung ist keine Garantie für ein erfolgreiches Produkt. Sie ist eine lokale Optimierung, die den kompletten Wertstrom nur unzureichend beeinflusst. Dennoch ist agile Entwicklung der erste große Schritt die Vorgehensweise an die Realität anzupassen: Kein Wasserfallprojekt kann mit der komplexen sich schnell ändernden Welt mithalten, schnelle Experimente und notwendige Kursanpassungen ermöglichen.
Von Wasserfall zu Produktteams
Aus der klassischen Projektwelt kommend, wurde die Software- und Produktentwicklung weiterhin in Projekten abgewickelt. Man hat schon früher erkannt, dass das klassische Projektmanagement und eine Projektstruktur zwar gut für vorhersehbare Ergebnisse geeignet ist, allerdings im komplexen Umfeld ihre Schwächen zeigt. Vom Wasserfall über das agile Projekt kam die Zeit der Produktorganisation. Diese versucht möglichst alle an der Produktentwicklung beteiligten Akteure zu vereinen, um möglichst den kompletten Wertstrom optimieren zu können.
Bereits in der agilen Entwicklung mit DevOps lösen sich die Silos zwischen Anforderungsmanagement, Design, Entwicklung, Test und Betrieb auf. Der Business ist oftmals jedoch entkoppelt von der Entwicklung. Es werden Features geplant und an die Entwicklung weitergegeben, wie an einen internen Dienstleister. Das Umsetzungsteam kümmert sich nur darum, dass das Feature richtig umgesetzt wird. Ob das Feature einen Wert beim Kunden erzeugt, das ist die Aufgabe der Planung (Business).
Produktteams, die entlang der Wertströme arbeiten, beziehen auch den Business in das Produkt ein: So sollen alle das Produkt betreffende Entscheidungen durch das Team getroffen werden können. Gemeinsame Planung, gemeinsame Verantwortung und verbesserte Kommunikation sorgen für schnellere nutzbare Ergebnisse und höhere Qualität.
Übergang von Projekt- zu Produktorganisation
Beim Übergang von einer Projekt- zur Produktorganisation (Produktteams) muss den Engpässen besondere Aufmerksamkeit geschenkt werden, um einen durchgängigen Wertstrom zu ermöglichen. In klassischen Projekten waren die einzelnen Stufen der Wertschöpfung entkoppelt, was zu Verzögerungen, Kommunikationsproblemen und nicht zuletzt zu Qualitätseinbußen führte. Besonders gravierend sind diese Engpässe in der Softwareentwicklung, wo die Wertströme und die Kommunikation nicht linear, sondern in Schleifen und Netzwerken ablaufen. Daher ist es wichtig, dass alle an der Produktentwicklung beteiligten Personen als ein Team eng zusammenarbeiten: Örtlich und organisatorisch. Dazu zählen nicht nur Entwickler und Tester, sondern auch Business. Nur so ist es möglich in einer agilen Produktpipeline kundenzentriert zu entwickeln. Sind weitere Gewerke in die Produktentstehung involviert (z.B. Infrastruktur oder Hardware), müssen sie ebenfalls eng eingebunden sein. Alle Optimierungen würden somit den kompletten Wertstrom betreffen, nicht nur lokale Teilabschnitte.
Entscheidungen im Produktteam werden gemeinschaftlich getroffen, wobei alle Perspektiven des Teams einbezogen werden. Ein crossfunktionales Team kann durch die Zusammenarbeit von Business, Design und Entwicklung höhere Qualität erreichen als bei Entscheidungen, die rein durch das Business oder in einzelnen Silos getroffen werden.
Produktentwicklung ist auch ein anderes Mindset
Das Ziel eines Projekts besteht darin, den Plan innerhalb des vereinbarten Zeitrahmens, des vereinbarten Umfangs und des vereinbarten Budgets zu erfüllen. Der Fokus liegt eindeutig auf dem Output, also auf dem, was geliefert wird. Die Transformation zum Produkt verlagert den Fokus auf den Outcome, also darauf, welchen Wert das Produkt für den Kunden und das Unternehmen generiert. Das Team versucht nicht mehr, fünf neue Features einzuführen. Stattdessen konzentriert es sich darauf, die Anzahl der Registrierungen zu erhöhen, die Absprungrate zu verringern und die Nutzungsdauer des Produkts zu verbessern.
Das „Produktmindset“ unterscheidet sich vom „Projektmindset“ dadurch, dass es das Team dazu anregt, nicht nur einmalige Pläne zu erstellen, sondern kontinuierliche Abläufe zu entwickeln, die sich permanent wiederholen. Dabei werden nicht nur die Entwicklung und Bereitstellung („haben wir es richtig umgesetzt?“) in Kadenzen organisiert, sondern auch die Anforderungsanalyse („haben wir das Richtige umgesetzt?“) und das Design. Der Kundenkontakt ist eine kontinuierliche Aufgabe des Produktteams und keine einmalige Angelegenheit des User Research Teams, die lediglich ein Projekt durchgeführt haben.
Das Team strebt nach dem Product-Market-Fit und der Möglichkeit der Skalierung, solange das Produkt nicht abgekündigt ist. Es werden neue Erkenntnisse gewonnen, neue Technologien entdeckt und neue Marktgegebenheiten akzeptiert, damit sich das Produkt anpassen kann.
Produktentwicklung ist Risikomanagement
Im klassischen Projekt wird Risikomanagement betrieben. Es wird versucht, möglichst viele Risiken zu Beginn des Projektes zu identifizieren und entsprechend zu behandeln. Die meisten dieser Risiken konzentrieren sich auf die Umsetzung im Projekt, den Output, die entsprechenden Zeitpläne und Budgets. Bei digitalen Produkten ist das Risikomanagement aufgrund der Komplexität und Veränderlichkeit des Marktes eine permanente Aufgabe im Team. Mit agilen Methoden wird versucht, Risiken frühzeitig zu erkennen und zu minimieren. Gerade in Projekten liegt hier der Fokus auf den Umsetzungsrisiken: Was hindert uns daran, das Ziel erfolgreich zu erreichen? Das größte Risiko wird dabei aber übersehen: Was passiert, wenn die Kunden unser Produkt nicht annehmen? Produktteams müssen daher bereits vor der Umsetzung das Wertrisiko validieren und gegebenenfalls die ursprüngliche Idee modifizieren (Pivot).
Anders als in Projekten, muss die Produktentwicklung die Risiken im Vorfeld angehen. Die sogenannte Product Discovery hat die Aufgabe vor der Entwicklung folgende Fragen zu beantworten und die entsprechenden Risiken zu minimieren:
- Werden die Kunden das Produkt kaufen?
- Wird das Produkt einfach zu nutzen sein?
- Können wir das Produkt bauen?
Mit Hilfe von MVPs und Experimenten soll der Kundenkontakt gesucht werden, um vor der Entwicklungsphase das Risiko zu minimieren, dass man ein Produkt am Markt vorbei entwickelt. Agilität nur in der Entwicklung kann das nicht gewährleisten (siehe Agile Produktpipeline).
