Agilität als solches (basierend auf dem Agilen Manifest[1]) wird diesen Monat volljährig. Vor dem Agilen Manifest wurden verschiedenste agile Ansätze (XP, Crystal, verschiedene Vorgänger von Scrum) bereits 10 Jahre lang angewandt. Zeit ein kleines Fazit zu ziehen.
Es geht darum den Benutzer zu verzücken
The Good
Kundenfokus - der Kunde steht im Mittelpunkt
Mit der Agilität kamen einige gute Aspekte. Der Fokus für das Entwicklungsteam änderte sich. Weg vom reinen Liefern der spezifizierten Funktionalität hin zur Lieferung echten Mehrwerts für den Benutzer der Software. War vorher in traditionellen Softwareentwicklungsvorhaben die Einhaltung von Zeit, Budget und besonders Scope zentral, geht es heute eher darum herauszufinden, was dem Benutzer wirklich einen Mehrwert bringt. Dieser wird geliefert und erneut wird geprüft, was als nächstes den meisten Mehrwert bringt. Es geht darum den Benutzer zu verzücken (How to make the whole organization agile?).
Weg von den Ideen der Industrialisierung und hin zur Wissensarbeit
Natürlich kann argumentiert werden, dass diese Veränderung nicht (alleine) aus der Agilität kam. Sondern die Art und Weise wie viele Firmen funktionieren, hat sich geändert: weg von den Ideen der Industrialisierung und hin zur Wissensarbeit.
Einzelne, kleine, agile Teams liefern direkten Kundennutzen
Ein anderer positiver Aspekt, den die Agilität mit sich brachte, war die Rückbesinnung auf einzelne, kleine, schlagkräftige Teams. Diese vereinen alle Eigenschaften, um ein Produkt von der Idee bis zur Optimierung für den Benutzer umzusetzen. Dies erfordert, dass das Team über die benötigten Skills verfügt, oft als "interdisziplinäres Team" oder auch "cross-funktionales Team" bezeichnet.
Interdisziplinäre Teams sind jedoch auch nur dann erfolgreicher, wenn man ihnen den nötigen Freiraum lässt die optimale Lösung für ein Kundenproblem zu finden und liefern zu können. Ein entsprechender gestalterischer Freiraum wird den agilen Teams gegeben. Da die Teams direkt im Kontakt mit dem Benutzer stehen, können sie aus erster Hand Feedback darüber erhalten, wie gut oder schlecht die gelieferte Lösung das ursprüngliche Problem löst und entsprechende Anpassungen vornehmen.
Dies alles ist jedoch nur möglich, weil nicht länger in langen Release-Zyklen, sondern möglichst früh und möglichst oft ausgeliefert wird. Somit besteht die Möglichkeit häufig Feedback von echten Benutzer zu sammeln. Das agile Team nähert sich schrittweise der optimalen Lösung und liefert kontinuierlich Mehrwert an den Benutzer.
The Bad
Bei einem Fazit - und besonders bei einem das ein "volljähriges" Konstrukt betrachtet - sollten auch die negativen Aspekte berücksichtigt werden. Auch diese sind vorhanden bei der Auseinandersetzung mit Agilität.
Viele (besonders grössere) Firmen haben Mühe mit der Umstellung auf agile Entwicklung. Deshalb werden oft die bestehenden Frameworks zusammengestrichen und bestehende Methoden mit aufgenommen, bis das agile Framework recht schnell dem bisherigen Vorgehen ähnelt. Die Begründungen reichen dabei von kreativ bis skurril. "Wir sind in einem regulierten Markt, wir müssen das so machen", "wir machen das schon seit Jahren so und es funktioniert für uns", "das kann bei uns nicht funktionieren, wir sind anders als xyz", …
… das kann bei uns nicht funktionieren, wir sind anders …
Die meisten Unternehmen, die diese oder ähnliche Aussagen treffen, haben oft nicht einmal die grundlegenden Ideen des Agile Manifesto verstanden.
Vielleicht aus diesem Grund (und dem Grund, dass das Agile Manifesto eben doch recht viel offen lässt) kommen fast monatlich neue Frameworks oder Varianten von agilen Frameworks "auf den Markt". Das hat zur Folge, dass sich schlussendlich jeder irgendwo wiederfinden kann ohne sich gross ändern zu müssen.
Dieser Trend ist besonders dort auffällig, wo meist grössere Firmen ihre über die Jahre gewachsene und auf möglichst effizienten Betrieb optimierten Plattformen und Applikationen agil weiterentwickeln oder erneuern wollen. Die meisten gehen davon aus, dass die neue Version ähnlich aussehen muss wie die alte und somit mindestens so gross und kompliziert werden muss. Also braucht man auch viele Mitarbeiter dafür. Diese dann noch einigermassen koordinieren zu können ist mit der ursprünglichen Idee von kleinen, selbständigen Teams nicht möglich. Wahrscheinlich haben sich aus diesem Grund die Frameworks für die Skalierung von Agilität in den grösseren Firmen besonders durchgesetzt.
Wir wählen das Framework, das «am besten zu uns passt» (bei dem wir uns am wenigsten ändern müssen)
Somit steht noch mehr Auswahl zur Verfügung; vielleicht zu viel. Häufig wird das Framework gewählt, in dem sich das Unternehmen zum aktuellen Zeitpunkt am ehesten wiederfindet.
Bei Einführung eines agilen Frameworks in einem Unternehmen über die Teamebene hinaus, konzentriert sich der Fokus oft auf den Prozess. Zusätzlich wird hoher Aufwand für die folgenden zwei Punkte betrieben:
- Offene Fragen müssen vor Anwendung des Frameworks beantwortet sein.
- Es muss sichergestellt sein, sich bis ins kleinste Detail genau daran zu halten.
Es werden die entsprechenden Prozesse definiert und eine mehr oder weniger dazu passende Governance erstellt. Man tauscht den einen (traditionellen) Prozess gegen den nächsten (agilen) Prozess ein.
Eintauschen des traditionellen Prozesses gegen den "agilen Prozess"
Die Erfahrung zeigt, dass die Adaption von agilen Vorgehensweisen auf Teamebene gut umsetzbar ist, solange die nötige Unterstützung und der Wille in der Organisation vorhanden ist. Die Adaption von Agilität oberhalb der Teamebene erweist sich als um einiges schwieriger. Die Praxis zeigt eine (wieder) zu starke Fokussierung auf die Prozesse, zumindest in den traditionellen Firmen.
The Ugly
Ja, leider gibt es bei diesem Fazit auch einen unschönen Teil, der aus der Agilität resultiert.
Unternehmen investieren viel Zeit und grosse Anstrengungen um Agilität einzuführen. Dabei geht der Fokus von Agilität verloren: Den Kunden in den Mittelpunkt zu stellen. Der ursprüngliche positive Aspekt wird zugunsten von "wie Agilität geht", also dem Prozess, wieder vernachlässigt.
Von der Kundenorientierung zurück zur Prozessorientierung?
Ein anderer unschöner Teil der Agilität ist, wie vorher schon angesprochen, die Skalierung. Die Art und Weise wie verschiedene Skalierungs-Frameworks in den Unternehmen eingeführt werden, unterstützt die traditionelle Command and Control Struktur der Unternehmung. Die Intelligenz und Innovationskraft der Mitarbeiter wird dabei oft unterdrückt oder vergessen. Das Bestreben, doch den einen Prozess für die ganze Firma definieren zu wollen ist wichtiger, als dass der Benutzer der einzelnen Produkte zufrieden oder sogar entzückt ist. Auch hier beschäftigt sich das Unternehmen wieder mehr mit sich selbst, als mit dem Kunden.
Fazit
Nachdem Agilität nun "volljährig" wird, ist es vielleicht so langsam an der Zeit, sich auf die echten Werte dahinter zurückzubesinnen. Den Fokus auf den Kunden legen und diesen verzücken. Um dies vollständig zu erreichen, ist es ebenfalls an der Zeit, Agilität ein für alle Mal aus der (verstaubten) IT-Ecke zu holen und in der gesamten Firma zu leben.
«Ihren Weg Dinge zu tun…»
Was haben die folgenden Firmen gemein: Google, Amazon, Zara, Zappos, Netflix, Spotify? Keine dieser Firmen würde sagen, dass sie dieses oder jenes Agile Framework verwenden. Sie verwenden «ihren Weg, Dinge zu tun».
Agilität heisst also nicht, das nächste Framework einzuführen, sondern einen Weg zu finden, als Unternehmen so agil zu werden, dass man seine Kunden immer wieder aufs neue entzücken kann. Darauf sollten wir uns fokussieren!
[1]: Agile Manifesto