Mit dem MVP und flexiblem Umdenken durch die nächste Herausforderung

21. September 2020 von Anica Eiting

In Krisenzeiten ist es wichtig, sich auf das Wesentliche zu konzentrieren. Was schon immer zu einem guten agilen Projektvorgehen gehörte, entpuppt sich jetzt zu einem der Kernaspekte, um das Überleben eines Projekts in und nach der Krise zu sichern.

Wenn heute neue Geschäftsmodelle gestartet werden, sollen sie einen schnellen Return-of-Invest bringen und natürlich es ist wichtig, schneller als der Wettbewerber am Markt zu sein.

Ein agiles Vorgehen bei IT-Projekten hat sich mittlerweile durchgesetzt, denn dieser Ansatz ermöglicht es, in kleinen, aber wertvollen Schritten die Geschäftsidee zu implementieren. Und so kann mit einem MVP (Minimum Viable Product) in relativ kurzer Zeit eine erste IT-Anwendung veröffentlicht werden.

 

 

MVP Minimum Viable Product

 

 

MVP: Das Minimum Viable Product

 

Ein Minimum Viable Product, wörtlich ein „minimal überlebensfähiges Produkt“, ist die erste minimal funktionsfähige Iteration eines Produkts, das entwickelt werden muss, um mit minimalem Aufwand den Kunden-, Markt- oder Funktionsbedarf zu decken und handlungsrelevantes Feedback zu gewährleisten. (Quelle: Wikipedia, Stand 09.2020)

 

 

MVP Minimum Viable Product

 

Minimum Viable Produkt (© eXXcellent solutions)

 

Der Begriff "Viable" in Minimum Viable Product kann mit einer Reihe von deutschen Begriffen übersetzt werden. „Lebensfähig“, oder „Überlebensfähig“ wären wörtliche Übersetzungen. In der Softwareentwicklung ist der wohl passendste Begriff allerdings das Wort "brauchbar".

Projekte sind komplex. Alle Details können kaum in einem 1.000-seitigen Konzept berücksichtigt werden. Die Anforderungen ändern sich, spätestens dann, wenn der Anwender das erste Mal den Workflow in einem ersten Prototyp durchspielt. Heutige IT-Projekte sind agil.

In agilen Vorgehensmodellen arbeiten wir in kurzen Zyklen an einem Projekt. Dabei entsteht nach Ende jedes Zyklus ein Mehrwert für den Benutzer, und zwar so ausgereift, dass dieses Inkrement auch veröffentlicht werden kann. Was in der Theorie direkt einleuchtend klingt, ist in der Praxis manchmal gar nicht so einfach.

 

Ein Zyklus, Iteration oder Sprint ist nur ein paar wenige Wochen lang. Wie schaffen wir in der kurzen Zeit einen Mehrwert für den Endnutzer?

Für einen MVP ist es wichtig, den ersten „brauchbaren“ Mehrwert zu ermitteln. Kurz gesagt:

  • Was ist die Kernfunktion, die wir zur Verfügung stellen wollen?
  • Was steht dem Gegenüber und ist "Extra"?

Diese Unterscheidung ist nicht trivial, denn sie hängt von den verschiedenen Rahmenbedingungen eines Projektes ab. So können zum Beispiel Hilfsfunktionen zunächst weggelassen werden, wenn es:

  1. nur wenige Expertennutzer gibt, die entsprechend eingewiesen werden können oder
  2. sich um Eingaben handelt, die keine direkten Konsequenzen haben und vom Nutzer selbständig leicht korrigiert werden können.

Gerade solche Features, die wichtig sind für ein rundes, robustes Softwareprodukt benötigen einiges an Entwicklungs-, aber auch Spezifikationszeit, bis jeder Sonder- und Grenzfall durchdacht wurde. In einem MVP kann diese Zeit kann eingespart werden.

Der Nutzer arbeitet direkt im MVP. Damit ist er in der Lage, bereits zu Beginn wertvolles Feedback zu geben. So wird die weitere Entwicklung der Software nachhaltig in eine ganz andere, bessere Richtung geführt als vielleicht zu Projektstart erdacht.

Beginnt man jeden Zyklus mit dem Konzept im Hinterkopf, zunächst nur das minimal Wertvolle zu tun, kann so in jeder Lage entsprechend reagiert werden, weil man durch die kurze Entwicklungszeit maximal flexibel und handlungsfähig bleibt.

 

 

Softwareentwicklung MVP

© upklyak - freepik.com

 

MVP in einer gewachsenen Landschaft - Wie wir unserem Kunden mit dem MVP-Ansatz Geld sparen konnten.

Der MVP-Ansatz ist nicht nur für neue IT-Anwendung sinnvoll, sondern ist auch essenziell für die Weiterentwicklung einer bestehenden Applikationslandschaft.

Für einen großen Kunden haben wir im Sommer 2019 den großen Block Weiterentwicklung abgeschlossen und es wurde Zeit, sich der Migration auf einen anderen Applikationsserver zu widmen. Durch die zukünftige Nutzung von Open-Source-Software sollten substanzielle Lizenzkosten eingespart werden.

