So sah die Herausforderung unseres Kunden aus
Zwei Teams, zwei Herangehensweisen
Nach der erfolgreichen Scrum-Einführung Mitte des Jahres 2011 bei der ISIOS GmbH, stand die Auslieferung eines großen Release bevor, für das ISIOS von it-agile Entwicklungsunterstützung beauftragte. Zusätzlich zu dem Berater, der bis dato die Scrum-Einführung begleitet hatte, unterstützte it-agile Ende August daher zunächst mit zwei weiteren Entwicklern das Projekt. Nach und nach stießen weitere it-agile-Entwickler:innen hinzu, bis Anfang Oktober sowohl ISIOS, als auch it-agile, jeweils ein sechsköpfiges Entwicklungsteam stellten.
Um das Wissen der internen Entwickler:innen möglichst gut unter uns „Neuen“ zu streuen wurden beide Teams halbiert und es entstanden zwei gemischte Teams, die jeweils drei Entwickler:innen von ISIOS und it-agile umfassten. Als grundlegendes Ziel wurde das Umsetzen der vom Kunden vorgegebenen Funktionen festgelegt. Die Weitergabe der von it-agile praktizierten agilen Entwicklungsmethoden an die internen Entwickler war für ISIOS zu diesem Zeitpunkt vor allem erwünschtes Beiwerk, aber nicht das Hauptziel.
Die beiden neu entstandenen Teams K und L gingen vollkommen unterschiedlich an ihre neuen Aufgaben.
Da das Umsetzen von viel Funktionalität im Vordergrund stand, entschloss sich Team L zwischen den Entwickler:innen vor allem Wissensaustausch über die Fachlichkeit zu verteilen. Die ISIOS-Entwickler:innen gaben das Wissen, was zum Entwickeln nötig war, bereitwillig an die it-agile- Entwickler:innen weiter. Diese nutzten das Wissen um es mitsamt der agilen Entwicklungsmethoden schnell in funktionierende Software zu transformieren. Die it-agile-Entwickler:innen von Team L machten sich schnell selbstständig und trugen so schnell und routiniert ihren Teil zu mehreren erfolgreichen Sprints bei.
Team K strukturierte sich anders: Es hatte die Annahme, dass man, um auf lange Sicht möglichst viel Funktionalität umzusetzen, das Wissen um agile Entwicklungspraktiken schnell streuen müsse. Daher wurde permanent in Paaren entwickelt und in den Paaren waren in der Regel beide Firmen vertreten. Die neue Zusammenstellung des Teams und die Einarbeitung der ISIOS-Entwickler in die ungewohnten Arbeitsabläufe wie TDD und Continuous Integration, verursachte zunächst die vom Team bereits erwartete Verlangsamung der Entwicklungsgeschwindigkeit, die zu erwarten ist, wenn ein nicht aufeinander abgestimmtes Team sich neu formiert. Mit der Zeit rentierte sich die frühe Investition und das Team K nahm Fahrt auf.
Zwischenzeitlich änderten sich die Anforderungen des Kunden stark, sodass der Product Ower von ISIOS das gesamte Backlog neu strukturierte. Die Erwartungen an das Team begannen sich zu ändern. Schließlich kam der Moment, als sich die Erwartung an den Auftrag der it-agile-Entwickler:innen ebenfalls änderte. Inzwischen waren beide Teams K und L aufeinander eingespielt und es sah aus, als ob der aktuell gewünschte Teil der Funktionalität ohne Probleme erreichbar war. Diese Sicherheit nutzte ISIOS, um den Wissenstransfer agiler Entwicklungsmethoden deutlich zu kommunizieren und zu fordern.
Beide Teams stellten sich voll auf die neuen Ziele ein. Team L erlebte nun eine kurze Zeit, in der die Entwicklung langsamer von statten ging, da die Teammitglieder nun viel mehr firmenübergreifend arbeiteten und noch nicht perfekt aufeinander abgestimmt waren. Team K hatte die selbe Verlangsamung bereits hinter sich und konnte durch die frühe Investition nun annähernd ungebremst auch mit der Intensivierung der Ziele weiterarbeiten.
Letzten Endes hat es für die durchschnittliche Geschwindigkeit kaum einen Unterschied gemacht, wie die beiden Teams ihren Auftrag begonnen haben. Für das Verbreiten des agilen Gedankens wurde es jedoch leichter, als unser Kunde bereits an den Ergebnissen sehen konnte, dass die agilen Entwicklungsmethoden durchaus ihre positiven Auswirkungen hatten.
