Fünf Fallen bei der Skalierung von Agilität
Große Unternehmen suchen besonders nach schnellen und einfachen Wegen, um die Transition von der klassischen zur agilen Entwicklung zu vollziehen. Je schneller eine Transition vonstatten gehen soll, desto gefährlicher sind die Fallstricke, die übersehen werden. Agile Entwicklung baut mehr auf Nachhaltigkeit als darauf, einfach schnell fertig zu werden. Daher hat das Management eine große Verantwortung für den Erfolg der agilen Transition.ten Fallen sorgt, wird höchstwahrscheinlich ein Cargo-Kult. Nach außen hin sieht die Transition erfolgreich aus, doch nach innen herein bleiben die Vorzüge der Transition aus.
Hier haben wir fünf übliche Fallen auf dem Weg zur agilen Organisation zusammengefasst:
1. Fundamentale Agilität
Die Umstellung auf agile Prozesse ist leicht. Man dereguliert ein bisschen und schickt einige Leute ins Training. Danach können die Leute „Scrum machen“ – oder auch einen anderen agilen Ansatz wählen. Doch aufs Ganze gesehen, hat man vielleicht 1% erreicht – 99% des Weges liegen noch vorne. Die Reise ist noch lang. Im Herzen der Agilität steht der Inspect+Adapt Prozess. Damit der funktioniert, braucht man ein besonderes Mindset. Jeder muss schonungslos hinterfragen, was gerade passiert – und Änderungen durchführen, wenn es in die falsche Richtung läuft. Um Inspect+Adapt sinnvoll in der Organisation zu verankern, braucht man zwei Dinge: Zuerst muss die bestehende Arbeitsweise entgiftet werden. Elemente der Firmenkultur, welche Entwickler entmutigen, Ownership für ihre Prozesse zu übernehmen, müssen entfernt werden. Dazu müssen viele Command+Control Prozesse über den Haufen geworfen werden und das Management von Entwicklern grundlegend überdacht werden. Änderung wird es nur dann geben, wenn man sie zulässt! Danach muss eine gesunde Arbeitsweise geschaffen werden. Man benötigt ein Management-System, welches Entwickler ermutigt, die Verantwortung für ihre eigenen Handlungen, Entscheidungen, Änderungen, Misserfolge und Erfolge zu übernehmen. Dazu müssen Strukturen und Prozesse geschaffen werden, welche den individuellen Beitrag des Einzelnen ehrlich wertschätzen – egal, ob das Management mit der Richtung gerade zufrieden ist oder nicht. Die Menschen werden nur ihren Beitrag leisten, wenn man sie lässt!
Bis das Fundament für Agilität gelegt ist, wird es keine Agilität geben. Teams ohne fundamentale Agilität werden weder einen Nutzen aus der agilen Skalierung haben – noch dazu beitragen.
2. Handwerkszeug
Die Zeremonien von Scrum einzuführen braucht gerade mal einen Tag, inklusive Training und der Entscheidung. Damit hat man die Grundlage für „agiles Arbeiten“. Kurzfristige Planung, regelmäßige Updates des Plans, Produkt-Feedback und inkrementelle Verbesserung am Prozess sind essentiell. So können die Entwickler über Zeit die optimale Arbeitsweise herausfinden. Man muss halt nur sehr viel Zeit für die Optimierung einplanen, wenn die Engineering-Practices noch nicht etabliert sind. Die Entwickler müssen vertraut sein mit Konzepten wie Versionskontrolle, Continuous Integration, Testautomatisierung, emergentem Design, TDD, BDD, Pairing, Code Conventions – und vielem Anderen, was XP zu bieten hat. Sie müssen bewusst entscheiden, welche dieser Praktiken ihnen im aktuellen Kontext hilfreich sind. Solange die Entwickler diese Praktiken nicht kennen, kann es sehr wohl sein, dass sie „rituell agil“ sind, jedoch keine Agilität praktizieren. Ein Team ohne das richtige Handwerkszeug kann die Implementierung einer skalierten Entwicklung sogar verlangsamen.
3. Teamgeist
Der oft als esoterisch belächelte Teamgeist ist immens wichtig für die systemische Verbesserung bei agiler Skalierung. Viele Manager denken, dass persönliche Zielvorgaben (bis hin zum Stack Ranking) hilfreich sind, um hochperformante Mitarbeiter zu bekommen. Agile Skalierung dient jedoch in erster Linie dem Aufbau eines komplexen, adaptiven Systems in dem viele Leute einen Beitrag leisen. Die Notwendigkeit, zum Großen Ganzen beizutragen ist weitaus wichtiger als der Beitrag zu den eigenen Zielen. Hier heißt „Teamgeist“, dass Individuen ihre eigenen Interessen grundsätzlich unterordnen müssen, um die Mission des Unternehmens zu fördern. Beim Teamgeist geht es weniger darum, „mit Anderen Dinge zu machen, die Spaß machen“ (z.B. Teamevents wie Rafting, Go-Kart oder Paintball). Es geht in erster Linie darum, dass man Freude daran haben muss, Dinge zu tun, die dabei helfen, gemeinsam vorwärts zu kommen. Dazu benötigen Entwickler zwei Dinge: Erstens, sie müssen wissen, wie sie beitragen können. Weil dies sehr stark vom Einzelfall abhängt, entsteht der Beitrag in erster Linie durch Selbstorganisation und intrinsische Motivation. Zweitens, sie müssen wissen, dass sich Hilfsbereitschaft lohnt. Alles, was einen persönlichen Nachteil schafft, wenn man Anderen bei der Erreichung eines gemeinsamen Ziels hilft, muss entfernt werden. Ein klassisches Beispiel für „Teamgeist“ ist Fußball: Wir haben oft gesehen, dass das Spiel nicht durch den besten Spieler gewonnen wird. Der Gewinner ist die beste Mannschaft. Das ist in der Entwicklung genauso: Asse, die sich gegenseitig ausstechen, gewinnen nicht. Man gewinnt dadurch, dass man Kräfte vereint, Ideen bündelt und gemeinsam vorangeht.
Gruppen von Entwicklern ohne Teamgeist vergeuden ihre Energie mit „Beschäftigung“. Eine skalierte Gruppe, die kein Team ist, nutzt nur einen Bruchteil ihres Potentials zur Erreichung des gemeinsamen Ziels!
4. Transparenz
Viele Organisationen scheitern an mangelnder Kenntnis des Gesamtsystems. Sie können nicht global optimieren. Klassische Hindernisse der Transparenz gibt es auf allen Ebenen: Vom Entwickler, der nicht weiß, wie die Arbeit eines Kollegen ihn beeinflusst bis hin zum Manager, der nicht sagen kann, was die Absolute Prio 1 ist. Dieser Mangel an Transparenz führt zu vielen Problemen. Es fängt an mit dem Entwickler, der unbewusst die Arbeit seiner Kollegen torpediert und reicht bis zu ganzen Teams, die an den falschen Dingen arbeiten. Nichts davon ist wünschenswert und je häufiger so etwas passiert, desto kritischer und wichtiger ist es, die Transparenz zu steigern. Manche Organisationen vergeuden fast ihre gesamte Kapazität mit dem Management von Problemen, die durch mangelnde Transparenz verursacht wurden. In solchen Situationen ist „Abrackern“ wohl eine zutreffendere Beschreibung als „Skalierung“. Es gibt viele Hebel, um die Transparenz so weit zu steigern, dass Skalierung sinnvoll ist. Einige davon sind:
- Ein Kanban aufsetzen – das jeder sehen kann!
- Ein zentrales Backlog aus dem alle Teams sich bedienen
- Collective Code Ownership als Basis für „Kommunikation durch Code“
- Andons einsetzen: Build Monitoring und „Stop the Line“ basierend auf automatisierten Tests
- Gemeinsames Planning und gemeinsame Reviews, in denen nur das Integrierte Produkt gezeigt wird
Transparenz verhält sich antiproportional zu Overhead und Problemen. Oder anders gesagt: Bei agiler Skalierung verhält sich Transparenz proportional zum ROI. Agile Teams, denen die Transparenz fehlt, leisten keinen sinnvollen Beitrag zu den Unternehmenszielen.
5. Fokus
In vielen Organisationen ist eines der Hauptprobleme ein falscher Fokus auf Auslastung: Man verwaltet Arbeit und bringt den Mitarbeitern Aufgaben. Die Grundannahme hier ist, dass man Wert dadurch schafft, dass alle maximal „beschäftigt“ sind. In einer agilen Organisation ist das genau anders herum: Wir bringen die Menschen zu der Arbeit, die sich lohnt zu tun. Wir wissen, dass es keinen positiven Zusammenhang zwischen Wertschöpfung und Auslastung gibt. Wir konzentrieren uns darauf, ein nutzbares Produkt zu liefern – Dinge fertig zu bekommen. Ein klassisches Problem in vielen Organisationen ist, dass durch den Versuch, Mitarbeiter auszulasten, viele Dinge „in Arbeit“ sind: Dazu benötigt man Task-Switching und Koordination. Doch schon in trivialsten Szenarien führt der resultierende Verlust des Fokus zu massiv reduziertem ROI und signifikant steigenden Durchlaufzeiten: Wir verbringen zu viel Zeit damit, herauszufinden, warum nichts fertig wird – und zu wenig damit, etwas fertig zu bekommen. Die Hauptidee hinter Fokussierung ist: Es kostet deutlich weniger, das Falsche zuerst zu machen und danach das Richtige – als zwei Dinge gleichzeitig zu machen. So trivial das klingt, so schwer ist es umzusetzen: Die gesamte Organisation benötigt eine klar sortierte Liste von Zielen, und jedes Ziel muss eindeutig priorisiert sein. Es gibt exakt eine einzige Prio 1. Als Nächstes muss „Work in Progress“ strikt begrenzt sein. Fokus erfordert, dass Manager ihre Einstellung grundlegend überdenken: Man muss akzeptieren, dass „Leerlauf“ weniger kostet als Überlastung. Man kann auch nicht alles gleichzeitig bekommen. Unfokussierte Teams sind zwar „gut ausgelastet“, aber höchst ineffektiv. Je weniger fokussiert, desto länger benötigen sie, um Wert zu schaffen.
Die Fallen bei der Skalierung von Agilität
„Agile Skalierung“, die sich nicht um die vorgenannten Fallen sorgt, wird höchstwahrscheinlich ein Cargo-Kult. Nach außen hin sieht die Transition erfolgreich aus, doch nach innen herein bleiben die Vorzüge der Transition aus. Für erfolgreiche agile Transitionen ist ein üblicher Ansatz, erfahrene Experten an Bord zu bringen, die schon „an der Front gekämpft“ haben und die Fallen schon kennen.
Um die Fallen in einem skalierten Umfeld zu umschiffen, empfehlen wir:
Management-Unterstützung der Transition. Um die Fallen zu schließen, muss einiges in der Organisation auf den Kopf gestellt werden. Das benötigt uneingeschränkten Rückhalt vom Management.
Ein Agile Transition Team (ATT) aufbauen, in dem sowohl Manager als auch Entwickler sind. Das ATT hat ein klares Veränderungs-Backlog, an dem alle gemeinsam arbeiten.
Executive Coaching für die Schlüsselpersonen der Transition. Dazu gehören Linien-Manager genauso wie Product Owner und Scrum Master. Der externe Coach benötigt Erfahrung in agiler Skalierung!
Technisches Coaching hilft den Teams darin, schneller das passende Handwerkszeug zu bekommen: Das zahlt sich sehr schnell durch ein höherwertiges Produkt aus!
Einen Berater einstellen, um die Transition zu leiten. Diese Person muss genau wissen, was sie tut und muss kompromisslos arbeiten. Sie muss die Macht besitzen, auch unpopuläre Änderungen durchzusetzen.
Ausbildung für Alle bezüglich Agilität. In einer sicheren Trainingsumgebung lässt sich die Auswirkung der Transition deutlich leichter vermitteln.