Das Prinzip der Selbstorganisation und Eigenverantwortung liest sich zwar recht schön, aber in der Praxis gibt es doch vermutlich in jedem Team auch Kollegen, denen Selbstorganisation einfach nicht liegt. Vielleicht stellt sich das Problem nicht, wenn alle Teammitglieder bereits bei der Einstellung nach ihrer Selbstorganisationskompetenz "abgeklopft" werden, aber bei Transformationen müssen ja auch diejenigen Mitarbeiter in die neuen agilen Teams integriert werden, die Jahre oder Jahrzehnte mit "command & control" gearbeitet haben. Wir haben die Erfahrung gemacht, dass es durchaus Mitarbeiter gibt, die es ganz gerne mögen, wenn sie NICHT so viel selbst entscheiden müssen! Das sind fachlich gute Mitarbeiter, die sich über lange Zeit im Unternehmen verdient gemacht haben, die sich aber mit dem geforderten agilen Mindset schwer tun. Wir wollen diese Mitarbeiter ja behalten, haben aber das Gefühl, dass die Stimmung im Team schlechter ist als zuvor - die agileren Kollegen sind unzufrieden, weil das Team nicht agil genug ist. Die weniger agilen Kollegen sind unglücklich, weil etwas von ihnen erwartet wird, was ihnen schwer fällt. Wie geht man damit um? Schafft man es mit dem richtigen Ansatz und Konsequenz wirklich, jeden Mitarbeiter von Selbstorganisation und Eigenverantwortung zu überzeugen? Oder muss man einfach damit leben (und auch bei anderen Teamkollegen akzeptieren), dass nicht jeder in gleichem Maße eine agile DNA in sich trägt?
1 Antwort
Hallo Bettina,
Du hast es bereits schön geschrieben: Selbstorganisation = die Fähigkeit, dass sich ein Team selbst führen und organisieren kann. Insbesondere die Führungsqualitäten - also Entscheidungen zu treffen - wurden vielen Mitarbeitern, die lange Command&Control erlebt haben, über die Zeit abgewöhnt. Entweder, indem man gerügt wurde, dass man eine Entscheidung getroffen hatte, man aber nicht die Entscheidungsgewalt innehatte. Oder dass man eine Entscheidung getroffen hatte, die sich später als Irrtum herausgestellt hatte und dafür gerügt wurde, dass man keinen Erfolg hatte. Die Folge: "Dienst nach Vorschrift". Der Hund, der ständig getreten wird, duckt sich eben einfach nur noch.
Wenn man diesen Mitarbeitern agile Methoden und Prinzipien anbietet und diese durch einen guten Manager begleitet, erlebte ich oft, dass dies für diese Mitarbeiter wie ein 'Befreiungsschlag' wirkt. Endlich kann und darf man wieder arbeiten, wie man es für sinnvoll erachtet. Unter gutem Management verstehe ich in diesem Zusammenhang, dass der Manager eine klare Erwartungshaltung hat, diese zu kommunizieren vermag und seinen Mitarbeitern die nötige Verantwortung zukommen lässt. Damit diese die Verantwortung auch annehmen können, bedarf eines solchen Führungsverhaltens: 'Wenn das Team Erfolge erzielt, gebühren alle Erfolg dem Team. Wenn das Team entscheidet, aber sich die Entscheidung als irrtümlich herausstellt, hält der Manager den Kopf hin.' Nicht jede Führungskraft kann das. Aber im Rahmen der sogenannten 'psychological safety' für die Mitarbeiter ist das unbedingt erforderlich.
Leider ermöglichten die Command&Control Strukturen aber auch eine andere Mitarbeiter-Entwicklung. Nämlich die des Helden, des 'brilliant jerks'. Diejenigen Mitarbeiter, die sich (zurecht verdient) einen Namen gemacht haben durch ihren Einsatz und ihr Können. Unter Command&Control wurde diesen Mitarbeitern gerne erweiterte Entscheidungskompetenz zugesprochen. Dies drückt sich dann aus in Titeln wie 'Lead architect', 'Lead senior developer'. Für diese Mitarbeiter stellen die agilen Prinzipien eine Gefahr des eigenen Status Quo dar. Man ist nicht mehr per Dekret 'Lead of...', sondern von nun an ist man darauf angewiesen, dass man eine 'freiwillige Gefolgschaft' hat. In der agilen Welt führt der, der in der jeweiligen Situation von den anderen als der beste Könner identifiziert und damit als Leader legitimiert wird. Damit kommt nicht jeder zurecht, der aus der alten Welt kommt. Den Wandel von einem 'Ansager, so machen wir das, weil ICH als Lead das so sage' hin zu einem 'Supporter, Coach, Servant leader, also echtes Führen und Zusammenarbeit' ist für Manche einfach zu groß.
Was also tun?:
1. Klare Erwartungshaltung seitens des Managements ausdrücken, wie zukünftig gearbeitet werden soll (z.B. natürliche Führung, keine 'Lead...' Titel mehr).
2. Im Zweifel ist es notwendig, einen 'brilliant jerk' gehen zu lassen. Das hört sich oft schrecklichen an, als es ist. Z.B. 'ohje, wenn Herr/Frau... geht, bricht hier alles zusammen'. Ganz ehrlich, in allen Fällen wo ich das bisher erlebt habe, ist nachdem dieser Held gegangen ist, Folgendes passiert: Nichts! Ganz im Gegenteil, endlich sind Teams nicht mehr durch das Verhalten des Helden in ihrer Teamentwicklung gehindert. Es stellt sich schnell eine Teamperformance ein, die die des Helden weit übertrifft.
3. Weitere Einflussmöglichkeiten nutzen: Gerade in Scrum ist der Product Owner eine oft unterschätzte Rolle, wenn es darum geht, wie ein Team performed. Je klarer und besser ein Product Owner ein vom Kunden her motiviertes Sprint-Ziel benennen kann, desto mehr stellen Menschen ihre eigenen Interessen zugunsten des Team-Zieles freiwillig hintenan. Aus meiner Erfahrung ist diese wichtige Wirkung auf ein Team nur wenigen Product Ownern so bewusst. Sie verstehen sich oft eher als Backlog-Verwalter und Sprint-Ziele sind eine Liste von Dingen, die halt gemacht werden müssen, aber in Summe kein motivierendes Sprint-Ziel darstellen.
Ich rate meinen Product Ownern zu Beginn des Sprint-Plannings klar herauszustellen, was nach dem nächsten Sprint anders sein wird. Welches Kundenproblem wird dann gelöst sein? Welche Deadline wird gehalten worden sein? Wen wird das Team glücklich gemacht haben? Das sind motivierende Ziele. Während des Sprints kann der Scrum Master (und aus meiner Sicht auch sehr gerne der PO) im Daily Standup immer wieder fokussieren und nachhalten, was heute noch gemacht werden muss, um diese Ziele zu erreichen. Und ein mancher 'brilliant jerk' lässt sich dann plötzlich gerne darauf ein, sein Team nicht im Stich zu lassen, sein Wissen zu teilen, andere auch machen zu lassen usw. Denn er weiß ganz genau, dass er es alleine nicht schaffen kann.
Ich hoffe, diese Gedanken helfen Dir. Viel Erfolg!
der Markus
Du hast es bereits schön geschrieben: Selbstorganisation = die Fähigkeit, dass sich ein Team selbst führen und organisieren kann. Insbesondere die Führungsqualitäten - also Entscheidungen zu treffen - wurden vielen Mitarbeitern, die lange Command&Control erlebt haben, über die Zeit abgewöhnt. Entweder, indem man gerügt wurde, dass man eine Entscheidung getroffen hatte, man aber nicht die Entscheidungsgewalt innehatte. Oder dass man eine Entscheidung getroffen hatte, die sich später als Irrtum herausgestellt hatte und dafür gerügt wurde, dass man keinen Erfolg hatte. Die Folge: "Dienst nach Vorschrift". Der Hund, der ständig getreten wird, duckt sich eben einfach nur noch.
Wenn man diesen Mitarbeitern agile Methoden und Prinzipien anbietet und diese durch einen guten Manager begleitet, erlebte ich oft, dass dies für diese Mitarbeiter wie ein 'Befreiungsschlag' wirkt. Endlich kann und darf man wieder arbeiten, wie man es für sinnvoll erachtet. Unter gutem Management verstehe ich in diesem Zusammenhang, dass der Manager eine klare Erwartungshaltung hat, diese zu kommunizieren vermag und seinen Mitarbeitern die nötige Verantwortung zukommen lässt. Damit diese die Verantwortung auch annehmen können, bedarf eines solchen Führungsverhaltens: 'Wenn das Team Erfolge erzielt, gebühren alle Erfolg dem Team. Wenn das Team entscheidet, aber sich die Entscheidung als irrtümlich herausstellt, hält der Manager den Kopf hin.' Nicht jede Führungskraft kann das. Aber im Rahmen der sogenannten 'psychological safety' für die Mitarbeiter ist das unbedingt erforderlich.
Leider ermöglichten die Command&Control Strukturen aber auch eine andere Mitarbeiter-Entwicklung. Nämlich die des Helden, des 'brilliant jerks'. Diejenigen Mitarbeiter, die sich (zurecht verdient) einen Namen gemacht haben durch ihren Einsatz und ihr Können. Unter Command&Control wurde diesen Mitarbeitern gerne erweiterte Entscheidungskompetenz zugesprochen. Dies drückt sich dann aus in Titeln wie 'Lead architect', 'Lead senior developer'. Für diese Mitarbeiter stellen die agilen Prinzipien eine Gefahr des eigenen Status Quo dar. Man ist nicht mehr per Dekret 'Lead of...', sondern von nun an ist man darauf angewiesen, dass man eine 'freiwillige Gefolgschaft' hat. In der agilen Welt führt der, der in der jeweiligen Situation von den anderen als der beste Könner identifiziert und damit als Leader legitimiert wird. Damit kommt nicht jeder zurecht, der aus der alten Welt kommt. Den Wandel von einem 'Ansager, so machen wir das, weil ICH als Lead das so sage' hin zu einem 'Supporter, Coach, Servant leader, also echtes Führen und Zusammenarbeit' ist für Manche einfach zu groß.
Was also tun?:
1. Klare Erwartungshaltung seitens des Managements ausdrücken, wie zukünftig gearbeitet werden soll (z.B. natürliche Führung, keine 'Lead...' Titel mehr).
2. Im Zweifel ist es notwendig, einen 'brilliant jerk' gehen zu lassen. Das hört sich oft schrecklichen an, als es ist. Z.B. 'ohje, wenn Herr/Frau... geht, bricht hier alles zusammen'. Ganz ehrlich, in allen Fällen wo ich das bisher erlebt habe, ist nachdem dieser Held gegangen ist, Folgendes passiert: Nichts! Ganz im Gegenteil, endlich sind Teams nicht mehr durch das Verhalten des Helden in ihrer Teamentwicklung gehindert. Es stellt sich schnell eine Teamperformance ein, die die des Helden weit übertrifft.
3. Weitere Einflussmöglichkeiten nutzen: Gerade in Scrum ist der Product Owner eine oft unterschätzte Rolle, wenn es darum geht, wie ein Team performed. Je klarer und besser ein Product Owner ein vom Kunden her motiviertes Sprint-Ziel benennen kann, desto mehr stellen Menschen ihre eigenen Interessen zugunsten des Team-Zieles freiwillig hintenan. Aus meiner Erfahrung ist diese wichtige Wirkung auf ein Team nur wenigen Product Ownern so bewusst. Sie verstehen sich oft eher als Backlog-Verwalter und Sprint-Ziele sind eine Liste von Dingen, die halt gemacht werden müssen, aber in Summe kein motivierendes Sprint-Ziel darstellen.
Ich rate meinen Product Ownern zu Beginn des Sprint-Plannings klar herauszustellen, was nach dem nächsten Sprint anders sein wird. Welches Kundenproblem wird dann gelöst sein? Welche Deadline wird gehalten worden sein? Wen wird das Team glücklich gemacht haben? Das sind motivierende Ziele. Während des Sprints kann der Scrum Master (und aus meiner Sicht auch sehr gerne der PO) im Daily Standup immer wieder fokussieren und nachhalten, was heute noch gemacht werden muss, um diese Ziele zu erreichen. Und ein mancher 'brilliant jerk' lässt sich dann plötzlich gerne darauf ein, sein Team nicht im Stich zu lassen, sein Wissen zu teilen, andere auch machen zu lassen usw. Denn er weiß ganz genau, dass er es alleine nicht schaffen kann.
Ich hoffe, diese Gedanken helfen Dir. Viel Erfolg!
der Markus