Dafür müsste sie zunächst einmal lebendig gewesen sein, oder? Aber natürlich ist die Sache weitaus komplexer. Über welche Art von Unternehmen sprechen wir, und was verstehen wir eigentlich unter Agilität? Mir geht es um einen Satz, den jeder von Euch wahrscheinlich schon oft gehört hat: was wir hier tun, hat nichts mit Agilität zu tun.
Ich bewege mich zumeist im hoch skalierten Konzernumfeld, und da höre ich genau diesen Satz – erstaunlicherweise auch immer wieder genau so formuliert – in fast jedem Team, mit dem ich zusammenarbeite. Das Erste, was dabei auffällt, ist, dass ich diesen Satz noch nie nie niemals aus dem Management gehört habe.
Das ist der erste Aspekt, über den ich sprechen möchte: Ziele.
Für das Management ist nur eines wichtig, nämlich dass der Laden laufen muss. Wie das passiert, ist dabei vollkommen egal. Wenn das Mittel der Wahl Agilität ist, über Scrum und in einer SAFe Skalierung, dann ist das genauso gut, wie ein ganz traditionelles Command-and-Control-Projektmanagement, wenn die Ergebnisse die gleichen sind. Und diese Sicht auf die Dinge ist für mich vollkommen verständlich.
Die Wahl der Werkzeuge – Agilität oder Scrum im Speziellen – dient einem Ziel, und in den Unternehmen, in denen wir arbeiten, ist das Ziel immer eine Gewinnmaximierung unter Einsparung von Kosten und Erhöhung des Outputs pro Mitarbeiter. Das ist eine rein betriebswirtschaftliche Sicht. Genauso sind unsere Unternehmen aufgestellt, genauso denken und handeln sie.
Jetzt könnte man sagen, dass Agilität genau das liefern soll. Es zwingt uns dazu, Verschwendung zu eliminieren und uns auf das Wesentliche zu fokussieren, was letztlich den Output pro Mitarbeiter erhöhen sollte. Nun kommen wir aber ein großes Problem. Viele unserer Kollegen erwarten, dass sie an Entscheidungen beteiligt werden und in ihrer Planung wirklich sprintweise denken können. Das ist es, was viele Personen unter Agilität verstehen.
Diese Sicht beißt sich allerdings mit den Produkten, die wir entwickeln. Sie sind zum einen viel zu groß, als das ein einzelnes Team daran arbeiten könnte, und daher ist es auch kaum möglich als Team direkt mit dem Anwender in Kontakt zu kommen, um deren direktes Feedback aufzunehmen.
Die Größe und Komplexität des Produkts und die damit verbundene Notwendigkeit, mehrere Teams miteinander zu orchestrieren, ist dabei unser größter Feind. Nur die Tatsache, dass viele Teams zusammenarbeiten müssen, unter Berücksichtigung von Abhängigkeiten und Timelines, führt dazu, dass viele Entscheidungen aus den Teams herausgezogen und zentral gebündelt werden. Unsere Entwicklerteams haben wenig Einfluss auf ihr eigenes Backlog. Wir füllen es selbst, aber wir füllen nur die Details auf. Welche größeren Features umgesetzt werden, in welcher Reihenfolge und in welchem Umfang, wird auf einer skalierten Ebene entschieden.
Erneut muss ich die Frage stellen, ob das schlecht ist. Natürlich haben wir gelernt, dass in Scrum der Product Owner Herr oder Herrin über das Backlog ist und allein über das Produkt entscheidet.
Wenn mehrere Teams zusammenarbeiten müssen, funktioniert das schon einmal überhaupt nicht. Man könnte eventuell ein Product Owner Gremium bilden, in dem alle gleichberechtigt über das Produkt entscheiden.
That has Success written all over it …
Also haben alle Skalierungen von Scrum einen Chief PO, Product Management, eine Solution Ebene oder was auch immer, um die übergreifende Roadmap des Produkts zu bearbeiten.
Das unterwandert den Scrum Gedanken, dass alle Entscheidungen im Team liegen, aber ist das deshalb weniger agil?
Schwierige Frage. Dazu müssten wir uns zuerst einigen, was Agilität eigentlich ist. Das haben Generationen vor uns schon nicht geschafft. Es gibt nicht die eine Definition von Agilität. Das Agile Manifest eine Sammlung von Grundsätzen – nicht mehr und nicht weniger. Glaubt nicht, wenn Euch jemand eine offizielle allgemeingültige Definition von Agilität verkaufen will, die für alle gilt. So etwas gibt es nicht.
Ich behaupte, dass eine solche Skalierung nicht weniger agil ist, nur weil sie sich von Scrum entfernt. Wenn ein solches Vorgehen das Feedback des Kunden annimmt, in möglichst kurzen Iterationen vorgeht, von sich selbst lernt und damit im Regelkreis Plan-Do-Check-Act bleibt, würde ich das noch immer ein Agiles Vorgehen nennen, es ist dann nur nicht mehr Scrum.
Aber seien wir ruhig ehrlich: Scrum hat kein Agiles Monopol.
Wir wissen schon lange, dass Scrum in einer skalierten Umgebung nicht mehr funktioniert, eben weil viele Entscheidungen aus dem Team herausgezogen und auf eine skalierte Ebene gehoben werden, weil es anders kaum machbar ist.
Mein Kritikpunkt ist, dass der Input und die Expertise der Teams auf eben diesen entscheidungsbefugten skalierten Ebenen in sehr vielen Beispielen nicht genug Berücksichtigung finden und wir leider in viel zu vielen Organisationen dazu tendieren, unsere Entwicklungsteams zu reinen Produktionsmaschinen zu degradieren.
Wenn wir eine Situation vorfinden, in der alle größeren fachlichen Entscheidungen außerhalb der Teams liegen, wo eine große Expertise in Form unserer POs liegt, dann ist das ein großes Problem und die viel größere Sünde. Erfolgt das Lösungsdesign von Solutionarchitekten ohne Beteiligung der Entwickler aus den Teams, und wir kommen an den Punkt, an dem Entwickler die Arbeit der Architekten in Frage stellen und sich darüber beklagen, dass diese ihnen das Leben eigentlich eher schwerer machen als zu erleichtern, dann habe ich Fragen.
Welchen Weg haben wir aus dieser Situation?
Wenn Ihr z.B. Scrum Master in einem Team seid, dann eigentlich keinen, weil Ihr sehr wahrscheinlich wenig Einfluss auf die Prozesse jenseits unseres Teams habt. In diesem Fall liegt es an uns. Diesen Zustand unserem Team begreiflich zu machen und diese Situation als Rahmenbedingung zu akzeptieren. Das bedeutet keinesfalls, dass wir nicht versuchen sollten, diese Dinge anzugehen, die der Organisation in höchstem Maße schaden. Ich sage lediglich, dass dieser Versuch leider oft genug vergeblich ist. Und dann hilft es uns nicht, wenn wir uns darüber beklagen, wie schlecht die Welt ist, und dass niemand uns verstehen will. Wir müssen damit leben und diese Rahmenbedingung in unsere Arbeit integrieren.
Einen aussichtslosen Kampf zu führen, hilft niemandem. Schlimmer noch, er zieht Ressourcen von den Aufgaben ab, wo tatsächlich eine Veränderung bewirkt werden kann.
Bewegen wir uns jedoch auf dieser skalierten Ebene und haben Einfluss auf die Arbeitsweise und Entscheidungsfindungen dieser Ebene, dann ist es eine verdammt gute Idee, die Expertise, wo sie vorhanden ist, mit einzuholen, auch wenn wir dafür den Pfad eines von der Organisation definieren Prozesses verlassen.
Es gibt zwei Gründe, warum das nicht immer und überall geschieht: auf der einen Seite den Bösartigen in Form eines vollkommen unangebrachten Protektionismus, und auf der anderen Seite den Dummen im blinden Befolgen eines vorgegebenen Prozesses.
Hier finden wir den einzigen Ansatz, den wir haben, das Unding, dass Entscheidungen maximal weit weg von der Umsetzung getroffen werden, irgendwie anzugehen: eine Person finden, die Teil dieser Entscheidung ist und freundlich auf sie einzuwirken, dass es eventuell eine gute Idee sein könnte, die größte verfügbare Expertise einzuholen.
Und wenn ihr die Chance habt, den Prozess zu ändern, der nicht vorsieht, die POs aus den Teams zu den Entscheidungen zur Roadmap etc. mit einzubeziehen, dann macht das.
Kernaussagen:
- Agilität stirbt nicht – sie wurde in vielen Organisationen nie wirklich gelebt.
- Management bewertet Agilität als Werkzeug zur Effizienz‑ und Gewinnsteigerung, nicht als Kultur oder Haltung.
- In skalierten Konzernstrukturen werden Entscheidungen zwangsläufig zentralisiert – Scrum-Prinzipien leiden, Agilität muss das nicht.
- Agil ist nicht gleich Scrum: Entscheidend sind Feedback, kurze Iterationen und Lernen, nicht das Framework.
- Kritisch wird es, wenn Team-Expertise ignoriert und Entwicklungsteams zu reinen Ausführenden degradiert werden.
- Wahre Agilität entsteht dort, wo Entscheidungen möglichst nah an der Umsetzung getroffen werden.
Wenn Ihr mehr erfahren wollt, oder Unterstützung braucht, sprecht mich einfach an.
