/ Stabilisierung der Basis. miitya #4
14. Juli 2016

Januar 2016 – Juni 2016

Stabilisierung der Basis war nun angesagt. Die Kräfte waren zurück, die Motivation wieder hoch, es ging los in ein neues Jahr. Der Backlog war voll, die Stories für den nächsten Sprint geklärt und die Entwickler standen in den Startlöchern. Natürlich wurden die Stories vorab in ihrer Komplexität eingeschätzt, mit dem Ziel, den Sprint recht gut beplanen zu können, vorab schon zu erkennen, welche Probleme auftauchen könnten.

Stabilisierung der Basis

Die Probleme lagen in der Codebasis begründet. Die beiden Plattformen iOS und Android setzten voraus, dass die Entwicklung entsprechend auf die Plattform zugeschnitten wurde. Die zwei Plattformen zwangen die Entwickler auch, alle Arbeiten doppelt auszuführen, und die Implementierung im Detail anzupassen. So gestaltete sich der Adressbuch-Abgleich auf iOS in einigen Punkten sehr viel komplizierter als auf Android, musste auf andere Art und Weise gelöst werden. Infolgedessen mussten Konzepte und Abstimmungen oft für beide Plattformen durchgeführt werden, was einen hohen Aufwand auf allen Seiten verursachte.

Unterschiede in den Plattformen

Im Weiteren mussten die indischen Kollegen zuerst verstehen, wieso vom vorherigen Team einige Dinge auf iOS gar nicht oder anders als auf Android implementiert wurden. Es stellte sich sehr oft die Frage, ob ein Bug oder eine bewusste Entscheidung, ein bewusstes Weglassen vorlag. Diese Erarbeitung ging natürlich zu Lasten der Umsetzungsgeschwindigkeit und so fiel es den Entwicklern schwer, den Sprintrahmen einzuhalten. Aus geplanten drei Wochen wurden 6 oder sogar 9 Wochen. Mit der Folge, dass die Updates nur in großen Abständen in den Stores ankamen.

Sprintplanung

Aus dieser Problematik heraus entstand der Wunsch seitens der Entwickler, die Sprintplanung zu intensivieren und dabei nicht nur die Fachlichkeit, sondern auch die technische Basis zu betrachten. Für uns als Product Owner hieß dies, dass die Aufwände der Sprintplanung sowie Schätzungen für die Stories eine Tendenz nach oben bekamen. Was nüchtern betrachtet weniger Funktionalität für mehr Geld bedeutet. Dafür kaufte man sich eine erhöhte Planungssicherheit und Liefertreue ein.

Regelbetrieb

Allerdings war nach einigen Sprints schon klar, dass dieser Zustand nur bis dahin beibehalten werden musste, bis der Code noch besser verstanden wurde. Das Team brauchte einfach Zeit, den Code zu verinnerlichen. So ging man gemeinsam im Juni zu einem Regelbetrieb über, der pro Sprint einige Stories, einige Bugfixes und Raum für Unsicherheit und Nachjustierung zuließ.

In diesem Modus wurden weitere Verbesserungen am miitya Core vorgenommen und erste Schritte Richtung Content-Modul gegangen. Das Content-Modul wurde erstmalig prototypisch auf der von uns begleiteten #startupkonf vorgestellt und stieß auf viel Zustimmung.

Nun geht es darum, herauszufinden, wie wir mit Lean Startup und Lean Analytics bessere und schnellere Ergebnisse erzielen können.

Dies ist der vierte Artikel einer Serie über unsere Erfahrungen in der Produktentwicklung nach Lean Startup. Dieser Artikel schließt die Rückschau auf die ersten Monate ab. Dahingegen werden spätere Artikel reflektieren, was wir heute aufgrund der gemachten Erfahrungen anders machen würden. Hier geht es zum dritten Artikel.

2 thoughts on “Stabilisierung der Basis. miitya #4

Schreibe einen Kommentar

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

Top