Wohnung putzen mit dem Minimum Viable Product

„MVP“ – Minimum Viable Product – ist ein verbrannter Begriff. Er wurde missbraucht, um eine Brücke zwischen dem klassischen und dem agilen Projektmanagement zu schlagen. Arbeitspakete des Projektablaufplans werden kurzerhand zu MVPs umgetauft – so wirkt alles schon viel agiler. Dabei wird jedoch eines vergessen: Ein MVP ist ein Produkt, das mit seinen Eigenschaften bereits die minimalen Anforderungen des Kunden abdeckt. Ein Produkt, das in sich geschlossen ist und einen Mehrwert bietet. Etwas, das schon verkauft werden könnte und wofür der Kunde bezahlen würde. Wenn der Kunde beispielsweise sagt, er möchte von Punkt A zu Punkt B gelangen, dann ist ihm mit einem Reifen nicht geholfen. Dazu benötigt er schon ein Fortbewegungsmittel, das seiner wichtigsten Anforderung – der Fortbewegung – genügt. Aufbauend auf diesem MVP können anschließend weitere Anforderungen hinzugefügt werden – der Kundennutzen wächst und ein neues MVP entsteht. Trotzdem fällt es vielen schwer, die Übertragung aus der klassischen Welt mit ihrer Meilensteinplanung hin zur Customer Journey mit MVPs und einem Releaseplan nachzuvollziehen. Für den Ausbruch aus diesen eingefahrenen Denkmustern braucht man manchmal aber nur einen kreativen Ansatz, um den Zusammenhang klarer zu machen. Was eignet sich dafür besser als eine alltägliche Situation?

Putzen Sie Ihre Wohnung – MVP 1

Angenommen, der Wohnungsputz wird hauptsächlich von Ihrer Partnerin oder Ihrem Partner durchgeführt. Stellen Sie sich vor, sie wollen ihr oder ihm diese Aufgabe nun einmal komplett abnehmen. Wo fangen Sie an zu putzen? Welche Räume nehmen Sie sich vor? Und die wichtigste Frage: Wie viel müssen Sie putzen, damit sie oder er zufrieden ist, Sie aber nicht mehr als nötig gemacht haben? Dafür ist für Sie wichtig zu wissen, was der „Putz-Standard“ bei Ihnen zuhause ist. Die Mindestanforderungen Ihrer Partnerin oder Ihres Partners an den Wohnungsputz sind ein wichtiger Teil der Vorbereitung. Sinnvoll ist es außerdem, die Aufgaben zu sammeln, die in der gesamten Wohnung regelmäßig anfallen. Diese Aufgaben können gut den jeweiligen Räumen zugeordnet werden. So entsteht eine in Rubriken strukturierte Sammlung wie „Wohnzimmer“, „Küche“, „Bad“ und „Schlafzimmer“. Diese Rubriken können Sie mit Themenklammern gleichsetzen, also sogenannten Epics.
Wenn Sie nun also wissen, dass Ihre Partnerin oder Ihr Partner glücklich ist, wenn in jedem Raum gewisse Aufgaben erledigt sind, so ergibt sich für Sie eine Anzahl an Aufgaben, die in Summe das MVP ergeben. Nach der Erledigung sämtlicher Aufgaben, die zur Erfüllung des MVPs beitragen, kann das Ergebnis vorgeführt werden. Sie werden recht schnell merken, ob Ihre Überraschung geglückt ist und Sie alle Anforderungen erfüllt haben!

Stellen Sie sich vor, die Schwiegermutter kommt zu Besuch – MVP 2

Nun ist also Ihre Partnerin oder Ihr Partner durch dieses MVP zufrieden gestellt. Was passiert allerdings, wenn sich spontan die Schwiegermutter mit einem Besuch ankündigt? Dann muss das ursprüngliche MVP ein bisschen erweitert werden. Und zwar um genau die Aufgaben, die dabei helfen, auch die Schwiegermutter zufrieden zu stellen. Die Anforderungen aus dem ersten MVP bestehen weiterhin, es gibt jedoch Aufgaben, die es ergänzen. Das Gesamtpaket ergibt dann ein neues MVP.
Die gleiche Vorgehensweise kann auch in der Produktentwicklung angewendet werden. Auch dort sollte angestrebt werden, mit einem ersten Produkt, das dem Kunden einen Mehrwert bietet, den Markt bedienen zu können. Somit kann erstes Kundenfeedback frühestmöglich in die nächste Iteration einfließen. Außerdem lassen sich mit diesem Ansatz Fehlinvestitionen vermeiden und somit das Risiko minimieren, indem früh erkannt wird, ob eine Weiterentwicklung des MVP rentabel ist und welche Funktionalitäten vom Kunden überhaupt gewünscht und bezahlt werden.
Allgemein ist, wie auch beim Wohnungsputz, dabei zu berücksichtigen, wer die Zielgruppe des Produkts ist. So können Unternehmen entlang der Customer Journey ein Produkt entwickeln, das die rentabelsten Funktionalitäten enthält und die Kundenbedürfnisse befriedigt. Im Gegensatz zur klassischen Produktentwicklung setzt der Cashflow hierbei wesentlich früher ein, die Reaktions- sowie Entwicklungszeiten sind kürzer und der Kunde steht im Zentrum der Überlegungen. Der Trick ist also eine geänderte Perspektive auf die Produktentstehung.

