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.

Das „Agile Unternehmen“ ist mittlerweile in mehr und mehr, auch größeren Konzernen, ein Ziel. Eines wird dabei aber oft missverstanden: Ein Agiles Unternehmen bedeutet nicht, dass überall (beispielsweise) Scrum gemacht werden muss. Agilität auf Unternehmensebene heißt, dass sich das Unternehmen den Kundenwünschen anpassen kann, so dass die Mitarbeiter, die mit dem Kunden zu tun haben, wichtige Entscheidungen treffen können.

Eine der Entscheidungen kann auch sein, dass mit dem Kunden ein „klassisches“ Projekt durchgeführt wird, mit Projektleiter, Lasten- und Pflichtenheft und allem, was sonst moch dazu gehören mag. Sicher, eventuell kann man den Kunden dahin beraten, dass ein anderes Vorgehen sinnvoller sein mag, doch wenn man auf den „einzig richtigen Weg“ besteht, so zeigt sich das Unternehmen alles andere als beweglich, also agil.

Dem Widerspricht nicht, dass man auch in klassischen Projekten die Agilen Prinzipien leben kann. Qualität, Kollaboration und Offenheit sind auch im „Wasserfall“ immer angebracht.
Ab einer gewissen Größe scheint es für Unternehmen allerdings immer schwieriger it der Beweglichkeit zu werden. Irgendwann kommt der Punkt, an dem man als Mitarbeiterin oder Mitarbeiter denkt „ich weiß was der Kunde will, aber das können wir nicht machen“. Allerdings nicht, weil das für das Unternehmen zu schwierig sei, sondern weil man weiß, dass es nicht abrechenbar ist, weil das die SAP-Warengruppen nicht vorsehen, weil das im Standardkatalog für Softwarekomponenten nicht vorkommt oder aus welchen Gründen auch sonst.

An dieser Stelle muss ein Unternehmen meiner Meinung nach arbeiten, um „agil“ zu werden. Man muss die Teams, die direkt mit dem Kunden interagieren, in die Lage versetzen, Entscheidungen treffen zu können, die dem Kundennutzen zu Gute kommen – und das ist viel seltener die Auswahl zwischen 3 Standard-Architekturen, als manch ein Enterprise Architect sich erhofft. Ein agiles Unternehmen ist eines, das Entscheidungen möglichst weit dezentralisiert, um gegenüber dem Kunden beweglich auftreten zu können.

Stell Dir vor, es kommt ein Handwerker bei Dir vorbei um beispielsweise das Bad zu renovieren. Am Eingang begrüßt Du ihn freundlich und sagst dann: Wir haben hier überigens Standard-Werkzeug. Sein eigenes Werkzeuig soll er also liegen lassen, statt dessen gibst Du ihm einen anderen Werkzeugkasten. Mit Hammer, Schraubenziehen und allem, was dazu gehört.

Ein guter Handwerker würde wohl auf der Stelle kehrt machen, bei Softwareentwicklern ist das aber aus irgend einem Grund gang und gäbe. Okay, nun verlange ich nicht, dass jede Softwarefirma sagt, dass der Entwickler seinen eigenen Computer verwenden soll; aber das Standard-Werkzeug, dass es oft gibt, ist ebenso oft eine Unverschämtheit gegenüber den Mitarbeitern.

Klar, wenn man in einem Projekt zusammen arbeitet, so sollte man sich auf ein gemeinsames „Toolset“ in dem Sinne verständigen, dass nicht ein paar Entwickler GIT nutzen während andere auf SVN schwören. Aber sollte wirklich die Entscheidung „VI(M) vs Emacs“ auf Unternehmensebene getroffen werden? Daher meine Bitte an alle Unternehmen: Gebt euren Entwicklern das Recht, auf ihren Rechnern Software zu installieren. Egal, was ihr tolles „standardmäßig“ mitgebt. Die Arbeitsumgebung sollte kein goldener Käfig sein!

Ja, es gibt Bedenken, die man ernst nehmen sollte. Vom Installieren von illegaler Software bis hin zu Sicherheitslücken. Aber findet dafür bitte andere Wege. Oder noch besser: Stellt Mitarbeiter ein, denen ihr zumindest im Prinzip zutraut, dass sie ihren Job machen und zumindest nicht böswillig sein werden.