Wie ein strukturiertes Test- und Delivery-Setup Release-Zyklen von 4+ auf 2 Wochen verkürzte.
Wie ein strukturiertes
Test- und Delivery-Setup Release-Zyklen von 4+ auf 2 Wochen verkürzte.
Eine , das eine mobile App als zentrale Plattform für Kundenkarten und Loyalty-Programme entwickelte. Das Ziel war die Ablösung physischer Mitgliedskarten durch eine digitale Lösung. Die Entwicklungskapazität bestand aus rund 40 Entwickler:innen, organisiert in vier Scrum-Teams mit Fokus auf unterschiedlichen App-Domänen. Doch trotz dieser Ressourcenlage stand das Startup unter Druck: Die Geschäftsführung forderte zweieinen ambitionierten Rhythmus, der in der Praxis nicht gehalten werden konnte, darstellte.
Die IT Delivery-Prozesse kamen immer wieder ins Stocken. zwischen den Teams erzwangen eine präzise Merge-Reihenfolge, doch ein koordiniertes Release-Management fehlte. Dies führte zu Verzögerungen, instabilen Builds und Releases, die statt im Zwei-Wochen-Takt oft erst nach vier Wochen oder später erfolgten. Noch kritischer war die Testorganisation: und konsequente Bug-Priorisierung blieb die Qualitätssicherung ein Risikofaktor. Unentdeckte Bugs würden über die App Stores hunderttausende aktive Nutzer:innen erreichen. Je nach Schweregrad mit potenziell gravierenden Konsequenzen für das Image des Startups.
Mein Vorgehen: Diszipliniertes Release- und Test-Management etablieren.
Strukturierung des Release-Prozesses
Im Zusammenspiel der vier Entwicklungsteams zeigte sich schnell, dass der Release-Prozess stark von implizitem Wissen abhing. Zwar arbeiteten die vier Teams parallel an der App, doch es gab keinen gemeinsamen Überblick über Git-Branching, Merge-Reihenfolgen oder die technischen Abhängigkeiten zwischen den einzelnen Domänen. Abhängigkeiten wurden nicht systematisch besprochen und Release-Entscheidungen erfolgten häufig unter Zeitdruck. In Kombination mit dem unstrukturierten Testmanagement führte dies zu Releases mit erhöhtem Risiko, die bislang nur durch Glück ohne kritische Bugs auf der Live-Umgebung geblieben waren.
Um diesen Zufallsfaktor zu reduzieren, etablierte ich zunächst eine enge Zusammenarbeit mit allen Entwicklungsteams und eignete mir gezielt das notwendige technische Verständnis an. Auf dieser Basis übernahm ich temporär die Rolle der koordinierenden Instanz: Ich sorgte für einen transparenten Gesamtüberblick, stimmte eine klare Merge-Reihenfolge zwischen den Teams ab und kommunizierte diese für alle Beteiligten nachvollziehbar.
Parallel dazu arbeitete ich gezielt an der Stärkung der Eigenverantwortung der Product Owner. Schritt für Schritt übernahmen sie meine Rolle als kommunikative Schnittstelle zwischen den Teams und trugen aktiv zur Abstimmung von Abhängigkeiten und Release-Zeitpunkten bei. So entwickelte sich eine nachhaltige Koordinationskultur, in der Ad-hoc-Entscheidungen durch strukturierte Abstimmungen ersetzt wurden und Wissenssilos zwischen den Scrum-Teams deutlich abnahmen.
Management kontinuierlicher "Full-Product-Tests"
Zu Beginn meiner Arbeit war das manuelle Testing beim Kunden nur schwer steuerbar. Es existierte keine einheitliche Testdokumentation, Tests wurden unregelmäßig und uneinheitlich durchgeführt, Bugs unterschiedlich klassifiziert und teils den falschen Scrum-Teams zugeordnet. Für Produktverantwortliche und Management war damit kaum nachvollziehbar, wie stabil das Produkt tatsächlich war und Release-Entscheidungen basierten eher auf Bauchgefühl als auf belastbaren Informationen.
Ich entwickelte daraufhin eine strukturierte Testdokumentation mit mehreren Dutzend klar definierter Test-Flows, die die zentralen Funktionen der App systematisch abdeckten. Diese sogenannte Full-Product-Tests (FPT) schufen erstmals Transparenz darüber, was getestet wird, wie getestet wird und mit welchem Ergebnis.
Durch die klare und einfach zu nutzende Struktur konnten neben mir auch weitere Kolleg:innen und freiwillige Tester:innen gezielt in die Tests eingebunden werden. Bugs wurden einheitlich nach Schweregrad klassifiziert, den richtigen Scrum-Teams zugeordnet und konsequent nachverfolgt. Dadurch verbesserte sich nicht nur die Qualität der Testergebnisse, sondern auch die Zusammenarbeit zwischen Testing, Entwicklung und Product Ownern spürbar.
Um die bestehenden Release-Bedenken auf Management-Ebene zu adressieren, etablierte ich zusätzlich ein zweiwöchentliches, von mir moderiertes Debriefing-Format. In diesem wurden die Ergebnisse der FPT, kritische Bugs und Risiken transparent vorgestellt. Das Management erhielt damit erstmals eine klare und verlässliche Entscheidungsgrundlage, um Releases bewusst freizugeben oder gezielt Bugfixes zu priorisieren.
Meine Vorgehensweise: Diszipliniertes Release- und Test-Management etablieren.
Ergebnisse
Höhere Release-Frequenz
von teilweise über vier auf die geplanten zwei Wochen verkürzt. Zur Vermeidung von Doppelstrukturen erhielten die Release- und Testing-Prozesse zudem ein kontinuierliches Fine-Tuning und wurde eng an die ohnehin bestehenden Scrum-Zyklen gekoppelt.
Höhere Qualität
Dank des Full-Product-Tests gelang es, eine wesentlich höhere Abdeckung im manuellen Testing zu erreichen. Während meiner Zeit im Projekt gingen keine schwerwiegenden Bugs live.
Verbesserte Zusammenarbeit
Die enge Koordination zwischen den vier Scrum-Teams reduzierte Reibungsverluste, sorgte für klarere Verantwortlichkeiten und verhinderte redundante Arbeit.
Gestärktes Vertrauen
Das Management erhielt durch die systematischen FPT-Debriefings Transparenz und konnte fundiert über Releases entscheiden, was einen wichtigen Faktor für die Stabilität des Projekts darstellte.
Ergebnisse
Höhere
Release-Frequenz
bei stabiler Qualität von teilweise über vier auf die geplanten zwei Wochen verkürzt. Zur Vermeidung von Doppelstrukturen erhielt der Release- und Testing-Zyklus ein kontinuierliches Fine-Tuning und wurde eng an die ohnehin bestehenden Scrum-Zyklen gekoppelt.
Höhere
Qualität
Dank des Full-Product-Tests gelang es, eine wesentlich höhere Abdeckung im manuellen Testing zu erreichen. Während meiner Zeit im Projekt gingen keine schwerwiegenden Bugs live.
Verbesserte Zusammenarbeit
Die enge Koordination zwischen den vier Entwicklungsteams reduzierte Reibungsverluste, sorgte für klarere Verantwortlichkeiten und verhinderte redundante Arbeiten.
Gestärktes
Vertrauen
Das Management erhielt durch die systematischen Debriefings Transparenz und konnte fundiert über Releases entscheiden – ein wichtiger Faktor für die Stabilität des Projekts.
Positives Feedback zum Projekt:
Bereit, Ihr Team voranzubringen?
Besprechen wir wo es hakt und wie ich dabei helfen kann.
Bereit, Ihr Team voranzubringen?
Besprechen wir wo es hakt und wie ich dabei helfen kann.
