„Ich will, dass meine Teams agil arbeiten!”, „Ich möchte, dass wir nach Scrum entwickeln!”, „Meine Mitarbeiter sollen selbstorganisiert sein und bessere Qualität liefern!”, „Ich brauche dringend ein Product Owner Training.” Diese Zitate alias Kundenwünsche sind en vogue und erreichen TEAMWILLE täglich. Unternehmen drängen auf Veränderung - agile Veränderung. Es geht dabei (endlich) nicht mehr um die Frage nach dem „Ob überhaupt”, sondern nach dem „Wie und Wann” eine Veränderung ihren Anfang finden kann. Scrum, bis gestern noch vielerorts verkannt als Mysterium, weit unterschätzt als Modewort oder gefürchtet als Büchse der Change-Pandora, mausert sich stetig zu einer Art Heilsbringer und Türöffner für einen nachhaltigen Wandel im Denken und Handeln, der Kräfte freisetzt, jahrzehntelange (Methoden- und Führungs-)Kulturen ins Wanken zu bringen. Diese außergewöhnliche, wenn auch für Insider weniger überraschende Entwicklung, ist Glücksfall und Gefahr zugleich. Dort, wo Werte wie Transparenz, Offenheit und Selbstbestimmung im Sinne von Wertschöpfung durch Wertschätzung tatsächlich den nötigen Raum bekommen, mit Hilfe professioneller Begleitung (z. B. Agile Coaching) nachhaltig gelebt zu werden, mündet das agile Anderssein in positiven Effekten wie Produktivitätssteigerung, Innovation und Mitarbeiterzufriedenheit, was wiederum positive Auswirkungen auf die Kunden zu haben scheint.
Gefährlich wird es überall dort, wo Scrum als Lösungsweg verstanden wird, der wie das simple Betätigen eines Lichtschalters den Raum erhellen soll und die bloße Implementierung auf Prozessebene bereits den Schlussakt „done” einläutet. Gefährlich, weil Scrum keine Blaupause für Veränderungen ist, sondern erstmal „nur” Vorbote für Symptome in Gestalt von Ressourcen und Potentialen ist und auf diese Weise (noch) keine Lösungen generiert! Scrum ist ein iterativer Prozess, der auf empirischen Daten, also Erfahrung, inkrementell aufbaut. Scrum ist und bleibt außerdem Managementframework. Damit definiert es zwar Inhalte und schafft mit ihnen Klarheit, die Freiheitsgrade in seiner Interpretation sind jedoch hoch. Folglich ist Scrum bei Team A, nicht wie Scrum bei Team B, was wiederum zur Konsequenz hat, dass bereits in der Vermittlung, aber spätestens in der Umsetzung eine Art Pippi-Langstrumpf-Denken Einzug hält: Ich mach mir Scrum, wie es mir gefällt oder anders ausgedrückt: Warum soll ich mich ändern, wenn ich Scrum habe?
Wenn ich das Trainingsteilnehmern oder potentiellen Kunden während einer Bedarfsermittlung berichte, sind viele überrascht, teilweise irritiert oder sogar enttäuscht, weil ich die naive Hoffnung auf den Masterplan für eine bessere, schnellere Produktentwicklung, im Keim ersticke. Der Wunsch, dass Teams schnellstmöglich agil werden und in Zukunft selbstorganisiert höhere Qualität pünktlich liefern, ist legitim und absolut nachvollziehbar. Eine Veränderung der Arbeitsweise durch die bloße Einführung einer neuen Methode setzt jedoch bei der Erfüllung eines solchen Wunsches viel zu spät an und ist vollkommen oberflächlich. Damit Scrum spürbar Wirkung erzielen kann, müssen sowohl strukturelle, als auch mentale Voraussetzungen geschaffen werden. Scrum ist nicht die Lösung. Die Lösung steckt vielmehr in der Beantwortung von Fragen, die sich das Management stellen muss, um ein Gefühl dafür zu bekommen, wie bereit das jeweilige Unternehmen ist, Scrum und seine Prinzipien tatsächlich zu leben:
- Was ist der eigentliche Auslöser für die Einführung von Scrum und warum soll das gerade jetzt passieren?
- Wie lange darf es dauern, bis erste Erfolge sichtbar werden?
- Welche Bestrebungen gibt es bereits, eine agile Organisation zu werden?
- Was bedeutet Agile Leadership und inwieweit unterscheidet sich das von klassischer Führung?
- Was machen Tester, Analysten oder Designer zukünftig, wenn es Scrum Teams gibt?
- Wo möchte man Test- oder Releasemanagement zukünftig verankern?
- Welchen Grad an Selbstorganisation möchte man in den Scrum Teams erreichen?
- Wie ernst meint man die Idee vom Product Ownership?
- Möchte man zukünftig Produkte entwickeln oder gibt es auch weiterhin noch Projekte?
- Welche technischen Voraussetzungen sind vorhanden und/oder fehlen noch, um kontinuierlich releasefähig zu werden?
- Was machen Führungskräfte zukünftig oder wie wird Führung in selbstorganisierten Teams gelebt?
Die Qualität der Fragen belegt offenkundig, dass die größte Gefahr in Zeiten des Wandels nicht der Wandel selbst ist. Es ist das Handeln mit den Mustern von gestern. Jeder möchte den Wandel oder zumindest fast jeder. Den Preis, sich dabei verändern zu müssen, möchten jedoch die wenigsten zahlen - am allerwenigsten die, die offensichtlich am meisten zu verlieren haben. Und somit enden die anfangs zitierten Wünsche in äußerst schmalen Lippenbekenntnissen und verpuffen „unterwegs” in aussichtslosen Kämpfen gegen die verkrusteten Windmühlen der Welt von Gestern.
Scrum ist nicht die Lösung. Und trotzdem lauert die Lösung überall - in jedem Mitarbeiter, der mutig über seinen Schatten springt, in jeder Führungskraft, die neugierig über ihren Tellerrand schaut, in jeder Entscheidung, die zu mehr Autonomie und Klarheit beiträgt.
Dream big, start small but most of all just start!
