Der zweite Teil der Serie zur agilen Transformation handelt von den Erfahrungen, die das Team in den ersten Monaten nach der Umstellung vom Klassischen ins Agile gesammelt hat. Welche Erkenntnisse aus der Initialisierungsphase gewonnen wurden, lesen Sie hier: [Link Teil 1]
Crossfunktionalität ist nach unserem Verständnis eine wesentliche Eigenschaft eines agilen Teams. Sie beschreibt die Fähigkeit des Teams, ohne wesentliche Hilfe von außen ein Inkrement (Produktbestandteil) zu entwickeln und auszuliefern.
Im hier betrachteten Programm wurde ein Bestandsführungssystem für den Bereich Leben implementiert und weiterentwickelt. In diesem Zusammenhang wurden durch ein Projektteam, in dem der Fachbereich Mitglied war, Schriftstücke ausgeliefert. Der Fachbereich definierte die inhaltlichen Vorgaben und übernahm den abschließenden Test. Umgesetzt wurden die Anforderungen nach einer Business Analyse in zwei verschiedenen Softwarelösungen. Die Umsetzung der Anforderungen unter Beteiligung heterogener Akteure erforderte ein intelligentes Schneiden des Teams im agilen Kontext. Nach einigen Sprints stellte sich heraus, dass diese crossfunktionalen Teammeetings immer auf zwei Informationsebenen stattfanden: Fachbereich und Business Analyse konzipierten die Vorgaben, während die Entwickler diese erst anschließend umsetzen konnten. Mit dieser Erkenntnis wurde adjustiert und Dailys ab sofort getrennt voneinander durchgeführt. Was zunächst sinnvoll erschien, da sich die einzelnen Teammitglieder ausschließlich auf die für sie relevanten Termine fokussierten, führte jedoch dazu, dass die Kommunikation zwischen Fachbereich/Business Analyse und Entwicklung sich im Wesentlichen auf die Refinements beschränkte. Die Umsetzungsgeschwindigkeit verlangsamte sich, da Rückfragen zu Anforderungen zu zögerlich und fachlich nicht ausreichend spezifisch gestellt wurden. Ein kontinuierliches, gemeinsames Arbeiten an den Produktanforderungen über kurze Wege ist wesentlich für den Erfolg und muss vom Team eingefordert werden. Alles, was nicht im direkten Wirkungsradius des Teams liegt, im Projekt beispielsweise die Erstellung der Testfälle, verringert merklich die Velocity (Umfang an Aufgaben, die das Team in einem Sprint erledigt). Sinnvoll geschnittene und vorbereitete Sprint-Events, Integration von Skills in das Team sowie regelmäßige Absprachen außerhalb der festen Termine sind die entscheidenden Erfolgsfaktoren.
Positiv zu erwähnen ist das Releasemanagement im Programm. Für die drei Output-Teams im Projekt gab es einen Releasemanager, der die Deployments koordinierte und sich mit dem übergreifenden Programm-Releasemanagement für die Bestandssoftware abstimmte. Die anstehenden Deployments wurden in den Plannings berücksichtigt. Darüber hinaus gab es einen täglichen Austausch dazu, was wann auf welche Umgebung deployed werden musste. Ohne einen zentralen Koordinator und feste Deploymentstrukturen laufen Softwareinstallationen unstrukturiert ab, was in einer Projektphase ohne Releasemanager für drei Teams offensichtlich wurde.
An den genannten Beispielen wird deutlich, dass Agilität vor allem davon lebt, dass jedes Team sein eigenes Vorgehen retrospektiv regelmäßig hinterfragt und auf aktuelle Gegebenheiten anpasst. Nach einigen Sprints pendelt sich ein funktionierendes Vorgehen ein, wobei es auch zulässig ist, agile Methoden nicht immer streng nach Lehrbuch, sondern sinnvoll für das Team und für das Projekt anzuwenden: Wenn eine Methode nicht funktioniert, passt das Team sie an. Ganz nach dem Motto: Überprüfung (inspection) und Anpassung (adaption) des täglichen Handelns.
Wie beim letzten Teil gilt auch hier: Bei Fragen und Wünschen kommen Sie gerne auf Herrn David Feldmann zu.