Nicht unbedingt schneller, aber richtiger

Gerade auf schnelllebigen Märkten empfehlen Berater oft agile Methoden wie Scrum – groß ist die Enttäuschung, wenn agile Entwicklung nicht schneller ist als klassische Wege. Über einen grundsätzlichen Irrtum und den entscheidenden Unterschied zwischen „schnell Dinge tun“ und „schneller die richtigen Dinge tun“.

Heute Irrtum #1: „Wenn wir in Sprints vorgehen, müssen wir schneller fertig sein“

„Wenn wir jetzt noch länger brauchen, dann können wir ja gleich wieder alles im Wasserfall machen.“ So ähnlich kommentierte einmal mein Klient den Fortschritt eines Scrum-Projekts. Der Irrglaube, dass man mit Scrum Projekte schneller umsetzt, rührt vielleicht von einem der zentralen Begriffe in Scrum – den sogenannten Sprints. Dabei betont der Begriff des Sprints einen der wesentlichen Unterschiede zur klassischen Wasserfall-Vorgehensweise: Sprints bedeuten nicht zuerst „schnellere Zeiteinheiten“, sondern Entwickeln in einzelnen Etappen, zwischen denen jeweils ein Abgleich mit Marktentwicklung und Kundenwünschen erfolgt.

Vorgehen in Sprints hat einen wesentlichen Vorteil: ist das Budget aufgebraucht oder drängt die Zeit, hat man das Wichtigste bereits umgesetzt.

Im klassischen Vorgehen definiert ein Unternehmen zunächst ein Zielprodukt. Produktmanager stellen sich die klassischen Fragen: Wie soll das Produkt aussehen? Was kann ich dafür verlangen? Wie viele Kunden nutzen das Produkt? Üblicherweise beauftragt das Team eine Marktforschung mit einer Umfrage und rechnet einen Business Case, der auf all diesen Annahmen basiert. Daraufhin schreiben die entsprechenden Fachabteilungen Konzepte und bereiten die Vermarktung des Produkts vor. Irgendwann – oft nicht in Zeit und Budget – geht das Produkt dann live und es wird mit Spannung erwartet, wie der Markt reagiert. Digitale Projekte haben dabei übrigens ein rund 30-fach höheres Risiko, Budget und Zeitrahmen zu sprengen – gut jedes fünfte IT-Projekt liegt rund 200 Prozent über dem geplanten Budget und kostet 70 Prozent mehr Zeit. Floppt das Produkt, ist die Enttäuschung groß und das Team oft ratlos.

Am Kunden vorbei entwickelt?

Tatsächlich werden entweder Kundenbedürfnisse von Anfang an nicht verstanden oder der Markt hat sich seit Produktentwicklung bis zur Implementierung verändert. Vielleicht hat ein konkurrierendes etabliertes Unternehmen oder ein Start-Up in der Zwischenzeit eine bessere Lösung auf den Markt gebracht, die außerdem auch noch günstiger ist. Wir haben ein Produkt im besten Fall also schnell entwickelt, aber behaftet mit dem Risiko, dass es der Kunde nicht will.

Was ist mit der Marktforschung, die wir vorher gemacht haben? Die müsste uns doch Sicherheit geben? Eine bekannte und viel zitierte Aussage von Henry Ford besagt „Wenn ich die Menschen gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.“ Dieser Ausspruch wird wohl gerade in der Scrum-Literatur deshalb so oft zitiert, weil er eine Tatsache gut veranschaulicht: die Antworten befragter Kunden bewegen sich immer innerhalb des Rahmens, den die Kunden kennen. So unterscheidet sich das, was Kunden meinen zu wollen, oft deutlich von ihren wahren Bedürfnissen – im Fall von Ford schneller von A nach B zu kommen. Umfragen können das Produkterlebnis nicht ersetzen. Bevor man einen Touchscreen nicht selbst getestet hat, mag einem die Idee befremdlich vorkommen und die wenigsten würden es wohl in einer Umfrage als Anforderung definieren. Zudem können sich Wünsche schnell ändern sobald ein Wettbewerber ein neues Produkt auf den Markt bringt.

Was ist bei Scrum anders?

Genau hier setzt Scrum an. Es wird nicht von Anfang an ein komplettes Zielprodukt definiert, es gibt vielmehr eine Produktvision, die dann iterativ unter Einbezug der Kunden weiterentwickelt wird. Ein Beispiel wäre ein Tool, mit dem Kunden Dateien organisieren können. Zunächst beschränkt man seine Produktidee auf die wichtigsten Features und setzt diese in einen Prototyp um. Im Beispiel könnten die wichtigsten Features ein Dateienupload, eine Ordnerstruktur sowie die grafische Benutzeroberfläche sein. Diese Features werden zum Beispiel für den ersten Sprint – einer Entwicklungsphase von bis zu vier Wochen – vorgesehen. In einem sogenannten Sprint Review wird der aktuelle Prototyp den Stakeholdern, im Idealfall einer Test-Community von Kunden, gezeigt – das kann je nach Branche ein Prototyp zum Anfassen, ein Stück Software oder zu Beginn ein Klick-Dummy sein. Die Community gibt dann Feedback und kann auch Wünsche zu weiteren Features äußern. Vielleicht wäre vielen Kunden der Test-Community wichtig, eine Datei mittels „Drag and Drop“ in das Tool zu ziehen. Nach jedem Sprint bewertet das Umsetzungsteam (insbesondere der sogenannte Product Owner), ob die ursprünglich geplanten Features noch die richtigen sind und ob Prioritäten geändert werden müssen. Zum Beispiel könnte das Feature „Drag and Drop“ in den nächsten Sprint gezogen werden, auch wenn es ursprünglich für einen der letzten Sprints vorgesehen war. Zentral für die Bewertung ist das Kundenfeedback, aber auch das Management eines Unternehmens wird einbezogen. Diese Vorgehensweise hat einen wesentlichen Vorteil: ist das Budget aufgebraucht oder drängt die Zeit, hat man das Wichtigste bereits umgesetzt. Die Drag and Drop-Funktion, die für die Kunden anscheinend elementar für eine angenehme Nutzung ist – ein zentrales Kundenbedürfnis – fällt nicht hinten runter.

Es geht bei Scrum also nicht darum, insgesamt schneller zu programmieren oder zu entwickeln, sondern vielmehr darum, die richtigen Dinge zu tun und in der Lage zu sein, sich schnell Veränderungen anzupassen. Vielleicht kommt man in einigen Fällen sogar langsamer zu einem Produkt als im Wasserfall-Vorgehen. Schließlich behält man sich vor, ggf. wieder einen Schritt umzukehren und neu über einen Teil des Produkts nachzudenken. Dies könnte zum Beispiel der Fall sein, wenn sich herausstellt, dass Features durch die Test-Community nicht genutzt werden oder es Probleme bei der Nutzung gibt. Auch Vorschläge im Sinne von „es wäre doch einfacher, wenn“ können dazu führen die Handhabung eines Produktes nochmal zu verwerfen und neu zu entwickeln.

Insbesondere in schnelllebigen Märkten und unter starkem Wettbewerbsdruck ist ein stetiger Abgleich mit Kundenbedürfnissen von großer Bedeutung für unternehmerischen Erfolg. Kundenbedürfnisse zu erkennen ist zentrale Herausforderung, zielgerichtetes Erfüllen derselben zentraler Wettbewerbsvorteil. Wir sind mit Scrum also nicht unbedingt schneller, aber wir haben deutlich bessere Chancen, richtig zu liegen.