Wenn der Agile Coach nur ein Team hat um dessen Wohl er sich kümmern soll, dann hat er Glück. Es gibt einen klaren Fokus, man kann sich kümmern, man kann für „sein Team“ sorgen und es gedeihen lassen. Eigentlich das perfekte Setup, mit dem man den größten Benefit realisieren kann.
In der Praxis sind die Vorteile so einer Struktur offensichtlich: Der Prozess kann selbst gestaltet werden; die Meetings, Artefakte und Methoden richten sich nach dem, was im eigenen Team gerade am meisten Sinn ergibt. Man hat die Zeit für Teambuilding, man kann sich um die Individuen kümmern und Konflikte schlichten. Das Team kann sich entfalten.
Wenn der Fokus zum Problem wird
Aber dieser Fokus bringt auch eine Schwäche mit sich. Denn besteht der Grossteil der eigenen Welt des Agile Coach aus dem Team, so neigt man dazu, auch nur diese Welt wahrzunehmen. Und weil man auch eine soziale Funktion wahrnimmt, bildet man Gemeinsinn und identifiziert sich mit dem eigenen Team.
Mit der Zeit bringt dieses Zusammenspiel von Identifikation, Gemeinsamkeit und Fokus auf das eigene Team die Stammeseffekte an die Oberfläche, die uns Menschen nicht nur zu sozialen Tieren gemacht haben, sondern auch spätestens seit der Steinzeit unsere Geschicke leiten: Wir stellen unsere Gruppe in den Vordergrund und die anderen Gruppen sinken von unserer Sicht aus in der Bedeutung. Außerdem verliert die Aussenwelt an Bedeutung.
[smartblock id=“7056″]Agile Coach Tribalism
Auf einmal stehen die eigenen Ziele im Vordergrund und nicht mehr die der Organisation, deren Interessen das eigene Team überhaupt die Existenz verdankt. Es stellt sich nicht mehr die Frage „Wie tragen wir am wertvollsten zum Erfolg der Organisation, des Kunden, des Nutzers bei?“, sondern Fragestellungen wie „Wie bringen wir unser Team voran?“ oder „Wie werden wir den Individuen in unserem Team besser gerecht?“ rücken stattdessen als Leitidee in den Vordergrund.
Diese Ziele stehen dann in Konkurrenz zu den Zielen der Aussenwelt und der Scrum Master wird zum Stakeholder. Seine Aufgabe ist nicht mehr, Teams dabei zu helfen, Produkte zu erschaffen, Kundenprobleme zu lösen und mitzuhelfen, die Ziele der Organisation zu erreichen. Er ist jetzt der Interessenvertreter seines Teams, sieht sein Hauptaugenmerk darin, die persönlichen und gemeinsamen Bedürfnisse der Teammitglieder zu erfüllen und sie vor den Dingen zu schützen, die diesen Interessen entgegenlaufen. Selbst wenn das die Interessen der Kunden und der Organisation sind oder wenn es sich um legitime Interessen anderen Teams handelt, die auf diese Ziele einzahlen wollen.
Auf diese Weise wird aus der Rolle, deren Aufgabe es eigentlich war, als stützende Funktion die Organisation im Sinne der Kunden besser zu machen und weiterzuentwickeln, das Gegenteil. Die stützende Funktion wurde zur Interessenvertretung von Partikularinteressen und statt einer Verbesserung des Gesamtsystems rutscht der Fokus in lokale Optimierung.
Agile Missverständnisse
Agile Methoden haben eine klare Intention: Sie wollen die Wertschöpfung bei der Entstehung von Software steigern. Sie bieten zu diesem Zweck gleich einen ganzen Stapel von Werten, Prinzipien und Methoden an, die dabei unterstützen.
In der Praxis sind die Intentionen hinter diesen Werkzeugen oft nicht mehr so klar, und manchmal gehen sie ganz verloren; die Methode bleibt, mit ihren Umständlichkeiten und Haken, nur ohne den erwünschten Effekt. Über diese Art von agilen Missverständnissen will ich hier berichten – und darüber, wie man mit ihnen umgeht. Dafür habe ich diese Beiträge geschrieben:
Schreibe einen Kommentar