Konzern-Anarchismus (und was macht man dagegen?)

Bild: Flickr/JDHancock - CC BY 2.0

Nicht alle Einführungen von Scrum oder anderen agilen Methoden sind Erfolgsgeschichten. Bereits mehrfach durfte ich aus der Nähe miterleben wie agile Transitionen gescheitert sind. Die Gründe dafür sind nicht etwa einzigartig und einzelfallbezogen (obwohl das natürlich immer wieder behauptet wird) sondern treten fast immer als die Variationen einiger weniger Grundmuster auf: ein Management das der Idee selbstverwalteter Teams nicht traut und ständig "reinregieren" will ist ein Klassiker, Stabspositionen wie der Lead Developer oder der Testmanager die die Methode sabotieren weil sie ihre Existenzberechtigung gefährdet sehen sind ein weiterer. Ein dritter entfaltet aber eine besonders verheerende Wirkung: die Unwilligkeit und Unfähigkeit praktisch aller Betroffenen sich an Regeln jeglicher Art zu halten, solange diese nicht mit Zwang und Sanktionsandrohungen eingeführt werden. Da dieses Phänomen vor allem bei den Mitarbeitern großer Unternehmen auftritt würde ich es als "Konzern-Anarchismus" bezeichnen.

Auf den ersten Blick mag das überraschend erscheinen - gerade Konzerne sind es doch, die ihre Mitarbeiter mit zahllosen Vorschriften, Vereinbarungen, Richtlinien und sonstigen Vorgaben überhäufen, und das nicht etwa aus bösem Willen, sondern aus dem Irrglauben heraus, dass derartig "angeleitete" Angestellte besonders produktiv wären. Und gerade Konzerne haben es doch perfektioniert jeden Widerstand gegen derartige Vorgaben konsequent zu brechen. Wie kann es also sein, dass ausgerechnet diese Angestellten konsequent jede Regel zu unterlaufen versuchen? Müsste nicht ihre gesamte berufliche Sozialisation in die genau andere Richtung geführt haben, in eine Art "Untertanenhaltung", in der alle Vogaben kritiklos angenommen und folgsam umgesetzt werden?

Leider nein. Die bemerkenswerte Wahrheit ist nämlich, dass sich diese Vorschriften meistens gar nicht umsetzen lassen. Es ist schlichtweg nicht möglich immer zeitgleich mit Hochleistung zu arbeiten, Leerlauf zu vermeiden, die eigenen Tätigkeiten und Produkte detailliert zu dokumentieren, zu Produkt- und Prozessverbesserungen beizutragen, Planziele zu erfüllen, Termine, Kostenrahmen und Qualitätsstandards einzuhalten, Wissen weiterzugeben, Überstunden zu vermeiden und "die Unternehmensvision zu verinnerlichen". Immer werden einige dieser Teilziele in Widerspruch zueinander stehen und sich gegenseitig verhindern. Da aber fast jedes dieser Teilziele von einer anderen Abteilung kommt (Personal, Compliance, Recht, etc.) und jede ihr Teilziel als besonders wichtig und unverhandelbar ansieht, steht am Ende der Angestellte vor der Wahl: entweder er macht heimliche und unbezahlte Überstunden (was schnell zum Burnout führt) oder er beginnt systematisch die Vorgaben zu unterlaufen und hält sich nur noch an sie wenn er explizit dazu gezwungen wird.

Natürlich bleibt das auf Dauer nicht verborgen. Anstatt in sinnvoller Weise zu reagieren und die Arbeits- und Vorschriftenlast herunterzufahren werden in vielen Firmen aber immer weitere Vorschriften und Kontrollmechanismen erdacht und zusätzlich auf die Bestehenden gepackt, um so Regelabweichungen zu verhindern. Das Problem: da die bestehenden Widersprüche so nicht aufgelöst werden stehen die neuen Regeln automatisch in Widerspruch zu einem Teil der alten. Mit jeder dieser "Verbesserungsrunden" wird es also unmöglicher alles zu tun was vorgeschrieben ist, wodurch die Mitarbeiter immer neue Wege erfinden, diesen Regeln auszuweichen. Es ist ein Wettlauf den keiner gewinnen kann. Und an dieser Stelle wird ein agiles Framework wie z.B. Scrum eingeführt.

