Über Scrum hinaus: eine vollständige Agile-Praxis aufbauen

Das Scrum-Plateau

Die meisten Teams erleben in den ersten sechs Monaten mit Scrum eine rasche Verbesserung. Die Transparenz nimmt zu, das Feedback der Stakeholder kommt früher und die Lieferung wird berechenbarer. Dann stockt der Fortschritt. Die Velocity stabilisiert sich, technische Schulden häufen sich leise an und Retrospektiven recyceln dieselben Massnahmen. Dieses Plateau ist kein Ausführungsfehler. Es ist die natürliche Grenze dessen, was ein einzelnes Framework leisten kann.

Scrum bietet Struktur für Planung, Zusammenarbeit und Inspektion. Es vermeidet bewusst, technische Praktiken, Organisationsdesign und strategische Governance vorzuschreiben. Das Framework geht davon aus, dass Teams diese Lücken durch empirisches Experimentieren füllen. In der Praxis wissen viele Teams nicht, womit sie experimentieren sollen. Sie haben Scrum gelernt. Sie haben noch nicht Agile gelernt.

Technische Praktiken, die Velocity erhalten

Die erste Lücke, die Teams bemerken, liegt in ihrer Codebasis. Alle zwei Wochen ein funktionsfähiges Inkrement zu liefern, erfordert eine Disziplin, die Scrum nicht lehrt. Test-Driven Development erstellt eine ausführbare Spezifikation, die Regressionen erkennt, bevor sie die Tester erreichen. Continuous Integration stellt sicher, dass jede Code-Änderung innerhalb von Minuten gegen das gesamte System validiert wird. Refactoring hält die Architektur reaktionsfähig gegenüber sich ändernden Anforderungen, anstatt sie um frühe Designentscheidungen herum erstarren zu lassen.

Diese Praktiken stammen aus dem Extreme Programming. Kent Beck entwarf XP als vollständige Entwicklungsdisziplin; Scrum übernahm die Projektmanagement-Ebene und liess die technische Ebene zurück. Teams, die beides einführen, entdecken, dass die Kombination grösser ist als jeder einzelne Teil. Scrum liefert den Rhythmus und XP liefert die technische Strenge, die diesen Rhythmus nachhaltig macht.

Wie Kanban das Flussbild vervollständigt

Scrum misst Fortschritt in Sprints. Arbeit ist entweder erledigt oder nicht erledigt an der Sprint-Grenze. Diese binäre Sicht verbirgt wichtige Informationen darüber, wie Arbeit tatsächlich durch das System fliesst. Eine User Story, die drei Tage in der Code-Review liegt, dann zwei weitere Tage auf Tests wartet und dann eine Design-Überarbeitung benötigt, sieht identisch aus wie eine Story, die reibungslos von der Entwicklung bis zum Deployment an einem einzigen Tag fliesst. Beide sind am Sprint-Ende „fertig“.

Kanban behebt diesen blinden Fleck. Explizite Work-in-Progress-Limits verhindern die Anhäufung teilweise fertiger Arbeit. Cycle-Time-Tracking zeigt, wo Verzögerungen tatsächlich auftreten. Ein Team, das beginnt, den Fluss zu messen, entdeckt oft, dass eine Story, die fünf Tage „in Bearbeitung“ verbringt, tatsächlich zwei Tage Entwicklung und drei Tage Warten umfasst. Diese Erkenntnis allein kann die Lieferzeit erheblich verkürzen.

Die Kombination funktioniert, weil Scrum und Kanban unterschiedliche Probleme lösen. Scrum beantwortet „Woran sollen wir als Nächstes arbeiten?“ Kanban beantwortet „Wie effizient fliesst Arbeit durch unser System?“ Teams, die beides nutzen, treffen bessere Entscheidungen über Priorität und Prozess.

Organisatorische Agilität ist nicht Team-Agilität

Eine häufige Frustration bei Scrum-Einführungen ist die Diskrepanz zwischen Agilität auf Teamebene und organisatorischer Starrheit. Teams führen Sprints durch, warten aber drei Wochen auf die Bereitstellung von Umgebungen. Sie setzen auf iterative Lieferung, releasen aber über ein vierteljährliches Change Advisory Board. Sie identifizieren Impediments in Retrospektiven, haben aber nicht die Befugnis, Beschaffungsprozesse oder Einstellungsverfahren zu ändern.

Lean-Denken erweitert die kontinuierliche Verbesserung über die Teamgrenze hinaus. Value Stream Mapping zeigt die End-to-End-Lieferperformance, einschliesslich der Übergaben und Wartezeiten, die Scrum-Teams nie sehen. Organisatorische Verbesserungsinitiativen, besetzt mit Personen mit abteilungsübergreifender Autorität, können die systemischen Engpässe angehen, die einzelne Teams nicht lösen können.

Hier wird das Engagement des Managements konkret statt zeremoniell. Scrum zu unterstützen bedeutet mehr als Schulungen zu finanzieren. Es bedeutet, Genehmigungsprozesse umzustrukturieren, in gemeinsame Infrastruktur zu investieren und dedizierte Verbesserungskapazität auf Organisationsebene zu schaffen.

Was Multi-Team-Koordination wirklich erfordert

Die Skalierung von Scrum ist der Bereich, in dem der Minimalismus des Frameworks am deutlichsten wird. Der Scrum Guide beschreibt ein einzelnes Team. Wenn fünf Teams am selben Produkt arbeiten, muss jede Annahme über Backlog-Ownership, Sprint-Grenzen und Definition of Done überdacht werden. Abhängigkeiten zwischen Teams führen zu einer Planungskomplexität, für die Sprint Planning nie konzipiert wurde.

Praktische Lösungen reichen von Feature Teams, die Abhängigkeiten minimieren, indem sie vollständige vertikale Schnitte besitzen, bis hin zu expliziten Koordinationsevents wie teamübergreifenden Refinement-Sessions. Manche Organisationen experimentieren mit Squad-basierten Modellen, die Alignment-Mechanismen über Chapters und Guilds hinzufügen. Diese Muster ergänzen Scrums Teamebenen-Struktur, wobei jede Organisation sie an ihren eigenen Kontext anpassen muss.

Das Reifemuster

Teams, die über das Scrum-Plateau hinausgehen, folgen einem erkennbaren Muster. Sie beginnen mit dem Framework wie vorgeschrieben. Sie fügen XP-Engineering-Praktiken hinzu, um die Codequalität zu schützen. Sie übernehmen Kanban-Flussmetriken, um die Prozesseffizienz zu verbessern. Sie treiben organisatorische Veränderungen voran, die systemische Impediments beseitigen. In jeder Phase behalten sie, was funktioniert, und verwerfen, was nicht funktioniert. Das Framework wird zu einem Fundament statt einer Decke, und „Scrum machen“ entwickelt sich zu einer breiteren, kontextspezifischen Agile-Praxis, die dem Team dient, anstatt es einzuschränken.