dot.tipp - Agilität im Alltag – Was tun, wenn das Ideal nicht passt?

5 Minuten Lesezeit

07. Mai 2025

9:19

Agile Frameworks liefern klare Empfehlungen – stabile Teams, planbare Sprints, cross-funktionale Ausprägung der Fähigkeiten. Doch was, wenn die Realität ganz anders aussieht? In diesem Beitrag zeigen wir vier echte Beispiele aus der Praxis, in denen das agile Ideal nicht erreichbar war – und was wir daraus gelernt haben.

Agilität bietet eine klare Vision: Teams sollen stabil, fokussiert, cross-funktional und autonom arbeiten. Doch in vielen Organisationen sind wir weit davon entfernt. Historisch gewachsene Strukturen, technische Schulden, Silodenken oder schlicht Personalmangel führen dazu, dass sich agile Arbeitsweisen nicht wie im Lehrbuch umsetzen lassen. Wie oft habt ihr schon gelesen oder gesehen resp. gehört, dass von Scrum-Like, SAFe-Like oder Kanban-Like Ansätzen gesprochen wurde. Immerhin wurde da erkannt, dass es nicht ganz dem Lehrbuch entspricht. Aber heisst das, dass man auf Agilität verzichten sollte? Ganz im Gegenteil: Wer agil arbeitet, muss gerade dann lernfähig und pragmatisch bleiben, wenn die Realität nicht zur Theorie passt.

Die grosse Frage ist dabei, worauf darf ich verzichten, wo soll ich ansetzen und wo liegen die Grenzen dieser pragmatischen Ansätze? Bei Scrum ist das relativ einfach. Die drei Säulen von Scrum, die auch ganz allgemein als die drei Säulen der Agilität betrachtet werden können, sind Transparenz, Inspektion und Adaption. Diese drei Säulen sind in den verschiedenen Rollen, Events und Konzepten integriert und so ist es zum Beispiel nicht sinnvoll, auf Retrospektiven zu verzichten, um nur ein Beispiel zu nennen. Wieso? Ohne die Transparenz, die mir eine gute Retrospektive bietet, kann ich keine Inspektion machen, was wir auf Prozessebene verbessern sollten und entsprechend ist auch keine Adaption des Vorgehens möglich. Das gleiche Denkkonstrukt gilt auch für den Review. Ohne Transparenz über den Produktfortschritt und die Qualität des Produktinkrements, kann es keine Inspektion und entsprechend auch keine Adaption geben. Ihr erkennt das Muster. Das spannende ist, dass sowohl Scrum mit Fokus auf Produktentwicklung, als auch Kanban mit Fokus auf Prozess- und Workflow-Optimierung in ihrer Essenz so rudimentär sind, dass es eine gute Faustregel ist, weder Scrum noch Kanban noch weiter zu reduzieren.

Wenn ein Framework bereits minimalistisch ist, dann ist jeder weitere Abbau kein pragmatischer Kompromiss mehr – sondern eine strukturelle Schwächung.

Gleichzeitig erleben wir in solchen Veränderungssituationen häufig eine psychologische Dynamik, die den Wandel zusätzlich erschwert. Die Angst vor Veränderung, Unsicherheit über die Auswirkungen und die Hoffnung, das bestehende System "noch irgendwie" zu stabilisieren, führen oft dazu, dass Organisationen im ersten Impuls lieber am Problem arbeiten, statt das System zu hinterfragen. Die Herausforderung liegt darin, eine fundierte Analyse aufzuzeigen, ohne vorschnell zu bewerten oder zu überfordern. Gerade in diesen Situationen kommt es darauf an, strategisch, taktisch und operativ abgestimmt zu handeln.

Vier Realitäten, vier Lernfelder – und viele Zwischentöne

1. Wenn Scrum nicht zum Arbeitsfluss passt

In einem Team führte der hohe Anteil an Wartungs- und Pflegeaufgaben dazu, dass die Sprintplanung systematisch scheiterte. Die Aufgaben liessen sich nicht sinnvoll in kleine, planbare Einheiten zerlegen, ohne dabei die Natur der Tätigkeit zu verzerren. Der Frust im Team wuchs, ebenso wie die Zweifel an der Methode. Das Planning wurde nicht mehr ernst genommen, die Retrospektiven scheiterten am Denkmodell, dass Scrum die einzig richtige Lösung ist und an den Reviews konnten bloss die erledigten Aufgaben, aber keine echten Lösungen oder gar Produktinkremente gezeigt werden.

Die Lösung kam nicht aus dem Scrum-Handbuch, sondern aus einer vertieften Reflexion mit einer externen Brille: Der Wechsel auf Kanban mit klaren Prozessdefinitionen ermöglichte wieder Transparenz und Steuerbarkeit. Das Beispiel zeigt: Agilität ist kein Dogma. Es geht nicht darum, an einem Framework festzuhalten, sondern ein passendes Modell für die gelebte Realität zu finden.

2. Wenn das Team gar kein Team ist

