Wie Sie den MVP-Ansatz für vorhandene Anwendungen nutzen können

Foto des Autors
Werner Beckmann

Das Minimum Viable Product (MVP) hilft Ihnen in der Produktentwicklung, zentrale Annahmen früh zu überprüfen. Dabei gilt: besser früh und kostengünstig lernen als spät und teuer. In der Neuentwicklung von Produkten setzen Unternehmen daher den MVP-Ansatz neben Prototyp und Proof-of-Concept häufig ein, um den Nutzen der Produkte zu optimieren.

Das Minimum Viable Product (MVP) hilft Ihnen in der Produktentwicklung, zentrale Annahmen früh zu überprüfen. Dabei gilt: besser früh und kostengünstig lernen als spät und teuer. In der Neuentwicklung von Produkten setzen Unternehmen daher den MVP-Ansatz neben Prototyp und Proof-of-Concept häufig ein, um den Nutzen der Produkte zu optimieren.

Die Grundidee des MVP ist die Validierung von Annahmen durch den Markt: echte Anwender verwenden das Produkt in echten Prozessen. Hierdurch erkennen Sie schnell, ob der geplante Nutzen des Produktes tatsächlich wie angenommen vom Anwender realisiert wird. Mit den Lernerfahrungen steuern Sie die weitere Produktentwicklung, um den Nutzen zu maximieren.

In der Entwicklung von Software-Produkten wie ERP-Systemen, Webshops, Smartphone-Apps etc. arbeitet man meist jedoch nicht auf der grünen Wiese, da häufig schon Anwendungen vorhanden sind. So werden beispielsweise ERP-Systeme über Jahre hinweg aufgebaut und immer wieder erweitert. In der Regel erwarten Anwender sogar einen weiteren Ausbau im Rahmen der Pflege und Weiterentwicklung.

Wie können Sie die Vorteile auch für bestehende Anwendungen nutzen?

Meiner Erfahrung nach erleichtert die vorhandene Basis sogar die Umsetzung des nächsten MVP:

  • Grundlegende Funktionen wie Login, Security und Protokollierung sind schon vorhanden.
  • Die Anwender sind mit Design und Usability-Standards bereits vertraut.
  • Prozesse wie Release, Support, Fehlermeldungen und Kundeninformationen sind häufig schon eingespielt.

Der Aufwand für Erweiterungen ist daher im besten Fall sogar deutlich geringer als bei einem neuen Produkt: Sie können Ihre Annahmen noch kostengünstiger validieren!

In schnellen Schritten zum MVP

Das Vorgehen entspricht bei Erweiterungen den Schritten für ein MVP bei einer Neuentwicklung:

  • Erforschen Sie die genaue Zielgruppe und deren Bedürfnisse.
  • Wählen Sie Anforderungen mit hohem Nutzen aus, meist ein fachlich zusammenhängendes Thema.
  • Klären Sie, was genau Sie durch das MVP herausfinden möchten, beispielsweise: Sind die Kunden bereit, für eine Erweiterung einen Aufpreis zu zahlen? Werden die Anwender das Feature täglich verwenden?
  • Bestimmen Sie den funktionalen Mindestumfang der Anforderungen – das MVP darf nicht zu groß werden.
  • Setzen Sie die Anforderungen mit dem Team um und nehmen Sie die Lösung produktiv.
  • Holen Sie sich Feedback der Anwender und Kunden ein: durch Umfragen oder durch anonymisierte Messungen von benutzten Funktionen etc.
  • Bewerten Sie die gesammelten Erkenntnisse: macht es Sinn, das Thema weiter auszubauen? Oder sind andere Themen wichtiger?

Scheuen Sie sich nicht, Themen ruhen zu lassen, falls die Erkenntnisse aus dem MVP dies nahelegen!

Photo by Alex Bagirov on Unsplash

Wenn das Backlog dem MVP im Weg steht

Nach einem funktional noch eingeschränkten, allerersten MVP-Release kommen viele gute Ideen und dringende Wünsche auf Sie zu:

  • Sie erhalten von Anwendern und Kunden viele, oft kleinteilige Anforderungen.
  • Ihr Produktbacklog wächst rasant, dabei enthält es noch alte Bugs mit geringer Priorität.
  • Sie kommen kaum noch hinterher, um die Anforderungen zu erfassen und zu verwalten, geschweige denn, sie umzusetzen.

Bei einer größeren, vorhandenen Anwendung stauen sich dementsprechend viele Anforderungen. Und wo bleibt da der Raum für Innovationen, mit denen Sie sich den Vorsprung vor der Konkurrenz sichern können?

Zielorientiert und transparent planen mit Hilfe der agilen Etappenplanung

