Warum agile Teams allein nicht bei der Business-Agilität helfen

Agilität ist eines der Top-Suchbegriffe in der letzten Zeit. Gerade während der Corona-Pandemie hat der Hype um die Themen Agilität und Digitalisierung noch mal richtig an Geschwindigkeit aufgenommen. Agilität ist allerdings kein Selbstzweck. Dahinter stecken andere Unternehmensziele, als einfach nur ein agiles Team zu haben. Die Ernüchterung in den Unternehmen ist oft groß, wenn mit den agilen Teams nicht die gewünschten Ziele erreicht werden. In diesem Artikel geht es um den Unterschied zwischen Agilität und Business-Agilität. Ich werde aufzeigen, warum agile Teams alleine nicht helfen, die gewünschten Ergebnisse zu erreichen.

Warum brauchen wir Agilität und agile Teams?

Hinter dem Wunsch der Unternehmen, agiler zu werden, stecken oft andere Bestrebungen. Es ist viel mehr der Bedarf, die folgenden Ziele zu erreichen:

  • Wir müssen schneller werden
  • Wir müssen mehr und öfters mit dem Kunden interagieren
  • Wir müssen dynamischer sein, als der Wettbewerb
  • Wir müssen digitaler werden, um die Zukunft abzusichern
  • Wir müssen anpassungsfähiger werden, um schneller reagieren zu können
  • und viele andere Ziele mehr….

Ein großes Problem viele Unternehmen ist, dass die eigene Entwicklungszeit von neuen Produkten oder Dienstleistungen einfach viel zu lange dauert. Die Konkurrenz scheint einfach viel schneller und dynamischer zu sein. Die Ideen sind da, die Kreativität sprudelt, aber die Umsetzung lahmt.

Das Zaubermittel agile Teams

Ein Unternehmensziel ist vor allem, die Entwicklungszeit zu reduzieren. Agilität bedeutet jedoch nicht Schnelligkeit. Es ist ein Synonym für Flexibilität. Ich schaffe es damit, mein Unternehmen anpassungsfähiger zu machen und damit schneller auf Veränderungen zu reagieren. Agile Teams allein sind daher kein Zaubermittel und können nicht die gleiche Arbeit in kürzerer Zeit erledigen. Agilität kann mit Faszien verglichen werden. Sie helfen dem Unternehmen bzw. dem Körper flexibler und beweglicher zu sein. Nur Faszientraining allein bringt mir aber keine neuen Geschwindigkeitsrekorde.

Sind agile Teams nur in der Entwicklungsabteilung zu finden?

Ohne darüber eine Studie gelesen zu haben, ist meine Vermutung, dass die meisten agilen Teams in der SW-Entwicklung zu finden sind. Das ist keine besonders große Überraschung. Die Geschichte der Agilität und dem agilen Manifesto sind zwar schon ein paar Jahrzehnte alt, allerdings kam der Durchbruch mit der agilen SW-Entwicklung. Leider ist dieser Umstand Fluch und Segen zu gleich. Die Methoden und Denkansätze der agilen SW-Entwicklung können als Vorbild für andere Bereiche genutzt werden. Es hat die IT-Branche und insbesondere die Entwicklung von digitalen Produkten sehr stark beeinflusst. Es führt aber zu einem großen Denkfehler.

Agilität in der Entwicklungsabteilung allein ist nicht ausreichend

Es ist nicht ausreichend, wenn nur die Teams in der Entwicklungsabteilung mit agilen Methoden arbeiten. Wenn beispielsweise an einem digitalen Produkt gearbeitet wird und nur die SW-Entwicklung agil arbeitet, wird das Gesamtunternehmen dadurch nicht agiler. Das ist ein Grund, warum die Ernüchterung in den Unternehmen nach dem Einsatz von agilen Teams so groß ist. Die Erwartungen sind hoch und agile Teams sowie agile Methoden können helfen, die Gesamtorganisation anpassungsfähiger zu machen. Allerdings muss ich dann nicht nur in der Entwicklungsabteilung agil denken.

Warum Abhängigkeiten die Durchlaufzeiten negativ beeinflussen

Wenn ich von Durchlaufzeiten spreche, meine ich damit die Zeit von einer Produktidee bis zu dem Zeitpunkt, in dem der Endkunde das Produkt tatsächlich ausprobieren kann. Damit ist nicht nur die Entwicklungszeit gemeint. Die gesamte Produktentwicklungskette oder auch Wertstrom genannt, hat sehr viele Abhängigkeiten untereinander. Es ist dabei häufig nicht als lineare Reihenfolge von Tätigkeiten zu sehen. Viel mehr ist ein Netzwerk aus unterschiedlichen Abteilungen und Aufgabenbereichen.

