Agil ist eine Haltung – kein Tool

…denn das agile Betriebsssystem funktioniert nur mit entprechender Software…

Kennen Sie diese Versprechen der \“agil musst Du sein Kampagne\“ auch?

• Agil sein löst alle Probleme
• Es ist kein Plan und kein Bericht mehr nötig
• Alle im Team sind gleich, Führung wird obsolet
• Jeder kann arbeiten wie er möchte
• Agil zu werden geht schnell, man braucht man nur die Unternehmensbürokratie abzuschaffen
• Agil sein = SCRUM einführen

Die Themen Agilität und SCRUM, die leider oft gleichgesetzt werden, haben in den letzten Jahren einen regelrechten Siegeszug durch die Beratungs- und Fortbildungslandschaft angetreten. Scheinbar ist es den Managementechnikern im Maschinenraum wieder einmal gelungen ein Konzept, das auf Werten, Haltung und Verhalten beruht, zum Tool zu machen. Denn der Kern agilen Arbeitens sind nicht die ausdifferenzierten Tools, sondern die Haltung, die es braucht, um in einer digitalen, 4.0 VUCA Welt erfolgreich zu sein.
Nicht ohne Grund braucht der SCRUM Guide nur knapp zwanzig und das agile Manifest nur eine einzige Seite, um zu erklären, worum es geht. Die sechs Kernwerte und Prinzipien, die dieses Manifest und die darauf basierenden Methoden (u.a. SCRUM) tragen, fasst mein Kollege Heiko Bartlog mit dem Satz

„Scrum ohne Werte und Prinzipien ist für mich wie ein seelenloser Roboter: funktioniert, aber nur auf Befehl“

und in dieser wunderbaren Abbildung zusammen.

Wer agil arbeiten will, der braucht diese sechs Fähigkeiten die andere sind, als im hierarchischen Betriebssystem. Aber agil zu arbeiten bedeutet nicht absolute Freiheit, vollständige Selbstorganisation und die Abwesenheit von gutem Management und wirksamer Führung. Warum denn auch? Denn überall, wo es dampft und segelt, d.h. Arbeitsteilung und Arbeit in Team stattfindet, braucht es Prinzipien und Personen, die die Sache regeln!

Und deshalb

• löst „agil sein“ nicht alle Probleme, sondern stellt zunächst einmal die vorherrschende Kultur der Organisation auf den Prüfstand. Denn die sechs Werte werden unmittelbar gebraucht und müssen „gezeigt“ werden. Ist dies nicht der Fall, prallt Agilität an den Verhaltensmustern des hierarchischen Betriebssystems ab.
• braucht es im agilen (SCRUM, Lean, Kanban, etc..) Betriebssystem weiterhin Pläne und Berichte. In SCRUM wird kontinuierlich und in kurzen Zyklen geplant und über den Arbeitsstand berichtet (daily scrum). Pläne werden also nicht abgeschafft, sondern flexibel und gegen gegen Überalterung „immun“.
• gibt es in SCRUM Teams drei klare Rollen mit definierten Entscheidungsräumen: Der Product Owner verantwortet das Produkt, das Entwicklungsteam verantwortet den Weg zur Umsetzung und der SCRUM Master achtet darauf, dass die (selbst bestimmten) Regeln und Rollen eingehalten werden. Er vermittelt zwischen den beiden anderen Rollen und weiteren Stakeholdern und hat selbst keine Entscheidungsgewalt.
• hat das Team im SCRUM Betriebssystem klare Vereinbarungen wie das Team den Weg zur Umsetzung vereinbart und kontrolliert. An task boards wird mit einem Blick deutlich, wer mit seiner Aufgabe wo steht, in Sprint Meetings wird SOLL und IST verglichen und in Review Meetings wird das Arbeitsverhalten auf Produktivitätsreserven untersucht.

Und schließlich ist die Einführung von agilen Betriebssystemen allein noch keine hinreichende Bedingung für eine erfolgreiche agile Organisation. Wer die sechs Basis Werte nicht antrifft, der wird die Organisation mit hoher Wahrscheinlichkeit sogar weiter an die Grenze der Inkompetenz bringen, statt sie wirksamer zu machen.

Wer sich auf den Weg zur agilen Organisation begibt, hat aktuell wohl die besten Aussichten, wenn er nach der Strategie „praktiziere was Du predigst“ vorgeht. Ayelt Komus und Moritz Kuhberg von der Hochschule Koblenz, die für die Deutsche Gesellschaft für Projektmanagement den „Status Quo Agile“ beobachtet haben, empfehlen dies im Fazit ihrer Studie:

„Unternehmen sollten individuell prüfen, welche Voraussetzungen und Rahmenbedingungen in ihrer Organisation und in den einzelnen Aufgabenstellungen gegeben sind und darauf aufbauend eine angemessene Agilisierungsstrategie entwickeln. Natürlich gilt es auch diese Strategie laufend zu überprüfen und zu hinterfragen. Schon die Einführung agiler Methoden sollte agil erfolgen; also in kleinen Schritten eingeführt, getestet und anschließend retrospektiv hinterfragt und angepasst werden. Gemäß des agilen Grundsatzes „Fail early, fail often, fail cheap“ sollte auch bei der Einführung auf die Nutzung kleiner Schritte und die schnelle Realisierung von Lernkurven Wert gelegt werden.“