Natürlich erscheint das den Betroffenen wie der X-te Versuch das Problem zu vieler Regeln durch die Einführung von noch mehr Regeln zu lösen. Und selbstverständlich reagieren sie darauf mit den Notwehr-Mechanismen, die sie seit langem eingeübt haben: Abblocken, Unterlaufen, Verzögern, Verwässern und Aussitzen. Das Bemerkenswerte daran - häufig ist das auch die einzig richtige Option. Dann nämlich, wenn die neue Methode die alte nicht ersetzt sondern zusätzlich zu ihr eingeführt wird. Wenn es z.B. heisst: "Wir machen schon Scrum, nur mit Konzeptionsphase und der bewährten Feinspezifikation." Oder "Wir machen schon Scrum, aber mit eigenen Test- und Hardening-Sprints als Ersatz für die Test- und Bugfixing-Phasen." Eine Scrum-Wasserfall-Kombination funktioniert nämlich genauso wenig wie der alte Überregulierungsansatz.

Aber nehmen wir nicht diese Negativ-Fälle sondern gehen vom Positiven aus: das Management hat dazugelernt, der Vorschriften-Overhead wurde abgebaut, es wird wirklich versucht agil und lean zu arbeiten. Und trotzdem stellen die Mitarbeiter sich quer, weil sie es schon zu oft gehört haben, "dass es diesesmal wirklich anders ist" und nicht mehr an solche Versprechungen glauben. Was ist jetzt zu tun? Ich würde an dieser Stelle folgende Maßnahmen empfehlen:

• Aufzeigen klarer Grenzen. Selbstverwaltet ist etwas anderes als Beliebigkeit, und bestimmte Dinge (z.B. incrementelles Arbeiten, intensive Kommunikation und kurze Feedback-Schleifen) sind nicht verhandelbar. Dabei sollte aber auch aufgezeigt werden in welchen Bereichen das Team tatsächlich selbst entscheiden kann (z.B. bei der Frage wie viel Arbeit es in den nächsten Sprint nehmen will).
• Visualisierung des Regel-Abbaus. Alle alten, abgeschafften Vorschriften auf ein Board, die neuen, schlanken auf ein zweites, das zum Vergleich danebensteht. Das bringt auch einen weiteren Vorteil: wenn jemand heimlich oder versehentlich wieder widersprüchliche Regeln einführen will wird das hier transparent sichtbar gemacht.
• Thematisierung in Einführungs-Workshops und Retrospektiven. Warum machen die Regeln diesesmal wirklich Sinn und warum wird das Arbeiten durch sie diesesmal nicht unmöglich gemacht? Natürlich muss dabei zu Vergleichszwecken auch angesprochen werden warum die alte Methode Mist war. Das gefällt im Zweifel nicht jedem, lässt sich aber nicht vermeiden.

Mit diesen und ähnlichen Methoden kann es gelingen, den Konzern-Anarchismus nach und nach in eine Commitment- und Verantwortungskultur überzuführen. Man muss sich aber eines bewusst machen - es kann dauern. Eine Geisteshaltung die in Jahren, vielleicht sogar in Jahrzehnten entstanden ist ändert sich nicht in einem Sprint oder in einem Monat. Ein befreundeter Scrum Master erzählte mir einmal von einem Übergang den ein Team erst nach Jahren abgeschlossen hatte. Das mag ein Extremfall sein, aber mehrere Monate braucht man auf jeden Fall mindestens dafür. Die sind dann aber auch gut investiert.