Wenn dort mit lokalen Optimierungen einzelne Teams agil arbeiten, dann wird das Team zwar anpassungsfähiger, nicht jedoch die gesamte Produktentwicklungskette. Es führt dazu, dass die agil arbeitenden Teams aufgrund der Abhängigkeiten nicht weiter arbeiten können. Beispielsweise, wenn Informationen oder Feedback fehlt. Weiterhin ist es möglich, dass ein neues SW-Release nicht veröffentlicht wird, weil die internen Freigaben fehlen oder der Customer Support noch nicht geschult ist.

Bei der Betrachtung muss immer der gesamte Wertstrom, also die gesamte Wertschöpfungskette, betrachtet werden. Diese Tatsache liest sich einfach, ist aber manchmal schwer in die Realität anzuwenden.

Für eine einfache grafische Darstellung habe ich die einzelnen Aufgaben bei der Entwicklung eines neuen Produktes linear angeordnet. Die Aufzählung ist absichtlich nicht vollständig, um mehr Fokus auf das eigentliche Problem zu legen. Die Realität kann deutlich komplexer sein.

Spannungen zwischen agilen Teams
Vereinfachte Darstellung vom Produktentwicklungsprozess

Die vereinfachte Darstellung soll vor allem darstellen, wie die Agilität und auch die Geschwindigkeit leidet, wenn ich Schnittstellen zwischen Teams habe, welche nicht agil arbeiten. Es soll dabei nicht der Eindruck entstehen, dass alle Teams agil arbeiten müssen. Allerdings muss die Erwartungshaltung an die agilen Teams angepasst werden.

Es ist für ein agiles Team unmöglich, jede Woche oder jeden Monat neue SW-Releases auf den Markt zu bringen, wenn beispielsweise die Freigabeabteilung keine Testkapazität hat und nicht agil arbeitet. Das Gleiche gilt für die Kundenanforderungen. Wenn Produkte, Features und konkrete Zeitleisten aufgrund von strategischen Initiativen für die nächsten Jahre bereits geplant sind, warum benötige ich dann die Anpassungsfähigkeit meines Software-Teams?

Die wirklichen Vorteile von agil arbeitenden Teams sind die Flexibilität und die Anpassungsfähigkeit. Das Team kann schnell auf Veränderungen reagieren. Es wird kein definiertes Lastenheft benötigt. Produkte können iterativ mit MVPs entwickelt und Kundenfeedback berücksichtigt werden. Wenn ich diese Vorteile nutzen möchte, müssen die Produktanforderungen dies aber auch zu lassen. Die Agilität wird nicht nur in der Entwicklung selbst benötigt, sondern bereits bei der Planung und Konzeption.

Business-Agilität benötigt ein abteilungsübergreifendes Denken

Wenn ein Unternehmen wirklich die oben genannten Ziele erreichen will, muss es aufhören, Agilität nur innerhalb von ausgewählten Abteilungen einzufordern. Der gesamte Prozess, beispielsweise bei der Produktentwicklung muss angepasst werden. Das bedeutet aber auch, dass nicht nur Prozesse auf dem Papier angepasst werden. Es wird viel mehr ein neues Selbstverständnis benötigt. Gemeinsame Ziele und weniger Abteilungssilos helfen bei der Erreichung von Business-Agilität. Weiterhin helfen wirklich crossfunktionale Teams. Damit sind nicht nur SW-Entwickler, Product Owner und Scrum Master gemeint. Wenn ein Team in der Lage sein soll, ein Produkt zu entwickeln und auf den Markt zu bringen, müssen alle dafür notwendigen Personen beteiligt sein und auch die entsprechende Kapazität dafür haben.

Schlussbetrachtung

Das Ziel dieses Artikels ist es nicht einzufordern, dass sofort alle Teams agil arbeiten. Das ist utopisch und nicht zielführend. Es geht viel mehr um die Erwartungshaltung. Agile Teams können nur scheitern mit der Erwartungshaltung, dass durch die lokale Optimierung in einzelnen Teams die gesamte Business-Agilität steigt. Dieser Artikel soll zum Nachdenken anregen, den gesamten Wertstrom, welcher für die Entwicklung des Produktes oder Services benötigt ist, zu betrachten. Welche Brüche habe ich zwischen agil arbeitenden und nicht agil arbeitenden Teams? Wo wird mehr Interaktion oder Feedback zwischen den Teams benötigt?

Agilität kann helfen Unternehmen anpassungsfähiger zu machen. Es ist allerdings kein Zaubermittel, was alle Probleme löst.