Agilität in Konzernen: Das Problem sind nicht die Entwickler

Trotz des Wandels zur agilen Softwareentwicklung sind große Teile der Produktentwicklung nicht agil. Das führt zu - vermeidbaren - Problemen.

Ein Erfahrungsbericht von Dean Tomasevic veröffentlicht am 4. April 2022, 9:00 Uhr

Agile Arbeitsweise ist aber nichts, das von heute auf morgen scharfgeschaltet werden kann. (Bild: Pixabay)

Viele, die in der Software-Entwicklung arbeiten, kennen diese Situation: Ein Sprint für ein Produkt läuft, die nächsten Sprints sind schon geplant, plötzlich heißt es vom Management: "Wir schneiden die Teams anders. Es kommen mehr Leute, damit wir schneller werden."

Das Team reagiert genervt, denn eigentlich lief doch alles gut: Es hat die Sprints geplant. Und es hat die Impediments, also alles, was ein Team daran hindert, das Sprintziel zu erreichen, aufgezeigt und behoben. Nun sollen die Teams verändert werden und neue Leute reinkommen, die auch noch eingearbeitet werden müssen? Und das soll das Projekt beschleunigen?

"Verrückt", denken sich da die Entwickler. Und auch: "Wie sollen wir agil arbeiten, wenn es am Ende doch wieder nur ums Budget, um Zahlen und ums schnellere Fertigwerden geht?"

IT-Abteilungen sind agil, andere oft nicht

Eigentlich geht es beim agilen Arbeiten vor allem darum, anpassungsfähig zu werden, also auf Veränderungen besser reagieren zu können - zum Nutzen des Produkts, der Kunden und damit auch des Unternehmens. In der Praxis kämpfen Entwicklerteams jedoch damit, dass Story Points in Personentage umgerechnet werden; dass Features an bestimmte Budgets geknüpft sind; dass Features irgendwann als geliefert gelten. Das Budget hierzu ist dann abgeschrieben und wenn anschließend daran noch weitere Arbeiten gemacht werden müssen, stellt sich die Frage: Worauf buchen wir das?

Am Ende werden die Projektstunden auf das allgemeine Projekt gebucht. Das ist zwar gemütlich für die Teams. Es ist aber suboptimal für das Unternehmen, denn hier schließt sich der Kreis: Wenn die Teams Features abgeschlossen haben, das Budget abgeschrieben ist, wie kann hier iterativ und agil - einfach kundenorientiert - ein Produkt entwickelt werden? Gar nicht.

Dabei wird heutzutage häufig Agilität von Bewerbern in der IT gefordert und steht in vielen Stellenanzeigen. In IT-Teams ist Arbeiten nach dem Manifest für agile Softwareentwicklung weit verbreitet. Die meisten Entwickler-Teams, die ich kenne, sind mit einem Scrum Master und einem Product Owner ausgestattet, die Teil des Konzepts sind.

Viele Unternehmen haben bereits vor einigen Jahren begonnen, sich agil aufzustellen - zumindest bezogen auf unsere kleine IT-Blase. Schauen wir uns eine Studie von Kienbaum & Stepstone aus dem Jahr 2020 an, sind aber insgesamt nicht einmal zehn Prozent der deutschen Unternehmen agil aufgestellt - und das, obwohl ein Großteil der Befragten agilen Methoden wie Scrum oder Kanban gegenüber offen ist. Besonders selten werden Einkauf und HR der agilen Transformation unterzogen.

Pseudo-Wasserfall statt echt agil

In der Praxis treffen dann zwei extreme Welten aufeinander: mit Entwicklern, die Agilität wirklich ernst meinen, und Fachabteilungen und Managern, die es auch ernst meinen, selbst aber nicht agil aufgestellt sind und die Prinzipien nicht richtig verstanden haben. Was als agiles Projekt beworben wird, ist im Alltag häufig ein Pseudo-Wasserfallprojekt, weil die Fachabteilungen, das mittlere Management und andere Entscheidungsebenen im Konzernumfeld nicht produkt- und/oder kundengetrieben sind - sondern budgetgetrieben.

Ein Beispiel aus meiner Erfahrung: Als Apple 2017 Face ID einführte und es sich nach einigen Monaten als Standard durchsetzte, hätten wir aus der Entwicklung heraus gerne das Feature des Logins über Face ID implementiert. Zum einen natürlich, weil wir nah dran waren und selbst genügend Apps nutzten, die es bereits implementiert hatten. Vor allem aber, weil wir gemerkt haben, dass Face ID einen echten Vorteil für Endkunden hat. Die App ist schlichtweg einfacher zu bedienen.

Schließlich kam das Feature auch, allerdings erst zwei Jahre später. Denn es war der Entscheidungsebene offenbar einfach nicht rentabel genug. Nun mag man sagen: Es gibt doch einen Product Owner, der darf die Priorität bestimmen und genau so etwas könnte er höher priorisieren - oder?

Ja, in der Theorie stimmt das. Im Umfeld der großen IT-Projekte, bei denen beispielsweise externe Dienstleister tätig sind, fungiert man jedoch oft als Proxy Product Owner. Das heißt: Im Prinzip kann der Product Owner Prioritäten setzen - aber nur bis zu einem gewissen Grad und nach Vorgabe von oben.

Das Ergebnis sind dann oft frustrierte Entwicklungsabteilungen auf der einen Seite und frustrierte Manager auf der anderen, die die Entwickler als Neinsager und Nörgler empfinden. Doch das müsste nicht so laufen.