Wenn ein größeres Unternehmen sich in Richtung Agilität transformieren möchte, so kommt früher oder später der Zeitpunkt, an dem – und sei es, um „dabei zu sein“ – auch Querschnittsbereiche wie HR oder Controlling auf einmal agile Methoden anwenden wollen. So kam es, dass ich kürzlich ein Gespräch mit Kollegen aus dem Controlling hatte, die unbedingt Scrum einführen wollten.

Ich muss zugeben, dass mir die Arbeit des Finanz-Bereiches zunächst noch etwas schleierhaft war, daher fragte ich mich zunächst durch, wie denn die tägliche Arbeit aussähe. Und siehe da, im Controlling besteht die tägliche Arbeit gar nicht aus Projekten oder der Produktumsetzung. Statt dessen werden monatlich die Auslastungs- und Umsatzzahlen erhoben und geprüft, dann gibt es einen monatlichen Bericht. Super, damit lässt sich doch auch leicht ein Sprintziel definieren, oder? Einfach jeden Monatsabschluss als Sprintziel benennen…

Das ist natürlich absolut sinnlos. Durch Sprints ist hier gar nichts gewonnen; die Frage ist nämlich vollkommen falsch gestellt. Wenn das Unternehmen agil werden soll, so muss nicht jeder Querschnittsbereich agile Methoden befolgen, die erste Frage sollte sein, wie sich die Arbeit inhaltlich ändert.

Ist es beispielsweise bislang im Controlling und in der Buchhaltung die Aufgabe des Finanzbereiches, in Richtung Geschäftsführung die Zahlen zu kommunizieren, damit diese strategische Entscheidungen treffen kann, so ändert sich in einem agilen Unternehmen die Zielrichtung der Kommunikation: Alle Mitarbeiter müssen die Zahlen verstehen, um selbstorganisiert arbeiten zu können und um strategische Entscheidungen zu erarbeiten.

Auch eine klassische Budgetierung steht einem agilen Unternehmen im Weg. Eventuell kann das Bild eines „internen Kredites“ für Innovationen erfolgversprechender und für die Mitarbeiter fassbarer sein.

All dies darf dann auch meiner Meinung nach gerne in den „klassischen Strukturen“ methodisch abgebildet werden. Eine Methode zu wählen, die dies eventuell besser unterstützt ist dann zumindest erst der zweite (oder dritte) Schritt.

Eigentlich mag ich kein Taylorismus-Bashing, zu oft wird mir da polemisiert. Trotzdem ist eine zentrale Idee daraus in einem modernen Dienstleistungs-Unternehmen nicht mehr angebracht: die Trennung zwischen Denken und Ausführen.
Für operative Prozesse ist diese Trennung im Konkreten zwar vielleicht ungewohnt für einige Beteiligte, aber doch erst einmal nachvollziehbar. Noch schwieriger scheint es allerdings für manche zu sein, wenn es um „strategische“ Entscheidungen geht, insbesondere, wenn  diese bislang zentral getroffen wurden.

Auch wenn ein Unternehmen dazu übergeht, Entscheidungen über das „Wie wird etwas umgesetzt“ in die Teams zu verlagern, so ist beim „Was“ oft noch der Reflex, das in den oberen Ebenen zu lassen. Konkret zeigt sich dies dann beispielsweise in einer Hierarchie von Product Ownern, in der „ganz oben“ die Strategie vorgegeben wird, während „unten“ die Implementierungsdetails ausgearbeitet werden sollen.

Damit entsteht jedoch das gleiche Problem, wie es Dienstleister mit dem klassischen Taylorismus haben: Ich kann nicht da entscheiden, wo ich mit dem Kunden interagiere. Statt dessen wird „oben“ die Strategie festgelegt, eventuell noch von Personen, die vom Tagesgeschäft weit entfernt sind.
Allerdings ist dies ein falsches Verständnis davon, wie in agil agierenden Unternehmen – auch großen – Strategie entstehen sollte: Strategie ist das Ergebnis der Synchronisation von kundennahen Teams; nicht das Arbeitsergebnis einer „höheren Einheit“.

Wohlgemerkt, das heißt nicht, dass es keine gemeinsame Strategie geben sollte; der Entstehungsprozess muss allerdings nicht nur anders gemacht, sondern insbesondere auch anders empfunden werden.
Das heißt auch nicht, dass es keine strategischen Bereiche geben kann – wobei sie in agilen Unternehmen eventuell kleiner sind, als in „klassischen“. Die strategischen Bereiche haben dann 2 zentrale Aufgaben: Sie moderieren die Synchronisation des Entscheidungsprozesses und sie stellen Informationen zur Verfügung – beispielsweise Marktübersichten oder relevante Finanzdaten.

„Wie steht es eigentlich um unseren Veränderungsprozess? Sind wir schon agil?“ – viele Firmen stellen sich unweigerlich irgendwann diese Frage, wenn sie sich in einer Agilen Transformation befinden. Nicht zu unrecht, möchte man doch auch wissen, ob sich Energie und Aufwand lohnen.
Um diese Frage zu beantworten werden gerne unterschiedliche Indikatoren herangezogen: Kundenzufriedenheit, Mitarbeiterzufriedenheit, Anzahl der Teams mit besetzten „agilen“ Rollen, umgesetze Story-Points oder was auch immer.
Auch das ist meiner Meinung nach nicht per se falsch – allerdings wird oft vergessen, was ein Indikator ist.

