Schnell noch eine Deadline stemmen
Wenn agile Developer-Teams auf Deadline-getriebenes Management treffen, prallen sehr unterschiedliche Sichtweisen aufeinander. Die Hybris, die Zukunft auf den Tag genau voraussehen zu können und zu einem Termin viele verschiedene Teams und Abteilungen in einer Punktlandung zu vereinen, ist so weit verbreitet wie erfolglos. Gute Gründe für eine Deadline gibt es zuhauf: finanzielle, personelle, das Quartalsende, die nächste Zielvereinbarungen, Budgetfristen, usw. Mit Überstunden und Wochenendarbeit lassen sich solche Termine vielleicht noch stemmen. Die Folge sind jahrelange Aufräumarbeiten, Frust und der sehr wahrscheinliche Verlust einer Applikation, die schnell hätte weiter entwickelt werden können.
Mit den Erkenntnissen wachsen
Agiles Arbeiten baut auf einen Erkenntnisgewinn, der im Laufe des Projektes wächst. Die Erfahrung macht eine Einschätzung des Erreichbaren zunehmend genauer. Epics, Stories und Meilensteine werden permanent neu geschätzt, zusammengestellt und im Zusammenhang bewertet.
Phasen erkennen und modellieren
Vor unserem Auge entstehen Phasen mit zunehmend scharfen Konturen. Daraus ergeben sich sinnvolle Ziele mit überschaubarem Inventar. Die Readiness verschiedener Komponenten wird absehbar, die Abstimmung mit verschiedenen Teams (Entwicklung, Fachabteilung, Marketing) ist mit kleinem Aufwand zu erreichen. Aus dem im Ganzen unscharfen Komplex eines Projektes wird ein wohlkonstruiertes Element herausgelöst, eine Etappe. Jede solche abgeschlossene Phase erhöht die Wahrscheinlickeit des Gesamterfolgs. Ziel ist nicht, in ein neues Geflecht von Terminen zu verfallen, sondern eine bewegliche Struktur zu schaffen, die Optionen eröffnet.
Optionen eröffnen
Betrachten wir im ersten Schritt das folgende technische Setup: Wir wollen eine alte Anwendung auf einen Rewrite migrieren und alle Features der alten Applikation auch auf der neuen Plattform anbieten. Eine Deadline ist gesetzt, alle Teammitglieder sind sicher, dass diese Deadline nicht zu halten ist. Mit den entsprechenden Auswirkungen auf die Moral der Truppe, die von Defätismus über Angst bis Panik reicht – Extreme, die einer umsichtigen Planung und einer gesteigerten Leistung diametral entgegen stehen. Unter Umständen wird der Termin mehrfach gerissen und verschoben, mit ähnlich desaströsen Auswirkungen auf das Geschäft und den Gemütszustand der Beteiligten.
Dagegen stellen wir eine Sichtweise, die Phasen identifiziert und Optionen eröffnet, die aus dem Stand der Entwicklung abgeleitet werden können. Innerhalb der Gesamtstrategie (hier: eine bestehende Applikation auf einen Rewrite migrieren und international online gehen) gibt es Phasen, auf die sich Management und Entwicklerteam einigen. Ein erster Livegang wird im Sinne des Lean Startup auf die Kernfunktionalität eines MVP (Minimum Viable Product) heruntergebrochen, um früh Feedback vom Kunden zu bekommen. Die Migration ist vollständig entkoppelt und wird der nächste Taktgeber: Ist sie technisch umsetzbar, kann das Management entscheiden, bei welchem Umsetzungsgrad der Features auf die neue Pattform migriert werden kann. Bis dahin können neue Features gegen den Markt, kann das Zusammenspiel von Entwicklung, Marketing und Operations in kleinen Dosen getestet und eingespielt werden. Es gibt kleine Erfolgserlebnisse und viele wertvolle Generalproben für den „Big Bang“ der Migration.
Wohlgeordnet von Etappe zu Etappe
Die Wahrscheinlichkeit ist groß, dass nach der Migration, die nicht mit letzter Kraft unter immensem Druck taumelnd erreicht wurde, sondern in wohlgeordneten und durchdachten kleinen Häppchen vonstatten ging, schnell weitere Features für den Kunden fertiggestellt werden können.
Und eine Menge gelernt
Da wir einen frühen Release mit den Kernfunktionalitäten anstreben (MVP), können wir auch früh Erfahrung sammeln und lernen: vom Feeback der User, vom Zusammentreffen der Domain-Logik mit der Wirklichkeit. Und wir können das Erlernte sofort in der nächsten Iteration umsetzen. Da wir mit Family & Friends initial testen und echte Benutzer Schritt für Schritt gezielt dazumehmen, können wir auch nicht so viel kaputt machen. Findet das Produkt keinen Anklang, können wir früh pivotieren. Scheitert das Projekt, scheitert es früh und mit weniger Kosten.
Schreibe einen Kommentar