Marty Cagan - Inspired

5 Ganz Ähnliches gilt für die Rolle des Designs. Die Sache ist schon viel zu weit vorangeschritten, um dem Design zu seinem tatsächlichen Wert zu verhelfen, und was hier geschieht, sind in erster Linie »kosmetische Maßnahmen«. Der Schaden ist bereits angerichtet und wir versuchen jetzt bloß, eine Schicht Farbe darüberzupinseln. Die UX-Designer wissen, dass das nicht gut ist, aber sie geben sich Mühe, es so nett und stimmig wie möglich aussehen zu lassen.

6 Die vielleicht größte verpasste Chance in diesem Modell ist die Tatsache, dass die technische Seite viel zu spät ins Spiel gebracht wird. Wir sagen, wenn Sie Ihre Programmierer nur zum Coden einsetzen, nutzen Sie nur ungefähr die Hälfte ihres Wertes. Das kleine Geheimnis der Produkterstellung lautet, dass Programmierer typischerweise die beste Innovationsquelle sind; trotzdem werden sie bei diesem Prozess nicht mal zur Party eingeladen.

7 Nicht nur das Engineering wird viel zu spät eingebracht, sondern auch die Prinzipien und wichtigsten Vorzüge von Agile treten viel zu spät auf den Plan. Teams, die Agile auf diese Weise nutzen, schöpfen vielleicht 20 Prozent des tatsächlichen Wertes und Potenzials der Agile-Methoden aus. Was man hier wirklich sieht, sind Agile-Methoden bei der Delivery, aber der Rest der Organisation und des Kontextes ist alles andere als agil.

8 Dieser gesamte Prozess ist sehr projektlastig. Das Unternehmen finanziert Projekte, stellt Personal für Projekte ab, drückt Projekte durch und führt schließlich Projekte aus. Leider sind Projekte aber Output und beim Produkt geht es in erster Linie um Resultate. Dieser Prozess führt vorhersehbar zu verwaisten Projekten. Irgendetwas wird am Ende schon dabei herauskommen, aber es erfüllt die Erwartungen nicht. Also worum ging es bei der ganzen Sache eigentlich? Auf jeden Fall ist das ein ernst zu nehmendes Problem und hat nichts damit zu tun, wie wir Produkte erstellen sollten.

9 Der größte Schwachpunkt des guten alten Wasserfallprozesses war schon immer und bleibt auch weiterhin, dass das gesamte Risiko am Ende liegt, und das bedeutet, dass die Kundenvalidierung viel zu spät erfolgt.Das Grundprinzip von Lean-Methoden ist die Reduzierung von Überflüssigem und eine der entscheidendsten Formen des Überflüssigen ist es, eine Funktion oder ein Produkt zu gestalten, zu schaffen, zu testen und einzuführen, nur um festzustellen, dass es nicht das ist, was benötigt wird. Die Ironie an der Sache ist, dass viele Teams glauben, sie würden Lean-Prinzipien anwenden; stattdessen folgen sie aber nur den grundlegenden Prozessen, die ich gerade beschrieben habe. Dann erkläre ich ihnen, dass sie Ideen auf eine der teuersten und langsamsten Arten ausprobieren, die uns bekannt ist.

10 Und während wir mit diesem Prozess beschäftigt sind und Zeit und Geld vergeuden, zeigt sich am Ende für gewöhnlich der größte Verlust von allen, nämlich in Form der Opportunitätskosten dessen, was die Organisation stattdessen hätte tun können und sollen. Wir können uns diese Zeit und dieses Geld nicht zurückholen.

Kein Wunder, dass so viele Unternehmen so viel Zeit und Geld verschwenden und so wenig dafür zurückbekommen. Ich habe Sie gewarnt, dass das Ganze ein bisschen deprimierend werden könnte. Aber Sie sollten genau verstehen, warum Ihr Unternehmen seine Arbeitsweise ändern muss, vorausgesetzt natürlich, dass es tatsächlich auf diese Weise arbeitet.

Kein Wunder, dass so viele Unternehmen so viel Zeit und Geld verschwenden und so wenig dafür zurückbekommen.

Die gute Nachricht ist: Ich verspreche Ihnen, dass die besten Teams überhaupt nicht so vorgehen, wie ich es gerade geschildert habe.

Die Menschen suchen immer nach einem Königsweg für die Produktentwicklung und ihnen steht eine bereitwillige Industrie gegenüber, die ihnen mit Büchern, Coaching, Training und Consulting unter die Arme greifen will. Aber es gibt keinen Königsweg und das finden die Leute unweigerlich irgendwann heraus. Dann erfolgt die Gegenreaktion. Während ich dies schreibe, ist es gerade modern, sowohl Lean als auch Agile zu kritisieren.

Ich bezweifle nicht, dass viele Menschen und Teams bis zu einem gewissen Grad enttäuscht sind von den Ergebnissen, die sie mit der Anwendung von Lean sowie Agile erzielt haben. Und ich verstehe die Gründe dafür. Gleichwohl bin ich davon überzeugt, dass die Werte und Prinzipien von Lean und Agile dauerhaft gültig sind. Nicht so sehr die speziellen Ausprägungen dieser Methoden, die viele Teams heutzutage anwenden, sondern die dahinterstehenden Kernprinzipien. Ich bin der Meinung, dass sie beide einen bedeutsamen Fortschritt repräsentieren, und würde an diesen beiden Fronten keinerlei Rückschritte machen wollen.

Aber wie gesagt, auch Lean und Agile sind nicht der Königsweg, und wie bei jedem Tool muss man auch bei ihrer Nutzung klug vorgehen. Ich begegne zahllosen Teams, die für sich beanspruchen, den Lean-Prinzipien zu folgen; doch dann arbeiten sie monatelang an etwas, das sie als MVP bezeichnen, und sie haben wirklich keine Ahnung, was sie da haben und ob es sich verkaufen wird, bis sie eine Menge Zeit und Geld hineingesteckt haben – was kaum im Sinne der Lean-Prinzipien sein dürfte. Oder sie schießen weit übers Ziel hinaus und glauben, sie müssten alles testen und validieren, sodass sie sich total verzetteln.

Und wie ich gerade erläutert habe, wird Agile in den meisten Produktunternehmen auf eine Art angewendet, die rein gar keinen erkennbaren Bezug zu Agile-Methoden aufweist.

Die besten mir bekannten Produktteams sind bereits einen Schritt weiter als die meisten Teams, die diese Methoden praktizieren – sie nutzen die Kernprinzipien von Lean und Agile, aber erweitern die Bandbreite dessen, was sie zu erreichen versuchen und wie sie dabei vorgehen.

Diese Teams haben vielleicht eine etwas andere Auffassung von der Problemstellung und verwenden gelegentlich andere Begrifflichkeiten, aber im Kern erkenne ich drei übergreifende Prinzipien:

1 Risiken werden im Vorfeldbehandelt, nicht erst am Ende.In modernen Teams behandeln wir Risiken, bevor wir uns entschließen, irgendetwas zu entwickeln. Zu diesen Risiken gehören Value Risks (ob die Kunden das Produkt kaufen), Usability Risks (ob die Anwender herausfinden, wie man es benutzt), Feasibility Risks (ob unsere Programmierer das, was wir brauchen, mit der uns zur Verfügung stehenden Zeit, den Kompetenzen und der Technologie entwickeln können) und Business Viability Risks (ob diese Lösung auch für die verschiedenen Aspekte unseres Geschäfts funktioniert – Sales, Marketing, Finanzabteilung, Rechtsabteilung und so weiter).

2 Die Produkte werden kollaborativstatt sequenziell bestimmt und gestaltet.Sie haben das alte Modell bereits hinter sich gelassen, bei dem ein Produktmanager die Anforderungen festlegt, ein Designer eine Lösung gestaltet, die diese Anforderungen erfüllt, und dann die Programmierer diese Anforderungen umsetzen, wobei jeder mit den Restriktionen und Entscheidungen der vorherigen Personen klarkommen muss. In starken Teams arbeiten Product Management, Design und Engineering Seite an Seite, sie geben und sie nehmen, um eine technologiegetriebene Lösung zu finden, die ihre Kunden begeistert und für ihr Geschäft funktioniert.

3 Letztlich geht es nur darum, Probleme zu lösen,und nicht, Funktionen zu implementieren.Bei konventionellen Product Roadmaps dreht sich alles um Output. Starke Teams wissen, dass es nicht nur um die Implementierung einer Lösung geht. Sie müssen gewährleisten, dass diese Lösung das zugrunde liegende Problem auch tatsächlich löst. Es geht um Geschäftsergebnisse.

Sie werden sehen, dass ich diese drei übergeordneten Prinzipien innerhalb des gesamten Buches immer wieder in den Mittelpunkt stelle.