Lessons learned: Agile Entwicklung im Großkonzern

Was passiert eigentlich, wenn man ein halbes Jahr lang in einem agilen Entwicklungsprojekt eines großen Unternehmens gearbeitet hat? Genau – man relativiert theoretisch Gelerntes, zuvor fest angenommene Glaubenssätze und ersetzt beziehungsweise ergänzt diese durch ganz praktische, teilweise erhellende, teilweise auch ernüchternde Einsichten. Worin bestehen die nachfolgenden Lessons? Zum einen habe ich erst durch die Praxis untermauert ein eindrückliches Verständnis der theoretisch konstatierten Vorteile agiler Vorgehensmodelle erhalten. Zudem basiert das Gelernte aber auch auf dem erlebten Clash zwischen Scrum und dem im Grundsatz vom Wasserfall getriebenen Großkonzern mit seinem hierarchischen Aufbau und seinen politischen Verflechtungen.

Lesson 1: Ohne wissenden Kunden wird's schwer!

Scrum basiert auf dem Grundsatz empirischer Prozesskontrolle mit den drei Säulen, Transparenz, Überprüfung, Anpassung. Konkreter bedeutet das: Ein gutes Produkt wird geschaffen, wenn es regelmäßig auf seinen Mehrwert, seine Funktionen hin geprüft und anhand der neuen Erkenntnisse verbessert wird.

Idealerweise begutachten und probieren diejenigen es aus, die seine tatsächlichen Anwender sind. Im Falle eines IT-Produkts können und sollten diese die besten Antworten auf wichtige Fragen geben können: Werden mir die relevanten Daten, die ich (für die Nachfolgeprozesse) brauche, geliefert? Liegen diese im richtigen Format vor? Ist die Abruf-Schnittstelle für mich verständlich und benutzbar gestaltet? Ist das Produkt auf die Häufigkeit meines Datenbedarfs eingestellt und bekomme ich keine uneindeutigen Fehlermeldungen?

Äußerst schlecht ist es daher, wenn die Konsumenten des Produkts keine Vorstellung davon haben, was sie tatsächlich benötigen, möglicherweise weil die strategische Eingliederung und Nachfolgeprozesse unbekannt sind. Das kann im schlimmsten Fall dazu führen, dass im Produkt am eigentlich im Unternehmen bestehenden, aber nebulösen Bedarf vorbei entwickelt wird.

Lesson 2: Nicht jeder feiert Agilität.

Dem ist möglicherweise besonders im Großkonzern mit seinen historisch gewachsenen Strukturen und fixen Karrierepfaden so. Aus der Praxis lassen sich zumindest drei Gruppen von Widersachern gegen agile Transformation ausmachen: Auf einer Seite stehen Methodik-Gegner, die – oftmals durch die jahrzehntelange Anwendung von Wasserfallmodellen geprägt – grundsätzliche Vorbehalte gegenüber neuen Arbeitsweisen haben. Weiterhin gibt es natürlich Skeptiker gegen agiles Vorgehen im konkreten Fall. Solche Einwände können teilweise berechtigt sein und sollten gehört werden, denn nicht für jedes Projektvorhaben ergeben sich Vorteile eines agilen Vorgehens.

Eine dritte, besonders vehemente Widersachergruppe gegen agilen Wandel sind Postenträger mit Statusverlustängsten. Oftmals entstehen Widerstände besonders hartnäckig auf der mittleren und unteren Managementebene. Unsicherheit darüber, ob sich Verantwortungsbereiche, Status und Karriereambitionen eines Teamleiters in die neuen Strukturen übertragen werden, lassen den Betreffenden bangen. Findet in der Organisation agiler Wandel statt, gilt für ihre Mitarbeiter das Credo "Love it or leave it".

Lesson 3: Das Mindset des Produktverantwortlichen ist entscheidend.

Dies gilt insbesondere dann, wenn die Organisation nicht durchgängig agil, sondern – wie im Falle vieler Großkonzerne – durch Politik und langsame Prozesse gekennzeichnet ist. Der Product Owner muss Stakeholder aktiv ansprechen und besonders umtriebig sein, insbesondere wenn ein Zustand wie in Lesson 1 besteht und direkte Kundenanforderungen sowie -feedback ausbleiben oder schwierig einzuholen sind.

Auch die Anforderungen an ihn, Funktionen klug für die Umsetzung zu priorisieren, sind hoch, wenn er dies verstärkt hypothesenbasiert und ohne Informationsrückfluss von Kunden tun muss. Zudem kennzeichnet sich ein guter Product Owner sicherlich dadurch, dass er eine auf Respekt und Augenhöhe basierende Beziehung mit dem Entwicklungsteam aufbaut. Er ist sich darüber im Klaren, dass das Team am besten weiß, wie umgesetzt wird und räumt dessen Beurteilungen daher genügend Raum ein.

Lesson 4: Alphatier bleibt Alphatier!

Scrum setzt auf die Auflösung von Hierarchien, die gemeinsam getragene Verantwortung und Selbstorganisation des Teams und unbedingten respektvollen Umgang auf Augenhöhe miteinander. Die Schlussfolgerung daraus zu treffen, dass in der agilen Entwicklung persönliche Verhaltensmuster und Machthierarchien (im Weitesten Sinne) vollständig aufgebrochen würden, ist jedoch falsch. Gesprächsanteile sind auch in Scrum-Teams und deren Meetings deutlich unterschiedlich verteilt, manche Mitglieder setzen sich mit ihren Lösungsansätzen konstant durch. Im besten Fall ist diese implizite Rangordnung anhand fachlicher Kompetenz- und Erfahrungsstände festgemacht, im schlechtesten Fall kann auch hier noch gelten: Wer am lautesten schreit…

Auch in der teamorientierten, selbstbestimmten Arbeitsweise gibt es noch Alphatiere. Der Umstand, dass Scrum die negativen Auswirkungen dessen stärker beschränkt als andere Vorgehensmodelle, sowie der Soll-Anspruch eines jeden Teams, nach einer möglichst hohen Demokratisierung zu streben, bleibt jedoch erhalten.

Lesson 5: Retros haben insbesondere den Wert, jeden zu Wort kommen zu lassen.

Nicht jede Retrospektive liefert eine Unmenge und qualitativ bedeutsame Erkenntnisse, die in Maßnahmen für den nächsten Sprint oder für längere Zeit münden. Dies gilt vermutlich insbesondere dann, wenn man mit kurzen Sprints (wie einem Zwei-Wochen-Rhythmus) arbeitet und entsprechend nicht ständig so kurzzyklisch neue Herausforderungen aufkommen.

Und das ist genauso okay. Manche Retros dienen "lediglich" dazu, das Team ohne operativen Lieferdruck zusammenzubringen und jedem die ausdrückliche Chance zu geben, einige Reflexionssätze zu sprechen. Manchmal ist es schlichtweg eine wohltuende Therapiesitzung, die das Team dazu zu bringt, sich wie ein solches zu fühlen und sich gegenseitig zu sagen, wie gern und effektiv man miteinander arbeitet.