Die drei echten Optionen

Scrum funktioniert am besten, wenn Ihr Team Features in einem vorhersehbaren Rhythmus ausliefert. Zweiwöchige Sprints erzwingen alle vierzehn Tage ein Planungsgespräch, eine Demo, die Fortschritt sichtbar macht, und eine Retrospektive, die Reibungspunkte aufdeckt, bevor sie sich verfestigen. Sie erhalten definierte Rollen — einen Product Owner, der das Backlog bewacht, einen Scrum Master, der den Prozess bewacht, und Entwickler, die das Commitment bewachen.

Die Struktur ist der Punkt. Produktteams, die auf vierteljährliche Ziele hinarbeiten, brauchen den Rhythmus von „wir haben diese acht Tickets geplant, wir haben sieben abgeschlossen, hier ist der Grund". Stakeholder erhalten Prognosen, die auf historischer Velocity basieren, statt auf optimistischen Vermutungen. Entwickler erhalten die Erlaubnis, „das ist nicht in diesem Sprint" zu sagen, ohne einen politischen Kampf.

Scrums Kosten sind Starrheit. Änderungen des Umfangs während des Sprints sind teuer. Zeremonien nehmen echte Kalenderzeit in Anspruch — ein Team von sechs Personen wird 4–6 Stunden pro Sprint in Ritualen verbringen. Wenn Ihre Arbeit unterbrechungsgetrieben ist oder sich Ihre Prioritäten täglich ändern, wird diese Starrheit zu Ballast statt zu Hebelwirkung.

Kanban optimiert den Durchsatz in Umgebungen, in denen die Arbeit nicht auf Ihre Sprint-Grenze wartet. Ein um 14 Uhr eskaliertes Support-Ticket kümmert sich nicht darum, dass Ihre Sprint-Planung erst am Donnerstag stattfindet. Kanban sagt: Visualisieren Sie die Arbeit, begrenzen Sie, wie viel gleichzeitig in Bearbeitung ist, und ziehen Sie das nächste Element mit der höchsten Priorität, wenn Kapazität frei wird.

Das Board ist das System. Spalten repräsentieren Phasen (To Do, In Bearbeitung, Review, Fertig), und WIP-Limits begrenzen, wie viele Tickets gleichzeitig in einer Spalte liegen können. Ein 3-Personen-Team mit einem WIP-Limit von 4 bei „In Bearbeitung" kann keine neue Arbeit beginnen, bis etwas vorankommt. Diese Einschränkung macht Kanban zu mehr als einer Aufgabenliste — sie zwingt das Team, abzuschließen, bevor es beginnt.

Kanban passt zu Operations-Teams, Plattform-Teams und jeder Gruppe, deren eingehende Arbeit zeitlich unvorhersehbar, aber relativ einheitlich in der Größe ist. Es funktioniert auch gut als Zwischenschritt — Teams, die sich bei Scrum unsicher sind, können einen Monat lang Kanban betreiben, um Flow-Gewohnheiten aufzubauen, bevor sie Sprints hinzufügen.

Nicht jedes Team braucht gerade jetzt eine Methodik. Ein 3-Personen-Team, das im selben Raum sitzt, ein Produkt ausliefert, mit einem kurzen Backlog und täglicher Kommunikation — dieses Team hat bereits Feedbackschleifen. Sprint-Zeremonien oder Kanban-Boards obendrauf zu legen, schafft keinen Wert; es schafft Overhead um des Overheads willen.

Die Grundlagen aus diesem Kurs — Disziplin bei der Versionsverwaltung, aussagekräftige Tickets, grundlegende Schätzung und ein gemeinsames Verständnis davon, was „fertig" bedeutet — reichen aus, um gut auszuliefern für Teams, bei denen die Koordinationskosten niedrig sind. Das Signal, dass Sie mehr Struktur brauchen, ist nicht „wir haben über Scrum gelesen und es klingt professionell". Es ist konkreter Schmerz: verpasste Übergaben, chronische Überraschungen zur Demo-Zeit, Arbeit, die untätig liegt, weil niemand wusste, dass sie blockiert war, oder neue Teammitglieder, die ohne eine Woche Einarbeitung nicht hochfahren können.

Wenn diese Probleme nicht auftreten, bleiben Sie hier. Überdenken Sie diese Entscheidung in drei Monaten oder wenn das Team über fünf Personen hinauswächst.