Häufig planen Product Owner und Teams nur die nächsten paar Sprints. Damit Sie Ihre Ziele nicht aus dem Blick verlieren und den Wald vor lauter Bäumen noch sehen, benötigen Sie eine Planung für die nächsten, längeren Zeitabschnitte. Diese Sichtweise konzentriert sich auf die inhaltlichen, meist wirtschaftlich motivierten Ziele und nicht auf die Umsetzungsschritte.

Häufig definieren Unternehmen dabei ein Quartal als eine Etappe und beschreiben, was sie im Zeitabschnitt erreichen möchten. In der Regel umfasst diese Planung mehrere Teams, um Abhängigkeiten, Zuordnungen und Möglichkeiten aufzuzeigen.

Wichtig ist, dass Sie für diese Planung alle vorliegenden Daten nutzen: bereits geschätzter Umfang der Anforderungen, Velocity der Teams, wichtige Termine wie Kundenveranstaltungen, Messen und andere. Im Zweifel müssen Sie Annahmen treffen – und diese als Annahmen kenntlich machen!

Vorteile und Nebenwirkungen

Noch wichtiger ist, dass Sie die Stakeholder einbeziehen. Meist sind dies die Ersteller der Anforderungen in den Fachbereichen sowie am Zielprozess beteiligte Akteure. In der Diskussion sorgt die Etappenplanung für Transparenz und führt häufig zur überraschenden Erkenntnis, dass Zeit- oder Aufwandsziele nicht realistisch sind. Hierin liegt der wesentliche Nutzen der Etappenplanung: die Abstimmung der Beteiligten herzustellen! Und das regelmäßig – so schaffen Sie nicht nur Transparenz, sondern auch Vertrauen durch die Berücksichtigung der Bedürfnisse der Beteiligten.

Sie können dieses Alignment fördern durch nachvollziehbare Priorisierung von Anforderungen. Typischerweise haben Stakeholder eine klare, oft intuitive Vorstellung über die Dringlichkeit ihrer Anforderungen. Dies kann zu langen, mitunter emotionalen Diskussionen führen. Schneller, einfacher und für alle akzeptabel ist eine gemeinsame Bewertung der Anforderungen, etwa in Form von Weighted Shortest Job First.

In der Diskussion können Sie durch numerische Einschätzungen schnell unterschiedliche Annahmen herausarbeiten: das ist der Kern der Abstimmung und der Planung.

Photo by Bruno Wolff on Unsplash

Vorsicht: Meilensteine!

Unternehmen erstellen häufig Roadmaps, die Meilensteine mi festem Datum enthalten. In den meisten Fällen werden diese Roadmaps zum Tracking des Fortschritts verwendet.

Problematisch ist daran, dass jeder vorab definierte Meilenstein quasi eine Wette darstellt, die auf vielen, oft unbekannten Annahmen basiert. Daher sind Termine in agilen Planungen stets Vorhersagen, die sich mit hoher Wahrscheinlichkeit ändern werden. Diesen wichtigen Unterschied müssen Sie Ihren Stakeholdern unbedingt verdeutlichen, um Vertrauen in die Planung aufzubauen. Schließlich ist Ihr Ziel, sich an neue Situationen schnell anpassen zu können!

Sie brauchen mehr Details? Wir müssen reden!

Erfahren Sie mehr und diskutieren Sie mit beim Agile Meetup am 19.09.19 bei Conciso.

Schreibe einen Kommentar

Das könnte Dich auch noch interessieren

Das Teamwork auf das nächste Level bringen: Wie der Agile Coach als Spotlight-Berater helfen kann

Das Teamwork auf das nächste Level bringen: Wie der Agile Coach als Sp...

„Wie kann ich wissen, ob es gut läuft und was kann man im Zweifel tun?” - hat mich kürzlich eine ...
Kamil Sokolski bei einem ruhigen Gespräch mit einem Arbeitskollegen im Conciso Workgarden im agilen Kontext. Zusätzlich wird das Conciso Logo in der unteren rechten Ecke abgebildet. Das Bild wird in dem Wissensbeitrag "Agilität ganzheitlich denken, statt nur „PS auf die Straße bringen“." genutzt.

Agilität ganzheitlich denken, statt nur „PS auf die Straße zu bringen“...

Agile Coach Kamil Sokolski erklärt, weshalb es wichtig ist, Agilität ganzheitlich zu denken ...
Agile Series: Das Backlog mit Magic Estimation schätzen

Agile Series: Das Backlog mit Magic Estimation schätzen

Wenn Sie eine große Anzahl an Epics oder Stories in Ihrem Backlog schätzen müssen, ist Planning Poker nicht immer die ...