Ein Entscheidungsrahmen

Teams, die die Arbeit der nächsten Woche heute beschreiben können, sind Scrum-Kandidaten. Teams, die die Arbeit von morgen heute nicht beschreiben können, sind Kanban-Kandidaten.

Bewerte dich selbst auf einer Skala von 1–5: 1 bedeutet „wir haben eine priorisierte Roadmap und die meisten Sprints verlaufen ungefähr nach Plan." 5 bedeutet „die Hälfte unserer Arbeit kommt ungeplant – Vorfälle, Kundeneskalationen, Ad-hoc-Anfragen von anderen Teams." Die meisten Produktfeature-Teams landen bei 1–2. Die meisten Plattform-, DevOps- und Support-Teams landen bei 4–5. Teams bei 3 sind wirklich mehrdeutig – und „Scrumban" (Scrum-Rhythmus mit Kanban-Pull für ungeplante Arbeit) ist eine vernünftige Antwort für sie.

Die zentrale Erkenntnis: Vorhersehbarkeit hat nichts mit Disziplin zu tun. Ein Team kann extrem diszipliniert sein und trotzdem unvorhersehbare Arbeit haben, weil die Domäne es erfordert. Verwechsle nicht „wir können nicht vorhersagen" mit „wir planen nicht".

Der Sprint von Scrum ist eine Zeitbox-Verpflichtung: Das Team verpflichtet sich, einen festen Zeitraum vor Scope-Änderungen zu schützen. Das funktioniert nur, wenn die Organisation die Grenze tatsächlich respektiert.

Stelle zwei Fragen: Kann dein Product Owner zu einem VP „nein, das wartet bis zum nächsten Sprint" sagen, ohne überstimmt zu werden? Und kann das Team realistischerweise an Planning, Standup, Review und Retro in jedem Zyklus teilnehmen, ohne dass diese Zeremonien für „etwas Dringenderes" abgesagt werden? Wenn beide Antworten ja sind, kannst du Scrums Rhythmus aufrechterhalten. Wenn eine davon nein ist, werden Sprints in kontinuierlichen Flow mit zusätzlichen Meetings kollabieren – das Schlechteste aus beiden Welten.

Kanban erfordert keine Rhythmus-Verpflichtung. Du kannst trotzdem regelmäßige Retrospektiven und Planungssitzungen abhalten, aber nichts bricht zusammen, wenn du eine auslässt oder um ein paar Tage verschiebst. Für Teams in Organisationen, die routinemäßig Pläne überschreiben, ist Kanbans Fehlen einer Sprint-Grenze Ehrlichkeit, nicht Schlamperei.

Struktur ist ein Gerüst – sie kompensiert, was das Team noch nicht als Muskelgedächtnis aufgebaut hat. Ein Team von sechs Entwicklern, die seit zwei Jahren zusammenarbeiten, braucht vielleicht keine formale Definition von „ready", weil sie es verinnerlicht haben. Ein Team, das sich letzten Monat gebildet hat, schon.

Konkrete Signale, die auf mehr Struktur hinweisen (Scrum):

• Mehr als zwei Entwickler sind im letzten Quartal dazugekommen
• Das Team hat keine gemeinsame Historie, was „done" bedeutet
• Arbeit wird regelmäßig ohne klare Akzeptanzkriterien begonnen
• Retrospektiven zeigen wiederholte Fehlkommunikation

Signale, die auf weniger Struktur hinweisen (Kanban oder nur Grundlagen):

• Das Team hat stabile Mitgliedschaft und gemeinsamen Kontext
• Entwickler organisieren sich effektiv selbst ohne Rollenzuweisungen
• Arbeitselemente sind gut verstanden und relativ einheitlich
• Das Hauptkoordinationsproblem ist Durchsatz, nicht Ausrichtung

Neue Teams profitieren fast immer davon, mit mehr Struktur zu beginnen und sie zu lockern, wenn Vertrauen aufgebaut wird. Das Gegenteil – einem Team, das bereits kämpft, Struktur hinzuzufügen – fühlt sich strafend an und erzeugt Unmut.

Scrum ist ein Alles-oder-Nichts-Framework von Grund auf. Du kannst keinen „halben Sprint" durchführen – entweder verpflichtest du dich zur Zeitbox und den Zeremonien, oder du hast kein Scrum. Es zu übernehmen bedeutet, die Art und Weise zu ändern, wie das Team plant, reviewt und reflektiert – in einem Schritt. Das ist eine Big-Bang-Transition, und sie funktioniert am besten, wenn das Team überzeugt ist und ein Scrum Master (oder Äquivalent) bereit ist, durch die ersten rauen Sprints zu coachen.

Kanban ist von Natur aus inkrementell. Du beginnst damit, deinen aktuellen Workflow auf einem Board zu visualisieren – noch keine Prozessänderung erforderlich. Dann fügst du WIP-Limits hinzu. Dann beginnst du, Cycle Time zu messen. Jeder Schritt bringt unabhängig Wert. Wenn ein Schritt nicht funktioniert, entfernst du ihn, ohne alles andere rückgängig zu machen.

Für Teams, die Prozessänderungen skeptisch gegenüberstehen oder von vergangenen Methodik-Einführungen verbrannt sind, ist Kanbans inkrementeller Pfad risikoärmer. Du beweist Wert bei jedem Schritt, bevor du dich weiter verpflichtest. Scrums Big-Bang-Ansatz ist schneller zur vollständigen Einführung, hat aber eine höhere Fehlerrate bei Teams, die nicht bereit für die Verpflichtung sind.

Die falsche Methodik ist behebbar – aber die Behebungskosten variieren. Ein Team, das Scrum für zwei Sprints ausprobiert und entscheidet, dass es nicht passt, hat einen Monat Anpassung und etwas Goodwill verloren. Ein Team, das sich um SAFe herum reorganisiert und Enterprise-Tooling kauft, hat einen viel schwierigeren Umkehrpfad.

Bewerte deine Wechselkosten ehrlich: Wie viele Personen müssen ihre täglichen Gewohnheiten ändern? Kaufst du Tools oder machst du Organigramm-Änderungen, um die Methodik zu unterstützen? Werden externe Stakeholder umgeschult, wie sie mit dem Team interagieren? Je mehr Berührungspunkte, desto höher die Kosten, falsch zu liegen – und desto stärker das Argument, mit der einfacheren Option zu beginnen.

Für die meisten Teams, die ihre erste Methodik-Wahl treffen, lautet die Antwort: Beginne mit Kanban (geringe Verpflichtung, leicht umkehrbar) oder Scrum (moderate Verpflichtung, in einem Sprint umkehrbar). Beginne nicht mit einem Skalierungs-Framework. Beginne nicht mit etwas, das teamübergreifende Koordination erfordert, die du noch nicht hast. Passe das Gewicht der Methodik an das Gewicht der Entscheidung an.