Über die agile Transformation von Organisationen, ihre Bedeutung im Rahmen digitaler Transformationen, aber auch über Prozesse, Methoden, Roadmaps und best practices ist schon viel geschrieben worden.
Um ein Thema machen viele Agile Coaches und Autoren allerdings gerne einen großen Bogen, obwohl genau diese Frage vielen Organisationen in der Praxis echte Kopfschmerzen bereitet. Ein Grund dafür mag sein, dass sich diese Frage auch erst in der Praxis stellt, denn in der Theorie sieht das alles ja immer ganz schön einfach und einleuchtend aus.
Es ist die Frage, wie werden Teams eigentlich transformiert, also wie mache ich aus einem gewachsenen Team, welches schon viele Jahre zusammenarbeitet und mindestens in der Selbstwahrnehmung dabei auch recht erfolgreich war, ein agiles Team.
Meiner Beobachtung nach spielt es dabei gar keine so große Rolle, ob das Team aus einer klassischen Methode kommt, oder bereits denkt, es würde schon agil sein, weil es schon nach Scrum arbeitet. Letzteres muss ich kurz erklären.
Viele Teams haben bereits versucht, eine agile Methode – meist Scrum, manchmal Kanban, gelegentlich sogar Scrumfall (nicht Skyfall) – zu implementieren, waren dabei nicht sehr erfolgreich und sollen das agile Handwerkszeug noch mal richtig lernen. Viele Organisationen und noch mehr Agile Coaches kennen das Problem.
Wie bringt man solchen Teams ein agiles Mindset bei?
Genau darum wird es in diesem Artikel gehen, d.h. ich werde hier versuchen meine ca. 15 Jahre Erfahrung mit diesem Thema zusammenzufassen und einen Vorschlag zur Diskussion stellen.
Agile Transformationen – der Unterschied zu klassischen Methoden
Agile Transformationen fühlen sich ja immer ein bisschen wie eine Therapie an, zumindest werden sie von Agile Coaches oft so veranstaltet und nicht immer geht es dem Patienten nach der Therapie besser.
Einige Patienten sind während solcher Therapien leider auch schon verstorben, Projekte sind gescheitert, Organisationen haben Notbremsen gezogen und gelegentlich sind sie wieder zurück in die klassische Methodik gewechselt.
Was macht agile Transformationen denn so schwer, bzw. warum machen es Agile Coaches oft so schwer? Zunächst versuche ich darauf eine kurze Antwort zu geben.
Klassische Methoden haben vor allem Rollen, Prozesse, Architekturen und Artefakte im Fokus. Pflichtenhefte, Lastenhefte, Schätzungen, Reportings, Lieferketten, Organigramme, Zuständigkeiten, Steuerung, Projektcontrolling, Quality Gates, usw., bis zur Denkmalenthüllung ist alles gut organisiert.
Der Ausgangspunkt agiler Projekte ist oft die Abwesenheit solcher Strukturen, Artefakte und Prozesse und die Erkenntnis, dass sowohl die Zeit nicht genügen wird, diese zu erstellen (time-to-market) als auch die Komplexität des Gegenstandes einen solchen Planungs- und Organisationsprozess fast unmöglich macht.
Was dann noch bleibt, sind die Akteure, auf die man sich jetzt verlassen muss. Agile Methodik fokussiert sich also wesentlich stärker auf den Menschen, versucht also die Akteure in die Lage zu versetzen, das zu tun, was jetzt notwendig ist. Menschen zu ändern ist weitaus komplexer, als Prozesse zu ändern.
Der richtige Ansatz für die agile Transformation der Teams
Hinzu kommt, dass Agile Coaches diesen Zusammenhang leider oft zu wörtlich nehmen und damit ein Spiel eröffnen, dass sie eigentlich gar nicht gewinnen können.
Agile Coaches verfolgen dabei einen – ich nenne es mal – psychoanalytischen Ansatz, setzen auf die intrinsische Motivation von Teams und auf deren Fähigkeit zur Selbstorganisation. Motivation und Selbstorganisation sind zweifellos sehr hohe Werte und erstrebenswerte Güter in der agilen Methodik.
Jedoch wird oft übersehen, dass beides gelernt werden muss und auch gelernt werden kann, aber eben nicht vorausgesetzt werden kann und vielleicht auch gar nicht vorausgesetzt werden muss. Letzteres ist ganz entscheidend für meinen Ansatz.
Ganz konkret: Wie mache ich aus einem Team ein gut funktionierendes Team, dass zu Beginn keinerlei Motivation verspürt, sich fundamental zu ändern?
Um das zu erreichen, nutze ich einen anderen Ansatz, einen eher verhaltenstherapeutischen Ansatz. Auch wenn beide Begriffe aus der Psychologie stammen, dienen sie hier natürlich nur als Metapher um zwei Transformationsstrategien besser zu unterscheiden.
Daher nenne ich den psychoanalytischen Ansatz im Folgenden den P-Ansatz, während ich den verhaltenstherapeutischen Ansatz den V-Ansatz nenne. Doch erlauben Sie mir an dieser Stelle noch je einen kurzen Satz für beide Ansätze zur besseren Orientierung.
Die Psychoanalyse soll durch Gespräche und freies Assoziieren Konflikte ans Licht bringen. Der Mensch soll also selbst erkennen, was schief läuft und daraus eine neue oder adaptierte Handlungsstrategie entwickeln.
Das kommt im positivsten Sinn dem Coaching Gedanken ja sehr nah und wird von Agile Coaches daher auch bevorzugt. Unterschätzt werden dabei oft zwei Punkte.
Erstens braucht das oft sehr viel Zeit und zweitens setzt es eben eine intrinsische Motivation der Teams voraus, sich auf dieses Spiel einzulassen. Organisationen haben diese Motivation oft, Teams oft allerdings nicht. Das, was auf Organisationsebene also oft noch ganz gut funktioniert, scheitert dann ebenso oft auf Team-Ebene.
Agile Teams vorbereiten
Auf Team Ebene brauchen wir daher in solchen Situationen einen anderen Ansatz, eben einen eher verhaltenstherapeutischen Ansatz. Der Kerngedanke der Verhaltenstherapie ist, dass (problematisches) Verhalten erlernt wurde und auch wieder „verlernt“ werden kann, bzw. neue, angemessenere Verhaltensmuster erlernt werden können.
Etwas vereinfacht ausgedrückt genügen dem Agile Coach als Voraussetzung hier, dass die Teammitglieder freiwillig morgens zur Arbeit erscheinen und Anweisungen ihnen zugewiesener Autoritäten entgegennehmen.
Hohe Motivationen, Neugier, Kreativität, Lernbereitschaft, Kritikfähigkeit, etc. sind allesamt von großem Vorteil und sehr hilfreich, werden aber nicht notwendig vorausgesetzt, anders ausgedrückt, wir müssen auch klarkommen, wenn diese Eigenschaften nicht so ausgeprägt sind, wie wir uns das wünschen würden.
In der Praxis sieht das dann so aus, dass die Methodik quasi per Dienstanweisung vorgegeben wird, und nicht wie im P-Ansatz mit den Teams erarbeitet wird. Das klingt natürlich erstmal hart und auch im Widerspruch zu den agilen Idealen stehend. Und zum Teil ist es das vermutlich sogar auch.
Man kann es aber auch als eine Abkürzung sehen, die am Ende nicht weniger nachhaltig ist, als der P-Ansatz.
Kurz gesagt gehen wir im V-Ansatz davon aus, dass wenn das Verhalten erstmal gelernt ist und Erfolge zu verzeichnen sind, wird sich die Einsicht und die Motivation schon einstellen.
Teams sollen recht zügig lernen, dass die agile Methode ihnen bei Bewältigen ihrer Aufgaben hilft, statt dass sie das Gefühl haben, dass sie viel investieren müssen, damit die Methode funktioniert. Dazu braucht es als Voraussetzung nicht die Einsicht, dass es so ist, sondern lediglich ein gewisses Maß an Bereitschaft, ihr zu folgen.
Agiles Mindset entwickeln
Natürlich kann agile Kultur und agiles Mindset nicht verordnet werden, wie die Kritiker jetzt leicht einwerfen würden.
Das ist auch nicht der V-Ansatz. Dieser sagt, es kann gelernt werden. In der Praxis heißt dies, dass – nennen wir ihn mal „Chief Scrum Master“ oder wie SAFe sagen würde Solution-, oder Release Train Engineer – die methodischen Artefakte vorgibt, Team-Setup, Sprintlänge, Definition of Ready, Definition of Done, Meetings und deren Frequenz, Templates für Storys und Epics, die Schätzverfahren und den Umgang mit Story-Points, Einsatz von Tools, all die Dinge, die im P-Ansatz in der Verantwortung der Teams verortet werden, sind im V-Ansatz vorgegeben.
Positiv ausgedrückt gibt das den Teams zunächst mal eine ganze Menge Orientierung. Denn im Hintergrund steht bei den Teams ja immer noch ein inhaltlicher Auftrag, nämlich ein Produkt zu entwickeln.
Der Auftrag lautet eigentlich nicht, sich eine Methode zu entwerfen. Und auch die traditionell agile Forderung der Selbstorganisation der Teams – und ich denke, das ist ein Missverständnis, dem viele agile Coaches unterliegen – sollte nicht verstanden werden als den Ruf
„sucht Euch Eure Methode selbst aus, bzw. customized sie Euch so zurecht, bis sie Euch gefällt“, sondern meint eher „Nutzt die Methode so, dass ihr Eure Probleme in der Produktentwicklung so weit wie möglich selbst lösen könnt“
Agile Methoden werden irrtümlich immer als sehr flexibel beschrieben, aber auch das ist auf ein sprachliches Missverständnis zurückzuführen. Die Methode selbst ist keines Falls sehr flexibel, im Gegenteil, sie ist sehr stringent und erfordert ein Höchstmaß an Disziplin. Richtig angewendet ermöglicht sie einer Organisation aber ein sehr hohes Maß an Flexibilität.
Im V-Ansatz müssen wir in der Tat nicht auf die Befindlichkeit jedes Einzelnen Rücksicht nehmen. Es bedeutet aber nicht, dass die Befindlichkeiten jedes einzelnen nicht berücksichtigt werden.
Jeder, der schon mal in einer Schule oder einem Krankenhaus gearbeitet hat, weiß sofort, was hier gemeint ist.
Es ist keine Zurücksetzung des Einzelnen, sondern wir wissen einfach, dass Teams, die vor einer solchen Herausforderung stehen, eine neue Methode einzusetzen und gleichzeitig irre-komplexe Produkte zu entwickeln, am meisten Orientierung und einen klaren Auftrag brauchen.
Die Methode, hilft Ihnen, sich zu fokussieren, zu priorisieren, sich weiterzuentwickeln. Das zu Erkennen ist ein Lernprozess. Lernen tut man hier am schnellsten durch Tun, nicht durch Reflexion.
Herausforderungen für agile Transformationen richtig angehen
In meiner Praxis habe ich häufiger beobachtet, dass Agile Transformationen eher daran scheitern, dass Teams diese klare Orientierung fehlt: best Practices, die ihnen Hinweise darauf geben, wie sie sich in schwierigen Situationen verhalten sollen.
Was tun, wenn wir zu viele Scope-Changes haben, wenn wir nie schaffen, was wir uns vornehmen, wenn wir zu viele Abhängigkeiten zu unseren Task sehen, wenn die Meetings immer mehr werden und zu lange dauern und wir keine Zeit zum Arbeiten haben, wenn uns die Ansprechpartner fehlen, wenn unsere Hinweise aus Retros überhört werden, wenn die Tools nicht so sind, wie wir sie einsetzen wollten, wenn wir mit einzelnen Teammitglieder ständig Konflikte haben, etc.
Erst wenn all diese Fragen einigermaßen zufriedenstellen beantwortet werden, kann sich eine Kultur mit einem entsprechenden Mindset entwickeln. Das geht eben nur in dieser Reihenfolge, nicht umgekehrt.
Wir dürfen allerdings auch nicht verschweigen, dass auch der V-Ansatz mit einigen Herausforderungen zu kämpfen hat. Wenn die agile Methode vorgegeben und etabliert ist, also funktioniert, dann kommt es bei vielen Akteuren schnell zu einer gewissen bequemen Zufriedenheit.
Wie gesagt, das Funktionieren der Teams in der Methode ist wichtig und schön, aber es muss noch der zweite Schritt erfolgen. Der zweite Schritt besteht eben darin, dass die Akteure in den Teams den Schwenk von „aktiv“ zu „proaktiv“ bekommen. Soweit reicht die Methode eben nicht.
Und auch der V-Ansatz hat diese Reichweite nicht zwingend. Es bleibt also noch etwas Arbeit übrig, aber diese Arbeit fällt auf Basis einer gut funktionierenden Methode leichter als auf keiner Basis.
Motivation und Proaktivismus, als Stützfeiler einer agilen Kultur können grundsätzlich auch gelernt werden, sogar die Freude an etwas kann gelernt werden.
Auch wenn diese Gedanken heute gesellschaftlich nicht besonders populär sind, weil sie über uns und unseren hochindividuellen Emotionen den Schatten einer gewissen Fremdbestimmtheit und Manipulierbarkeit werfen. Aber das führt viel zu weit.
Wir sehen, dass P-Ansätze und V-Ansätze in einer agilen Transformation wichtige Rollen spielen können. Auf Management- und Organisationsebene brauchen wir eher P-Ansätze, damit – und das ist z.B. eine zentrale Forderung von SAFe – das Management die Transformation selbst mit in Gang setzt.
Hier haben wir in der Regel nur wenige Akteure, dafür mit hoher Verantwortung für den Transformationsprozess. In den Teams sieht das ganz anders aus. Die Teams sind der Kern der Wertschöpfung und damit tragen sie eine enorme Verantwortung für diese.
Aber ihre Verantwortung im Transformationsprozess ist – auf den Einzelnen heruntergerechnet – weniger groß. Um gleichermaßen den Wertschöpfungsprozess nicht zu gefährden und agile Methoden schnell zum Laufen zu bringen, ist auf Team Ebene der V-Ansatz vielversprechender.