Ein Indikator ist etwas, was leicht messbar ist und mit der zu betrachtenden Zielerreichung korreliert.

„Korreliert“ ist hierbei ein sehr relevantes, aber oft ignoriertes, Wort. Es wird nämlich nicht zwangsweise ein „kausaler“ Zusammenhang vorausgesetzt.
Nehmen wir ein technisches Beispiel: In vielen Haushalten (und Firmen) hängen Geräte an der Decke, die bei einem Brand warnen sollen. Nur messen diese Dinger oft gar kein Feuer. Viele messen… Rauch. Rauch korreliert nun ziemlich stark mit Feuer, deswegen passt das ganz gut. Aber wer ein solches Gerät in der Küche hat, der hat sicher auch die Erfahrung gemacht, dass die Dinger nicht nur bei einem Brand losgehen.
Wirklich störend wird diese fehlende (zumindest eindeutige) Kausalität allerdings erst dann, wenn man beginnt, die Indikatoren nicht nur zu messen, sondern auch zu einem Ziel zu erklären. Im schlimmsten Fall noch zu einem Ziel, an dessen Erfüllung ein Bonus oder sonst irgendeine Gratifikation hängt. Dann beginnen nämlich die Beteiligten, den Indikator direkt zu beeinflussen, ohne sich um das ursprüngliche Ziel zu kümmern. Das ist nämlich meist viel einfacher! Sage ich beispielsweise einem Team, dass eine hohe Velocity toll ist und ich deswegen nun anfange, „Story Points pro Sprint“ zum Ziel zu erklären, werde ich sicherlich eine Inflation an Story Points beobachten können. Messe ich „ausgebildete Agile Rollen“, so gehen dutzende Mitarbeiter in beliebig nützliche Scrum-Schulungen, ohne das ernsthaft betreiben zu wolen. Zähle ich, wie viele Teams „agil“ arbeiten, so werden einfach ein paar bestehende Teams in Scrum-Team umbenannt und sie arbeiten weiter wie bisher.

Heißt das nun, dass man Indikatoren gar nicht messen soll? Doch, das sollte man, aber in einer Zieldefinition haben diese nichts zu suchen! Denn auch wenn Ziele messbar sein sollten, ist nicht alles messbare ein geeignetes Ziel. Aber Indikatoren regelmäßig zu betrachten ist sehr sinnvoll – und diese kritisch zu hinterfragen. Denn wenn man die Indikatoren nicht in (langfristigen) Zielen festgeschrieben hat, so kann man diese auch relativ leicht durch bessere Indikatoren austauschen oder ergänzen. So unteriegt auch die Betrachtung von Indikatoren einem ständigen Verbesserungsprozess.

Hierarchien sind etwas schlechtes. Böse Manager unterdrücken ihre Mitarbeiter, halten sie vom eigenständigen Denken ab und wollen nur ihre Macht anhäufen.

So scheint es einem oft, wenn in Unternehmen sich die „Agilen Werte“ durchsetzen wollen, Ziel ist immer eine „flache Hierarchie“. Davon abgesehen, dass es das oben beschriebene Verhalten von Managern wohl geben mag, möchte ich an dieser Stelle eine Lanze für Hierarchien in Unternehmen brechen. Wozu sind diese also Nutze?

Hierarchien nehmen Druck

Der CEO einer anderen Firma, für die man tätig ist, ruft erbost den eigenen CEO an, damit „wichtige Features“ doch noch durchgedrückt werden. Der eigene CEO bestellt die Bereichsleiter ein, um ihnen die Wichtigkeit zu verdeutlichen. Die Bereichsleiter wenden sich an die Abteilungsleiter, geben die Info weiter, die Abteilungleiter teilen dem Projektleitern mit, was der Kunde wünscht. Auf der einen Seite könnte das ein „nach oben buckeln, nach unten treten“ werden, aber oft wird durch diese Hierarchie der Druck heraus genommen. Vom erbosten CEO bleibt (zumindest bei einem guten Management) bis zur Projektebene nicht mehr ganz so viel Wut übrig. So können Hierarchien die Mitarbeiter „schützen“ und statt des „Push“ ein „Pull“ in den Projekten ermöglichen.

Wichtige Entscheidungsträger werden geschützt

In jedem Unternehmen ab einer gewissen Größe gibt es Mitarbeiter, die mehr Erfahrung mit bestimmten Technologien oder anderen Themen haben. Diese Mitarbeiter sollten dann typischerweise für wichtige Entscheidungen oder Unterstützung bei hoch priorisierten Projekten zur Verfügung stehen. In klassischen Hierarchien handelt es sich dabei um Chefarchitekten, Chefstrategen oder Senior-Vice-Irgendwas. (Zumidnest unter der eventuell etwas naiven Annahme, dass die Beförderung auf Kompetenz beruht…) Dadurch ist der Zugang zu diesen Mitarbeitern über die Hierarchie „reglementiert“ und sie können in den wichtigen Themen eingesetzt werden.

Und nun, heißt das, ich möchte, dass doch klassische Hierarchien bestehen bleiben? Nicht unbedingt – aber man sollte meiner Meinung nach die Vorteile kennen, da bei einer Transformation hin zu einer flachen Hierarchie diese Effekte auf einmal nicht mehr da sind. Eventuell wird daher der Druck auf Mitarbeiter größer oder Wissensträger sind nicht mehr für die wichtigen Themen verfügbar.