Wie kann Agilität für ein Team in einer großen Organisation beginnen? Hier ist ein Erfahrungsbericht.
Die ersten Ansätze für agiles Arbeiten in großen Organisationen basieren häufig auf konkreten Methoden. Man hat vielleicht viel Gutes von agilen Methoden gehört und versucht daher, mit Hilfe einer der am häufigsten angewandten Methoden wie Scrum oder Kanban, agil zu werden. Es geht also zu dem Zeitpunkt meist um den Nutzen eines agilen Arbeitsablaufs und eher noch nicht um Fragen zur agilen Haltung bzw. Kultur.
Ich habe diesen Schritt in einer deutschen Großbank in einem Testteam eine Zeit lang begleitet. Mein Auftrag lautete, ein Testteam „agil zu machen“. Denn sowohl das Testteam als auch das übergeordnete Projektteam waren unerfahren mit agilen Methoden, sollten aber agil arbeiten. Darüber hinaus war die Organisation dominiert von stark klassischen Prozessabläufen – sowie sie in der Bankenwelt aus guten Gründen etabliert waren.
Das Großprojekt war positiv gegenüber agilem Vorgehen eingestellt und wollte in kurzen Zyklen neue Produktinnovationen schaffen. Eine gute Grundlage also für ein agiles Testteam.
Das Team hatte eine Größe von etwa 10 Personen und war unabhängig im Projekt organisiert. Es gab also in dem Gesamtprojekt ein Business-Team, mehrere Entwicklungsteams und ein Testteam. Ein erfahrener ‚Agilist‘ könnte also schon dadurch vermuten, dass das ganze Projektteam noch einen frühen agilen Reifegrad hatte und dort erst einmal abgeholt werden musste.
Zum Glück war das Team fachlich erfahren und kompetent. Das war eine gute Grundlage, um sich nicht auch noch mit fachlichen Themen beschäftigen zu müssen. Und so begannen wir, uns mit den Grundlagen der Teamorganisation zu beschäftigen.
Selbstorganisation im Team
Die Personen im Team waren hierarchische Projektstrukturen gewohnt und hatte in Vorprojekten vor allem Erfahrung mit autoritären Projektmanagern gemacht. Da war es schon herausfordernd, gemeinsam erste Schritte von Selbstorganisation zu erleben:
Wir mussten den Rahmen finden, in dem sich das Team frei und selbständig bewegen konnte und sollte.
Gleichzeitig hatten wir die Abgrenzung zu anderen Teams klar darzustellen, abzustimmen und einzufordern.
Hier war vor allem ich als temporärer Projektleiter und Coach gefordert und musste Abläufe mit anderen Teams etablieren, die einen Start in möglichst selbstständige Teamarbeit erlaubten.
Systematisches Vorgehen in kurzen Zyklen
Vom ersten Tag an, gingen wir in kurzen Zyklen vor. Das war für das Team keine wirkliche Umstellung, denn sie waren es gewohnt, in Software-Release-Zyklen zu denken. Daher fanden die Leute das intuitiv und logisch. Wir verkürzten nur die Arbeitszyklen weiter Schritt für Schritt. So war iteratives Vorgehen ohne eine gefühlt merkbare Veränderung etablierte Praxis.
Priorisieren der Arbeit nach Nutzen für den Kunden
Priorisieren der Arbeit war ebenfalls kein neues Thema. Das Team hatte erwartet, dass der Projektmanager priorisiert, und damit war die Sache für das Team klar: Es gibt eine vorgegebene Priorisierung. Vorerst einmal gleich von wem!
Dadurch war es also meine Aufgabe, den Prozess der externen Priorisierung durch den firmeninternen Kunden sicher zu stellen. Ich übernahm damit vorerst diese Rolle zum Kunden.
Ziele setzen und sichtbar machen
Wir legten viel Wert darauf, für das Team in den Iterationen erreichbare Ziele zu setzen und diese intern und extern sichtbar zu machen. Das erleichterte stark die Kommunikation mit anderen Teams. Es gab damit klare Erwartungshaltungen in alle Richtungen. Wir waren da auch sehr transparent – es wurde sichtbar kommuniziert, was möglich und nicht möglich war. Nichts wurde „versteckt“.
Fokus auf die nächste Etappe
Mit dem zyklischen Vorgehen und der Zielklarheit war es gleichzeitig auch selbstverständlich, dass wir uns jeweils mit dem Inhalt der nächsten Iteration am meisten beschäftigen würden.
Kontinuierliches Verbessern
Eine kontinuierliche Verbesserung durch ständige Reflexion der eigenen Arbeitsweise war schwieriger. Einmal besprochene Vorgehensweisen wurden als „fixiert“ betrachtet, Veränderungen dazu als Zeitverschwendung angesehen. Nicht nur von Teammitgliedern – auch von Personen außerhalb des Teams.
Die Umsetzung davon gelang mir in der gegebenen Zeit fast gar nicht. Hier war die Bereitschaft nicht vorhanden, weil die Einstellung („das Mindset“) dafür noch nicht da war. Ich konnte scheinbar den Nutzen davon für die Teammitglieder nicht ausreichend nachvollziehbar vermitteln. Das Thema mussten wir zu dem Zeitpunkt leider verschieben und haben damit nur offensichtliche Verbesserungen aufgegriffen.
Kunde im Fokus
Wie schon eingangs beschrieben, waren wir in der Teamstruktur zu Beginn noch als eigenes Fachteam organisiert. Das bedeutete, dass wir zwar viel Kundenkontakt zum Testauftrag hatten, dieser jedoch prozesstechnisch der Businessanalyse und der Entwicklung nachgeordnet war. Wir waren kein multifunktionales agiles Team, wie man sich das gewünscht hätte. Soweit war die Organisation insgesamt noch nicht.
Ein frühzeitiges Einbinden und damit aktives Arbeiten mit dem Businesskunden konnten wir zwar etablieren, war aber insgesamt ein langsamer Entstehungsprozess.
Wenn man diese ersten Schritte einer agilen Arbeitsweise mit einer Methode benennen möchte, dann war das am Ehesten ein „Kanban“-Ansatz, den wir verfolgt hatten. Denn wir hatten unter anderem viel Wert auf folgende Prinzipien gelegt und einige Praktiken davon genutzt:
Nach den ersten Wochen der Verwunderung über die Vorgehensweisen hatten sich viele im Team an die neuen Abläufe und Denkweisen gewöhnt. Es wurde nicht mehr so sehr darüber diskutiert, ob das richtig oder falsch war. Vielmehr konnte man beobachten, dass darüber geredet wurde, wie man diese Arbeitsweise nutzen konnte und was daran noch zu verbessern wäre.
Damit war ein agiles Team geschaffen – zugegeben, in früher Entwicklungsreife. Aber der Start war gelegt und es konnte vom Team und meinem geplanten Nachfolger auch ohne mich weiterverwendet werden.
Vor einiger Zeit bekam ich folgende Nachricht von einem damaligen Teammitglied: „… ja ich erinnere mich gern mal an die Zeiten zurück und deinen Vorstoß mit dem Daily … auch wenn‘s Anfangs nervig war, war es doch konstruktiv. Hab‘ das beim neuen Arbeitgeber und neuen Projekt so etablieren können, nach deinem Vorbild ???? …“Previous article: Agile Transformation – wie geht das PrevNext article: Agil machen oder agil seinNext