Das bestehende System nutzte allerdings einige proprietäre Features des Applikationsservers. Das machte einen Umbau erforderlich, um die Migration zu ermöglichen.

Unsere Analyse hat ergeben, dass diese Chance genutzt werden sollte, um parallel:

  • den Code zu verbessern und lesbarer zu machen,
  • obsolete Codefragmente zu entfernen und
  • auf aktuellere Frameworks zu wechseln.

Der Aufwand eines solchen Umbaus ließ sich aber nur schwer belastbar abschätzen. An vielen Stellen wäre ein sehr tiefes fachliches und technisches Verständnis der entsprechenden Codestellen notwendig gewesen, um davon abhängig den Umfang der notwendigen Umbaumaßnahmen bestimmen zu können.

Demgegenüber Stand ein relativ simpler Copy-Paste Ansatz, in dem Schicht für Schicht die Klassen übertragen und nur die minimal notwendigen Anpassungen vorgenommen werden. Gleichzeit wird darauf verzichtet, die Änderungen direkt zu testen.

Stattdessen haben wir ein Vorgehen gewählt, bei dem nach der Copy-Paste-Phase eine technische Bugfixphase steht, um das System wieder zu stabilisieren. Erst anschließend wurden die fachlichen Tests durchgeführt, um die inhaltlichen Funktionalitäten zu validieren.

Für ein Team, das seit eineinhalb Jahren nach Scrum arbeitet, in kurzen Sprints, sein Ergebnis an der Definition-of-Done misst und die agilen Prinzipien verinnerlicht hat, war eigentlich klar:

Ansatz eins wäre aus technischer Sicht, Scrum-Sicht und auch aus Risikominimierungssicht der Richtige gewesen - aber er wäre auch der Aufwändigere gewesen. Hier musste nun für uns als Scrum-Team ein Umdenken passieren.

 

Wer ist der Kunde, dessen Bedürfnisse wir mit dem einem MVP erfüllen wollen?

  • Sind es in diesem Fall die Endnutzer, die ein möglichst robustes System bedienen wollen  oder
  • ist es unser direkter Auftraggeber, der das Projekt finanziert und den Produkt-Owner stellt, und der natürlich auch in seiner Firmenstruktur Budgets für Weiterentwicklung, Pflege und Kosten für den Betrieb der Software rechtfertigen und gegeneinander aufwägen muss.

Dieses Hineinversetzen in die Stakeholder und Produkt-Owner hat im gesamten Scrum-Team für die Erkenntnis gesorgt, dass in unserem Fall das minimale brauchbare Produkt dasjenige ist, das noch vor Jahresende auf dem neuen Applikationsserver laufen kann, um so in weiteren Iterationen mehr Budget für die Weiterentwicklung zu haben.

So haben wir für diese Projektphase unser Vorgehen umgestellt und mit einem hohen Verständnis für die Bedürfnisse des Gegenübers gemeinsam die Migration erfolgreich gemeistert.

Wir haben genau das richtige Modell für ein MVP in einer speziellen Situation gewählt und so einen schnellen Mehrwert für unseren Kunden geschaffen.

 

 

Weitere Artikel zu diesem Thema

Folgen Sie unserer mehrteiligen Serie zum Thema „Als Gewinner aus der Krise“:

 

Weitere Informationen

Haben Sie Fragen rund um agiles Projektmanagement im Allgemeinen oder Scrum im Speziellen?

Schreiben Sie mir eine E Mail, ich freue mich auf Ihre Kontaktaufnahme:

emailanica.eiting@exxcellent.de

 

Lernen Sie auch unsere weiteren Artikel zu agilem Projektmanagement und Scrum unter:

bubble-chat-information-2-1Agiles Projektmanagement mit Scrum - Unsere Best Practices

bubble-chat-information-2-1Produktdokumentationen - Sind sie in agilen Projekten überflüssig?

bubble-chat-information-2-1Agile Projekte mit ständig wechselnden Teams: das ist onboarding extreme!

Über Anica Eiting

Anica Eiting ist Business Manager bei eXXcellent solutions. Ihre langjährig Entwicklungserfahrung hat sie seit mehr als sechs Jahren in agilen Projekten mit aktiver Verantwortungsübernahme ausgebaut. Sie hatte die PO und Scrum-Master Rolle mehrfach inne und gestaltet aktiv das Leistungsportfolio „Agile Entwicklung“ für eXXcellent solutions. In Ihrer Coach-Rolle begleitet sie mehr als 10 Mitarbeiter bei deren Karriereplanung und übernimmt für eine Reihe von Projekten die wirtschaftliche Verantwortung. Sie ist versiert im Einsatz diversester Tools für virtuelle und lokale Kommunikation und bringt dieses Wissen kreativ und sehr erfolgreich in die Gestaltung von Meetings, Zusammenarbeitsmodellen und der aktiven Gestaltung des Teamgefühls ein.

Tags: Alle Blogbeiträge, Projekte/Lösungen, Scrum, Agiles Projektmanagement

Diesen Artikel teilen:


Newsletteranmeldung