Kommt drauf an. Nächste Frage, bitte.
So einfach ist es natürlich nicht. Lassen Sie uns die Frage konkretisieren:
Führt es zum Ziel, lediglich agile Methoden einzuführen? So wie statt eines Hammers eine Zange aus dem Werkzeugkoffer zu nehmen?
Und – wie ist das Ziel definiert? Schneller und kostengünstiger zu werden? Bessere Produkte zu entwickeln? Die Kunden zufriedener zu machen?
Ist agiles Vorgehen schneller als klassisches?
Ein verbreitetes Missverständnis lautet, dass es mit agilen Methoden schneller geht.
(Aus dieser Annahme folgt eine weitere Annahme: Es wird kostengünstiger.)
Wir stellen uns vor, dass wir eine neue Methode aus dem Koffer holen und die Projekte und Produkte künftig früher fertig werden.
Das Problem an dieser Sichtweise ist, dass die Methoden nur die Spitze des Eisbergs darstellen. Wenn der Bereich unter der Wasserlinie unverändert un-agil bleibt, werden neue Methoden nicht viel ändern:
Die Grundannahme ist falsch.
Der Kontext, in dem agile Methoden stattfinden, ist genauso wichtig wie die Methoden.
Das wird an einem Beispiel anschaulicher.
Wie die XY GmbH versucht, agiles Arbeiten einzuführen
Die fiktive XY GmbH entwickelt Software. Sie steht als Beispiel für eine Vielzahl von Unternehmen, die agiler werden wollen.
Das Management der XY steht vor den üblichen Problemen. Die interne Zusammenarbeit ist nicht gut, die Projekte dauern zu lange, und die Kunden werden unzufriedener.
Also beschließt der Geschäftsführer, dass ein Projekt als “Versuchsballon” agil durchgeführt werden soll.
Das Team bekommt eine Scrum-Schulung, eine Person übernimmt die Rolle des Scrum Masters, und eine andere die des Product Owners. Außerdem beruft die Firma eine Projektleiterin. Der Geschäftsführer möchte eine feste Ansprechpartnerin für das Projekt haben.
Damit sind die Vorbereitungen abgeschlossen, der Scope des Projekts wird fixiert, und die Arbeit beginnt.
Bestandsaufnahme
Nach einiger Zeit stellt der Geschäftsführer fest, dass die Verbesserung, die er sich von agilem Vorgehen erhofft hatte, nicht eingetreten ist. Das Projekt ist weit davon entfernt, Ergebnisse an die Kunden auszuliefern. Obwohl die Projektleiterin den Auftrag hatte, sich besonders darum zu kümmern.
Die Projektleiterin wiederum ist der Meinung, dass sie ihren Job nicht richtig machen konnte. Sie war es früher gewohnt, ihr Team zu steuern, und muss sich jetzt mit einem Scrum Master auseinandersetzen. Sie war es gewohnt, für die Inhalte verantwortlich zu sein, aber da gibt es einen Product Owner, der das gleiche Verständnis hat. Sie hat das Gefühl, dass ihre Aufgabe überwiegend darin besteht, im Lenkungsgremium den Druck abzubekommen und für das Reporting zuständig zu sein.
Das Team meint, dass sich gegenüber früher nichts geändert hat. In hoher Frequenz kommen zusätzliche Anforderungen herein. Abteilungsleiter und Projektleiterin mischen sich ständig auf der Arbeitsebene ein. Wie soll da ein vernünftiges Ergebnis herauskommen?
Bei allen Beteiligten reift die Erkenntnis heran: Agil funktioniert nicht. Jedenfalls ist es weit von den hohen Erwartungen entfernt. Damit ist das Experiment abgeschlossen – mit einem vermeintlichen Fehlschlag.
Ursachenforschung
Blicken wir tiefer, wird klar, dass es bei agilem Vorgehen nicht alleine um Methoden gehen kann. Eine Methode wie Scrum setzt auf bestimmten Werten und Prinzipien auf. Nur damit funktioniert es. Diese Werte und Prinzipien sind beim Agilen Manifest nachzulesen und repräsentieren den Bereich “unter der Wasseroberfläche”. Sie umfassen das “Mindset”.
Das Umfeld in der XY GmbH ist aber nicht geeignet, diese Werte und Prinzipien zu leben, oder sich dorthin zu entwickeln. Das Gerüst rund um das agile Projektteam bleibt klassisch geprägt, mit den üblichen Prozessen und Strukturen.
Schauen wir auf die einzelnen Probleme:
Es gibt eine Projektleiterin, die die Gesamtverantwortung für das Projekt hat.
Agile Teams brauchen Eigenverantwortung, um ihr Potential zu erreichen. Die Funktionen der Rolle “Projektleiter” erbringt das Team. Es trägt insgesamt auch die Verantwortung für das Ergebnis.
Bei Problemen gibt es im Lenkungsausschuss einen Anranzer für die Projektleiterin.
Moment, ein Lenkungsausschuss? Ein solches Gremium ist normalerweise mit Management-Vertretern besetzt, die es gewohnt sind, klassisch zu planen und zu steuern. Das passt nicht zu agilem Vorgehen, bei dem das Team das bestmögliche Produkt iterativ entwickelt.
Der Umfang des Projekts ist vorab definiert. Das Management erwartet, dass das Team diesen Scope im Sprint-Rhythmus umsetzt. Einen regelmäßigen Austausch mit den Kunden gibt es nicht.
Agile Projekte orientieren sich nicht an einem vorher festgelegten Pflichtenheft, sondern an dem Nutzen für die Kunden. Deshalb ist es wichtig, permanent Kundenfeedback einzuholen.
Der Product Owner hat keine echte Chance, die Inhalte des Produkts gemeinsam mit den Kunden zu bestimmen und festzulegen, welche Features das Team in welchem Sprint umsetzt.
Ein Product Owner braucht diese Befugnis, sonst kann er seine Rolle im Team nicht richtig ausfüllen.
Die Führungskräfte geben zusätzliche Aufträge und Feature-Wünsche direkt ins Team. Selbstverständlich hoch priorisiert und während der Laufzeit des Sprints.
Agile Teams liefern am besten, wenn sie in einem “geschützten Raum” konzentriert am aktuellen Inkrement arbeiten. Zusätzliche Feature-Wünsche landen im Backlog. Das Team arbeitet nach ihrer vereinbarten Priorität an ihnen.
Die Führungskräfte erwarten, dass das Team zu einem festgelegten Termin, weit in der Zukunft, einen definierten Umfang liefert. Das muss mit vernünftiger Planung doch machbar sein? Natürlich sind unterwegs wichtige Meilensteine zu halten.
Eine solche Denkweise hebelt effizientes agiles Vorgehen von vornherein aus. Mit deterministischen Ansätzen schafft die XY GmbH das denkbar ungünstigste Umfeld für agiles Arbeiten und für gute Ergebnisse.
Agiles Theater
Dieses Schauspiel beobachten wir häufig. Eine Methode wird eingeführt, die Regeln oberflächlich beachtet, die Rollen gespielt und die üblichen Meetings durchgeführt. Mit agilem Vorgehen hat das nicht viel zu tun; es heißt “agiles Theater”. Denn es ändert sich ansonsten nichts in der Organisation und ihrer Kultur.
Dann fällt der Vorhang, und wir schreiben das agile Experiment ab. Wir haben es versucht, aber es “klappt nicht”, oder es “passt nicht zu uns”.
Wirkungsvolle Agilität geht tiefer
Würden wir versuchen, eine aktuelle Videobearbeitungs-Software auf dem alten Windows XP zu installieren? Vermutlich nicht. Das Betriebssystem benötigt zuerst ein Upgrade.
Analog benötigen Organisationen, die agiles Vorgehen nutzen wollen, eventuell ein Upgrade. Manche mehr, manche weniger. Agile Methoden führen zum Ziel, wenn der Kontext und die Kultur erlauben, dass sie ihre Vorteile ausspielen.
Dabei sind folgende Prinzipien wichtig:
- Transparenz. Alle wesentlichen Informationen über die zu leistende Arbeit sind offen verfügbar. Alle Entscheidungen sind nachvollziehbar.
- Wille zur kontinuierlichen Verbesserung. Wir wissen, dass wir nicht perfekt sind, aber wir verpflichten uns gemeinsam, besser zu werden. Das gilt für alle, auch für Führungskräfte.
- Eingeständnis der Unplanbarkeit. In komplexen Umfeldern sind die herkömmlichen Methoden der Planung und Steuerung überfordert.
- Mut, mit Hypothesen zu arbeiten und iterativ vorzugehen. Bei komplexen Problemstellungen ist es der beste Weg, mit Hypothesen zu arbeiten. Anhand der Erkenntnisse finden wir schrittweise gute Lösungen.
- Mut zu Experimenten. Viele Manager haben Vorbehalte gegen Experimente. Damit haben sie in einem stabilen Produktionsumfeld zum Teil Recht. Aber in komplexen Umfeldern führen Experimente oft zum Ziel. Die Kunst besteht darin, ein Experiment so zu gestalten, dass es früh Erkenntnisse liefert.
- Regelmäßig mit den Kunden sprechen. Nur so wird das Produkt die Bedürfnisse der Kunden treffen und einen echten Wert schaffen.
- Vertrauen in das Team. Es besteht in der Regel aus Menschen, die fähig und willens sind, ein gutes Ergebnis abzuliefern und sich zu organisieren.
Und da ist noch ein wichtiger Punkt
Bevor wir uns in ein agiles Experiment stürzen, ist es hilfreich, einen Moment innezuhalten. Eignet sich agiles Vorgehen für unsere Problemstellung überhaupt? Das ist nicht immer der Fall.
Hätte die XY GmbH für ihre Projekt-Probleme eine andere Lösung finden können? Das ist denkbar.
Aber woran machen wir das fest?
Um herauszufinden, ob Agilität für ein Vorhaben oder für einen Organisationsteil sinnvoll ist, schätzen wir das Umfeld ein. Wir bewerten, ob wir uns in einem einfachen, komplizierten, komplexen oder chaotischen Umfeld bewegen. Erst dann wählen wir die geeignete Vorgehensweise. Dabei helfen uns Tools wie die Stacey-Matrix – und Menschen mit Erfahrung.
Fazit
Methoden alleine bringen oft nichts. Sie schöpfen ihr Potential nur aus, wenn das Umfeld und die Kultur mit einem geeigneten Mindset einhergehen.
Für die Entscheidung, Agilität sinnvoll zu nutzen, haben Sie in mir den richtigen Partner. Der Weg zu mehr Agilität in Ihrer Organisation sieht so aus:
- Wir finden zusammen heraus, wo Sie stehen und was Sie benötigen.
- Ich unterstütze Sie und Ihre Teams und Führungskräfte durch Training und Coaching.
- Wir beginnen an einer geeigneten Stelle.
Besprechen wir gemeinsam Ihre Aufgabenstellung. Ihre Organisation wird kein agiles Theater veranstalten, sondern tatsächlich von Agilität profitieren.
