Selbstverständlich brauchen wir noch diese Funktion und jenes Feature, wenn wir gefragt werden. Natürlich lässt man keine Chance aus, um noch mehr zu erhalten für sein Geld. Das zeigt sich beim Kauf einer Küche genauso, wie beim Kauf eines Neuwagens oder der Entwicklung von Software. Da werden neue Funktionen implementiert, Workflows entworfen und Grafiken optimiert – und das oftmals nur, weil ein (potentieller) Kunde dies beiläufig erwähnte. Wie sagte schon Auto- und Produktionspionier Henry Ford: „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt schnellere Pferde.“ Was lässt sich daraus ableiten?
Gerade in Software-Entwicklungsprojekten lassen sich neue Funktionen bzw. Features vordergründig einfach und rasch einbauen. Tatsache ist aber, dass laut einer Umfrage der Standish Group 2002 nur rund 20% der spezifizierten Funktionen häufig genutzt werden. 64% der Funktionen werden kaum oder gar nicht verwendet! Praktische Erfahrungen aus vielen Projekten bestätigen diese Ergebnisse auch heute noch. Je komplexer Applikationen werden, umso geringer ist der Anteil der verwendeten Funktionen (Extrembeispiel ist MS Excel). Ein enormes Einsparungspotential wäre also gegeben, wenn man es richtigmacht und nur das entwickelt, was tatsächlich benötigt wird.
Hier setzt Scrum als agiles Prozessframework in SW-Entwicklungsprojekten an. Es wird nicht zum Projektstart eine (scheinbar) vollumfängliche Spezifikation erstellt und implementiert. Stattdessen wird nur das absolute Minimum (MVP) spezifiziert und umgesetzt. Alle 2-4 Wochen (kurz „Sprint“) erhält der Auftragnehmer dann eine potentiell einsatzbare SW-Release.
Nach jedem Sprint wird geprüft, ob und welche Anforderungen noch offen sind und in welcher Reihenfolge die neuen Funktionen in der nächsten Runde dazu kommen sollen. Durch diese laufende Überprüfung der Anforderungen werden nur die wirklich benötigten Funktionen implementiert. Was obsolet ist, wird verworfen. Neue Anforderungen kommen ggf. hinzu. So wird vermieden, dass letztlich ein Software-Moloch entsteht, der dann ohnehin nur zu einem Bruchteil von Anwendern verwendet wird.
Die Priorisierung und Auswahl der Anforderungen übernimmt in Scrum der sog. Product Owner (PO). Der PO bestimmt als Vertreter des Auftraggebers, welche Anforderungen die höchste Wichtigkeit für das Business haben und als nächstes umgesetzt werden müssen. Diese wichtige Rolle kann selbstredend nicht nebenbei erledigt werden. Externe Product Owner können unabhängig von internen Verhältnissen die richtigen Fragen stellen und die wirklich wichtigen Anforderungen so herausfinden. Die Qualität und letztlich die Zufriedenheit von Anwenderinnen und Anwendern steigt dadurch. Gleichzeitig werden Kosten und Zeit eingespart. Es wird, um bei Ford zu bleiben, also kein schnelleres Pferd, sondern tatsächlich ein Auto entwickelt.
Wenn Du ein kostenloses und unverbindliches Beratungsgespräch wünscht, füll bitte das nachstehende Formular aus und ich werde mich mit Dir in Verbindung setzen.