Agiles Demand Management im skalierten Umfeld

Klassische Unternehmensbereiche und Scrum treffen oft aufeinander. Fast immer stellt sich dabei auch folgende Frage: Wie kann beides auf einen Nenner gebracht werden? Diese Frage stellt sich auch beim Anforderungsmanagement. Denn im grundlegenden Konzept von Scrum gibt es lediglich die Rollen Product Owner, ScrumMaster und Entwicklungsteam – Boris Gloger hat das Konzept um die Rollen Kunde, Management und Nutzer erweitert. Das klassische Demand Management wie in Großkonzernen, bei dem interne Anforderungen bewertet und gesteuert werden, findet sich in keiner der Rollen direkt wieder.
Der täglichen Arbeit des Anforderungsmanagements kommt die Rolle des Kunden noch am nächsten. Er liefert dem Product Owner jene Impulse, die er in eine Vision bündelt, um dem Entwicklungsteam die richtige Orientierung zu geben. Nun werden in einem Großkonzern auf eine entwickelnde Abteilung jedes Jahr hunderte Anforderungen aus allen Teilen des Unternehmens eingesteuert. Hier reicht die Rolle des methodisch sauber aufgesetzten Kunden nicht mehr aus, um die Anforderung zu handhaben.

Eine Lösung: das Demand Management Team

Doch für diese Problematik im skalierten Umfeld ist die Lösung leichter als gedacht. Bei einer größeren Anzahl von Scrum-Teams wird zwischen Kunde und Chief Product Owner (CPO) ein vorgelagertes Scrum-Team aufgesetzt: das Demand Management Team. Es arbeitet in regulären Sprints und übergibt im Refinement dem CPO die evaluierten und spezifizierten Anforderungen. Bei diesem Refinement können bzw. sollten neben dem CPO und dem Demand Management durchaus auch andere Experten anwesend sein. Schließlich kann ab einem bestimmten Komplexitätsgrad eine einzelne Person nicht die fachliche Tiefe mitbringen, um für Großprojekte alle Anforderungen adäquat zu priorisieren und den Return on Investment bewerten zu können.
Nach dem Overall Refinement werden die Anforderungen in den Sprintzyklen der skaliert zusammenarbeitenden Scrum-Teams bearbeitet. Am Ende des Sprints tritt das Demand Management wieder auf den Plan, um den Kunden und seine zu Beginn des Sprints eingesteuerten Anforderungen im “Overall Review” zu vertreten. Hier hat das Demand Management auch die Möglichkeit, Änderungen des Kunden zu kommunizieren. Sollte es der Kunde einfordern, ist das Demand Management in der Rolle des Transmitters nach diesem Termin auch aussagekräftig zu Zwischenständen und Teillieferungen. In der darauf folgenden “Overall Retro“ wird neben den projektübergreifenden Learnings auch der Rahmen aufgespannt, um die Zusammenarbeit zwischen Demand Management und CPO zu evaluieren und langfristig zu verbessern.
In der Praxis funktioniert diese Lösung sehr gut, dennoch sollten einige Voraussetzungen erfüllt sein, um den Übergang in die Agilität zu vereinfachen. Im ersten Schritt sollten die betroffenen Personen zu einem frühzeitigen Zeitpunkt inhaltlich und methodisch auf den gleichen Wissensstand gesetzt werden, sodass alle Beteiligten die gleiche Vorstellung von Begrifflichkeiten oder Artefakten haben. Sind Methode und Inhalte, sowie deren Anwendung klar, kann im finalen Schritt die Integration eines eigenen Scrum-Teams “Demand Management” angestrebt werden.

Foto: CC0 Creative Commons, pixabay – ulrichw