Projektmanagment: Kurze Sprints statt Marathon

9 von 10 Webprojekten sehen in etwa so aus: Man bespricht die Anforderungen der neuen Website oder des Shops, ein Angebot wird erstellt und mit ein wenig Glück wird für die nächsten Wochen oder gar Monate hinter verschlossenen Türen der „große Launch“ vorbereitet.Dass es aber auch anders gehen kann, zeigen derzeit ein paar Startups aus dem Web- und eCommerce-Bereich. Dort wird nicht nur das Unternehmen so schlank wie möglich gehalten, auch die Funktionalitäten eines Shops oder einer Website werden in vielen Fällen für den (Neu-)Start zunächst auf das Nötigste beschränkt. „Think big, start small“, lautet die Devise – das Ziel „so schnell wie möglich online gehen“.

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

Ich bin Steuermann bei Erdmann & Freunde, einem Netzwerk für Contao-Webworker, und schreibe hier über Themen aus dem Bereich Webdesign und Webentwicklung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *