Suche
Die Kultur entscheidet über den Erfolg

Skaliertes Management: Agile in großen Unternehmen

Ann-Cathrin Klose

© Shutterstock.com / Jaaak

Agile auf Unternehmensebene zu skalieren gilt als Herausforderung. Oft sind die Differenzen zwischen den Bedürfnissen des Managements und der agilen Methodenwelt zu groß. Sollte man den Schritt zum agilen Großunternehmen also lieber sein lassen?

Der agile Wandel ist meist leicht, wenn es nur um wenige Entwickler-Teams geht, die agil arbeiten sollen. Den Teams wird erklärt, was es mit Agile oder dem gewählten Framework auf sich hat und dann lässt man sie mal machen. Ganz einfach, richtig? Schon hier zeigt sich unmittelbar, wo die Stolpersteine liegen: Nur dann, wenn auch das Management mitzieht und die Teams nicht blockiert, kann die Umstellung auf agile Methoden gelingen. Je kleiner das Unternehmen ist, desto leichter gelingt das natürlich.

Das gilt beispielsweise für Startups mit 20 Mitarbeitern, die sich allesamt kennen, ständig miteinander abstimmen können und gegenseitig vertrauen. Jeder kennt jeden, flache Hierarchien lassen sich schnell realisieren, es müssen keine verkrusteten Managementstrukturen aufgebrochen werden. Auf solche Situationen sind Scrum und Co. ausgelegt. Was passiert aber, wenn das Unternehmen keine 20, sondern 5.000 Mitarbeiter hat und jeder davon künftig den agilen Gedanken umsetzen soll?

Agile mit multifunktionalen Teams

Auf Teamebene macht auch das erst einmal keinen großen Unterschied. Multifunktionale, unabhängig arbeitende Teams funktionieren überall gleich. Sie treffen eigene Entscheidungen, entwickeln Features vom ersten Schritt bis zur Auslieferung und machen alles selbst, was damit zu tun hat. Und doch steht diesem einfachen Konzept häufig der administrative Überhang im Weg, wenn dieser zu groß wird.

Während die Entwicklerteams ganz einfach weiterhin Code schreiben, also im Endeffekt genau das gleiche machen wie vorher, muss sich das Management nämlich deutlich stärker umstellen als die agilen Teams. Budgetplanungen funktionieren anders, wenn das Team nur den nächsten Monat voraus plant; auch Verträge müssen agil anders gestaltet werden als im klassischen Wasserfall-Modell. Und mitten in all diesen Veränderungen soll die Führungsebene dann auch noch aufhören, dem Team vorzuschreiben, was es zu tun hat. Freiheit, das ist die neue Maxime! Aber für wen? Auf Managementebene entstehen so schnell Missverständnisse und Konflikte, an denen der agile Prozess scheitern kann.

W-JAX
 
Frank Sons

Effective Code Reviews

with Frank Sons (code-quality.de)

Alexander Casall

UX für Techies

mit Alexander Casall (Saxonia Systems)

Verschiedene Bedürfnisse im Projektmanagement

Eine große Hürde stellt nämlich das Bedürfnis des Projektmanagements nach Informationen und fundierten geschäftlichen Entscheidungen dar; auf der anderen Seite steht das Interesse der agilen Teams, Werte für den Endnutzer oder Kunden zu schaffen. Sowohl dann, wenn Projektmanager zu wenige Daten erhalten, als auch dann, wenn sie sich zu viele beschaffen, wird es darum problematisch. In beiden Fällen wird die agile Arbeitsweise behindert. Darum muss die geschäftliche Perspektive von Anfang an auf Unternehmensebene mit bedacht werden.

Ein Fehler besteht darin, sich zu sehr von agilen Maßstäben vereinnahmen zu lassen. User Stories stellen zwar eine gute Perspektive auf die Usability und den Funktionsumfang des Produkts dar, bilden andere Sichtweisen aber nicht ab. Abstraktere Interessensebenen und feinere Details bleiben außen vor, wenn ausschließlich damit gearbeitet wird. Ruth Zive empfiehlt darum, auch mit visuellen Modellen und Simulationen zu arbeiten, um das Gesamtbild für alle Projektbeteiligten transparent zu machen. Das stützt die Interessen des Projektmanagements, ohne die agile Ebene zu verlassen.

Messbarer agiler Erfolg?

Die zweite Hürde besteht in der Kontrolle des Projektfortschritts. Der Fortschritt agiler Projekte kann anhand verschiedener Maßstäbe kontrolliert werden – viele davon sind jedoch gar nicht gut dafür geeignet. Manche Management-Tools spucken beispielsweise automatisch die eine oder andere Auswertung darüber aus, wie gut ein Team arbeitet. Diese Bewertungen sollten dringend ignoriert werden. Sie gehen nicht auf die situativen Faktoren ein, die in agilen Projekten immer mit einkalkuliert werden müssen. Sonst ist ein Urteil über die Arbeitsleistung agiler Teams nicht aussagekräftig. Personenbezogene Metriken sollten in Agile ebenfalls außen vor bleiben: Agile ist eine gemeinsame Leistung, individuelle Leistungsschwankungen sind normal.

Häufig wird die Velocity zur Beurteilung der Teamleistung herangezogen, was allerdings keine gute Idee ist. Die Velocity berechnet sich aus den Story Points, die innerhalb eines Sprints abgearbeitet wurden. Ist ein Kollege krank, sinkt sie also. Das passiert ebenfalls, wenn plötzlich ein großer Bug gelöst werden muss, der nicht eingeplant war. Zwar mittelt sich langfristig die kontinuierliche Behebung von Fehlern im Code aus, sodass die Velocity sich auf einen Wert einschwingt, der nicht mehr von den üblichen, kleinen Bugs beeinflusst wird. Und doch bleibt dieser Maßstab insgesamt immer unzuverlässig und eignet sich höchstens zur langfristigen Beobachtung von Tendenzen.

Subjektive Zufriedenheit

Als Yahoo! anfing Scrum einzuführen, entschied man sich, die Teamleiter der nun agil arbeitenden Teams zum Erfolg der neuen Arbeitsweise zu befragen. Zwar ist auch das ein subjektiver Maßstab; er bietet sich für große Unternehmen jedoch an, da ein Vergleich der Zufriedenheit über viele Teams hinweg erfolgen kann. Fällt das Urteil positiv aus, deutet dies darauf hin, dass das Unternehmen auf dem richtigen Weg ist.

Auch darüber hinaus ist die Mitarbeiterzufriedenheit allerdings ein guter Indikator dafür, ob der agile Wandel auf Unternehmensebene gelungen ist oder nicht. Wenn Misstrauen und Druck herrschen, die Leitungsebene angespannt ist, während die Entwickler sich an ganz wichtigen Änderungen abarbeiten, die am besten schon gestern hätten fertig sein sollen, stimmt etwas nicht. Je größer das Unternehmen, desto schneller kommt es zu solchen Situationen, weil alle beteiligten Stakeholder und Manager mit dem Team an einem Strang ziehen müssen. Sonst kann Agile nicht gelingen.

Scrum & Co. – skalierte Frameworks als Lösung?

Hier hilft es, sich auf die Grundwerte der agilen Arbeitsweise zu konzentrieren. Zwar können auch skalierte agile Frameworks dabei helfen, das ganze Unternehmen an Bord zu bekommen. Auch damit muss aber immer bedacht werden, dass agile mit seinen Grundpfeilern steht und fällt. Außerdem sind die skalierten Frameworks nicht unumstritten!

Eine häufig geäußerte Kritik an skalierten Frameworks lautet, dass sie die Differenzen zwischen dem Management, das auf geschäftliche Ziele ausgerichtet ist, und der Team-Ebene lösen, indem sie die Freiheit der Teams beschneiden. So sollen alte Strukturen erhalten bleiben, denen nur ein neuer Name übergestülpt wird. Es entstehe kein echter agiler Prozess, so die Kritiker. Nicht jeder sieht die skalierten Frameworks zwar so kritisch; als optimale Lösung gelten sie jedoch gemeinhin nicht. Skalierte Frameworks werden zumeist als Zwischenschritt auf dem Weg zum agilen Unternehmen gesehen. Ein guter Einstieg, aber nicht das Endziel.

Ein langsamer Lernprozess

Besser ist es nämlich, wenn skalierte agile Lösungen langsam wachsen. Jeder Mitarbeiter im Unternehmen sollte die Möglichkeit dazu erhalten, an Schulungen teilzunehmen und neue Wege auszuprobieren. Dabei müssen natürlich sowohl die geschäftlichen Interessen als auch die agilen Grundwerte bedacht werden – sonst kommt es den benannten Konflikten.

Dabei muss auch nicht zwingend mit einem skalierten Framework gearbeitet werden. Zwar ist Scrum nicht darauf ausgelegt, in großen Unternehmen eingesetzt zu werden; Scrum eignet sich aber durchaus dazu, individuell an die Bedürfnisse eines Unternehmens angepasst zu werden. Zusammen mit einer Lean-Management-Methode für die Führungsebene kann damit viel erreicht werden. Seit dem vergangenen Jahr stellt Scrum die eigenen Grundwerte seiner agilen Arbeitsweise mehr in den Mittelpunkt des Frameworks. Diese Grundwerte können als Wegweiser zu einer eigenen Scrum-Adaption genutzt werden. Am Ende geht es nämlich um die Unternehmenskultur, die sich ändern muss, damit Agile gelingt.

Agile Grundwerte für eine gute Kultur

Courage, Focus, Commitment, Respect und Openness sind die Grundwerte, die im Sommer 2016 in den offiziellen Scrum Guide aufgenommen wurden. Zwar beziehen sich diese Werte erst einmal auf die Team-Ebene; ein ehrlicher Austausch mit den Kollegen, das gemeinsame Lernen, ohne andere zu verurteilen, Offenheit gegenüber allen Beteiligten, auch bei Problemen sind aber auch auf Unternehmensebene wichtig. Wer das umsetzt, ändern die Philosophie und Kultur eines Unternehmens nachhaltig.

Wenn sich Management und Team auf einer ehrlichen, respektvollen Ebene begegnen, die Arbeit und Bedürfnisse des Anderen ernst nehmen und einen gemeinsamen Weg finden, kann der agile Wandel auch in großen Projekten gelingen. Es muss aber auch immer daran gedacht werden, dass Agile nicht auf Teamebene endet. Auch die Bedürfnisse des Managements müssen gehört und ernst genommen werden. Wenn das gelingt, finden irgendwann alle Mitarbeiter im agilen Prozess zusammen.

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose studiert allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz. Seit Februar 2015 verstärkt sie als redaktionelle Mitarbeiterin die Redaktion bei Software & Support Media. Zuvor war sie als freie Autorin tätig und hat erste redaktionelle Erfahrungen bei einer Tageszeitung gesammelt.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.