Ein klassisches SAFe-Setup mit fünf Teams, das auf den ersten Blick agil wirkte. Doch die Analyse zeigte: Die Teams waren entlang disziplinärer Linien geschnitten – Testing, Integration, Framework, Bugfixing. Zusammenarbeit? Fehlanzeige. Jeder arbeitete in seinem Segment, Übergaben dominierten den Alltag. Die erste Lösungsvariante des Kunden war, das Bugfixing Team dynamisch zu gestalten. Also in gewissen Zyklen jeweils neu zusammen zustellen. Die Analyse der Hintergründe zeigte, dass so eine vermeintlich höhere Performance der Development Teams erreicht wurde, da diese nicht mehr für ihre Bugs verantwortlich waren. Über längere Zeit hat sich so der Workload unverhältnismässig in das Bugfixing Team verschoben.

Zwei Varianten standen im Raum: das Vorgehensmodell an die Realität anpassen – oder die Realität so verändern, dass ein agiles Vorgehen überhaupt möglich wird. Letzteres bedeutet in der Regel: Teams entlang der Wertschöpfung neu schneiden. Der Mut zur strukturellen Veränderung ist oft der Engpass – nicht das Wissen um bessere Alternativen.

3. Wenn niemand wirklich Teil des Teams ist

In einem grossen Projekt mit hoher Sichtbarkeit wurde ein Scrum-Team mit 20 Personen aufgestellt. Die Hoffnung: breite Perspektive, grosse Schlagkraft. Die Realität: kaum Fortschritt, keine Verantwortung, chronische Konzeptphase. Die Analyse zeigte: Viele Teammitglieder waren nur zu 10 % im Projekt engagiert – de facto Zuschauer.

Der Turnaround kam durch Klarheit: Die Rolle von Stakeholdern wurde klar von der Rolle des Teams getrennt. Das Team wurde auf fünf Personen reduziert – alle mit mindestens 80 % Commitment. Externe Expertise wurde temporär eingebunden, mit dem klaren Ziel, internes Know-how aufzubauen. Erst dann konnte Scrum wirklich greifen. Fokus schlägt Breite – und Verfügbarkeit ist keine Nebensache.

4. Wenn Support und Innovation im selben System stecken

Fünf Teams arbeiteten am gleichen Produkt. Doch nur eines davon entwickelte wirklich weiter – die anderen vier waren mit Wartung, Pflege und Support ausgelastet. Das Management sah das Problem in der fehlenden Priorisierung durch die POs. Erst nach sechs Monaten wagte man sich an die Grundsatzfrage: Ist die Teamstruktur überhaupt sinnvoll? Die tiefergehende Analyse brachte ein komplexes Bild zum Vorschein: eine überladene Architektur, komplizierte Reproduzierbarkeit von Kundenproblemen und hohe personelle Fluktuation. Erst als klar war, dass es nicht nur um Planung, sondern um systemische Entflechtung ging, konnte ein Veränderungsprozess angestossen werden. Die Umstellung auf cross-funktionale Teams, gemeinsame Rituale und neue Rollen war nicht nur ein organisatorischer Schritt, sondern auch ein kultureller. Veränderung beginnt mit dem Mut, das eigentliche Problem anzusprechen – und sich Zeit für den Umbau zu nehmen.

Wenn Veränderung zur Zumutung wird

Alle vier Beispiele zeigen: Die Hindernisse waren nicht primär methodisch, sondern strukturell, kulturell und oft auch emotional. Das agile Ideal war nicht erreichbar – nicht sofort und nicht vollständig. Doch es wurde auch nicht als Ausrede genutzt. Stattdessen brauchte es den Mut, das Unangenehme auszusprechen, die Geduld, Systeme zu durchdringen, und die Fähigkeit, Zwischenlösungen zu gestalten, die einen nächsten Schritt ermöglichen.

Veränderung ist nicht linear. Sie bewegt sich auf mehreren Ebenen gleichzeitig:

Strategisch, wenn es um Zielbilder, Grundhaltungen und Organisationsdesign geht.
Taktisch, wenn es um Rituale, Prozesse und Zusammenarbeit geht.
Operativ, wenn es um konkrete Rollen, Tools und Backlog-Strukturen geht.

Gelingt es, diese Ebenen miteinander zu verbinden, entsteht eine Veränderung, die nicht von aussen gesteuert, sondern von innen getragen wird. Genau hier liegt der Hebel der agilen Arbeitsweise – nicht im perfekten Framework, sondern im reflektierten Umgang mit Imperfektion. Wer uns kennt, weiss, hier setzen wir mit unserem Abstraktionsmodell-Ansatz an, in dem wir zunächst ein gemeinsames Verständnis über die Zusammenhänge von Rollen, Events, Planungs- und Dokumentationsartefakte erarbeiten und basierend darauf festlegen, wie wir am besten zusammenarbeiten.

Agil sein heisst nicht, perfekt zu sein

Es gibt kein „agiles Reifegrad-Label“, das nur bei Idealerfüllung vergeben wird. Agilität beginnt dort, wo wir ehrlich auf unsere Realität blicken und uns fragen: Was ist jetzt der nächste sinnvolle Schritt? Wer diesen Weg geht, muss sich nicht für unperfekte Zustände rechtfertigen – sondern kann sie nutzen, um echte Veränderung möglich zu machen.

Die vier Beispiele zeigen: Wenn wir den Mut haben, über Symptome hinauszusehen, finden wir Ansätze, die tragen – nicht sofort, aber über Zeit. Und vielleicht ist genau das der ehrlichste Ausdruck von Agilität: Nicht die Antwort zu kennen, sondern den nächsten Schritt gemeinsam herauszufinden.