Ich bin mittlerweile der Meinung, dass es genau umgekehrt sein sollte. In 9 von 10 Fällen wäre es besser, zunächst klein zu starten und mit kurzen Sprints die Funktionalitäten Stück für Stück auszubauen. Der größte Vorteil: Durch frühes Feedback der Kunden lässt sich feststellen, ob man auf dem richtigen Weg ist und wie die neue Funktion bei den Nutzern ankommt. Änderungen lassen sich direkt und unmittelbar vornehmen, ohne dass sich jemand in den Code von vor Wochen wieder einarbeiten muss. Ein schneller „Projektlaunch“ sorgt außerdem in vielen Fällen dafür, dass die Motivation aller Beteiligten um ein Vielfaches höher ist. Ich würde sogar behaupten, zu sehen wie etwas gerade Entwickeltes von der Zielgruppe aufgenommen wird, beflügelt uns wesentlich mehr weiterzumachen, als der Gehaltscheck zum Monatsende.
Kleine Sprints beim Relaunch eines Projektes
Nun profitieren die meisten Startups davon, dass sie bei Null anfangen können und ihre Darstellung allenfalls an den Mitbewerbern gemessen werden kann. Aber was ist beispielsweise bei einem Website-Relaunch?
Auch hier können kurze Sprints meiner Meinung nach sinnvoll sein, auch wenn das bedeutet, dass man dem Kunden/Nutzer Funktionen des alten Auftritts vorerst oder gar dauerhaft „wegnimmt“. Wie so etwas aussehen kann hat 37signals vor rund 1,5 Jahren bewiesen, als sie ihre Projektmanagement-Software Basecamp von Grund auf neu entwickelten. Statt alle bisher da gewesenen Funktionen als Standard für das neue System zu sehen, haben sie sich entschlossen nur mit den ihrer Meinung nach wichtigsten Funktionen zu starten. Klar, war der Aufschrei zunächst groß. Gleichzeitig wurden viele der zunächst weggelassenen Funktionen auf den Prüfstand gestellt. Wie groß ist die Nachfrage nach dieser oder jener Funktion tatsächlich?
Probleme der Sprints
Gerade Auftraggeber werden wohl ein Problem mit dieser Vorgehensweise haben. In der Regel möchten sie ein Angebot, möglichst mit Fixpreis, das alle Eventualitäten abdeckt. Vielleicht fürchten sie sich auch ein wenig, dass durch die kurzen Sprints das Projekt unberechenbar und unter Umständen teurer wird, was eigentlich Unsinn ist. Viele sind aber auch einfach nur schwer davon zu überzeugen, dass Reduktion und das schrittweise Vorgehen etwas gutes sein können. Schließlich bedeutet Fortschritt in den meisten Fällen nachwievor „mehr“ und nicht „weniger“.
Fazit
Gerade weil die letzten größeren Projekte so schwerfällig und teilweise unnötig kompliziert wurden, würde ich gerne mal ein großes Projekt mit kurzen Sprints realisieren wollen, auch um meine Theorien auf den Prüfstand zu stellen. Habt ihr bereits Erfahrungen mit dieser Vorgehensweise gemacht? Wo seht ihr die Gefahren? Lasst es mich wissen in den Kommentaren.
Bild: vectorportal.com