Scrum oder Kanban - Studienanalyse und Praxiseinordnung mit Felix Huschka

Stephan Bellmann
2. Dez.
4 Min. Lesezeit

Aktualisiert: 5. Dez.

Felix Huschka ordnet die aktuellen Studien zu Scrum und Kanban ein und erklärt, warum echte Agilität immer kontextabhängig ist.

Interview

Zusammenfassung des Interviews

Im Interview diskutieren Stephan und Felix die Ergebnisse dreier wissenschaftlicher Studien zu Scrum und Kanban und vergleichen diese mit Felix’ praktischen Erfahrungen aus über 14 Jahren agiler Transformation. Zu Beginn kritisiert Felix, dass viele Organisationen Agilität nur oberflächlich übernehmen, indem sie klassische Wasserfallstrukturen beibehalten, aber mit agilen Begriffen überkleben. Echte Agilität bedeutet für ihn jedoch, Produkte und Organisationen so auszurichten, dass sie flexibel auf Marktveränderungen, Kundenerwartungen und technologische Entwicklungen reagieren können – und dafür reichen Labels oder Frameworks allein nicht aus.

Die Studien, die im Gespräch vorgestellt werden, kommen allesamt zu dem Ergebnis, dass Scrum und Kanban nicht generell vergleichbar sind, da ihre Wirksamkeit stark vom Einsatzkontext abhängt. Felix bestätigt diese Erkenntnis aus der Praxis und betont, dass es immer auf die Art der Arbeit, den Reifegrad des Teams und die Rahmenbedingungen ankommt. Besonders Kanban wird seiner Meinung nach oft falsch verstanden und unterschätzt. Obwohl es flexibel wirkt, ist die Einführung anspruchsvoll: Teams müssen Workflows, WIP-Limits und Rollen selbst gestalten, was häufig ein Coaching-Setup erfordert. Kanban entfaltet seinen größten Mehrwert in Umgebungen mit hoher Dynamik, kontinuierlichem Arbeitsfluss und reifen, selbstorganisierten Teams – etwa im Support oder in stabilen Produktteams.

Scrum hingegen ist deutlich populärer, was laut Felix vor allem daran liegt, dass es Organisationen mehr Orientierung bietet. Seine klaren Rollen, Events und Artefakte erleichtern gerade Firmen mit klassischer Prägung den Einstieg in agiles Arbeiten. Hinzu kommt ein starkes Schulungs- und Marketingumfeld, das Scrum in vielen Unternehmen zur Standardwahl macht. Allerdings führt diese Struktur nicht automatisch zu besserer Anwendung. Felix stellt heraus, dass viele Probleme, die in Studien als geringe Planungssicherheit beschrieben werden, nicht durch Scrum selbst entstehen, sondern durch falsche oder oberflächliche Umsetzung: Story Points werden oft zu Stunden umdefiniert, Velocity wird ignoriert, Backlogs sind nur teilweise geschätzt, und viele Teams planen lediglich Sprint für Sprint, ohne Roadmap oder vorausschauende Planung.

Ein weiterer Aspekt des Interviews ist die Betrachtung der Erfolgsquote agiler Projekte, die laut Status-Quo-Studie zwar weiterhin hoch ist, aber über die Jahre abnimmt. Felix führt das einerseits darauf zurück, dass heute mehr Projekte unter „agil“ laufen und dadurch realistischere Erfolgsquoten entstehen, und andererseits darauf, dass Agilität in Projekten eingesetzt wird, die davon gar nicht profitieren. Hinzu kommt, dass agile Arbeitsweisen oft früher sichtbar machen, wenn ein Projekt nicht funktioniert, was statistisch zu mehr „gescheiterten“ Projekten führt, während es für die Organisation eigentlich vorteilhaft ist, früher zu lernen und früher abzubrechen.

Ein zentrales Thema des Gesprächs ist außerdem die Frage, ob Organisationen sich an Frameworks anpassen müssen oder umgekehrt. Felix trennt klar zwischen Prinzipien und Methoden und betont, dass die agilen Prinzipien – etwa Kundennutzen, Feedback, Lernschleifen und Anpassungsfähigkeit – der eigentliche Kern sind. Frameworks wie Scrum oder Kanban sind Werkzeuge, die an Organisationen angepasst werden müssen, nicht dogmatische Systeme, denen Unternehmen sich zu 100 % unterwerfen sollten. Wer die Prinzipien verstanden hat, gestaltet seine Vorgehensmodelle so, dass sie zur Kultur, Produktlandschaft und Zielsetzung passen, statt starr an vorgegebenen Regeln festzuhalten.

Felix’ Antworten auf drei Abschlussfragen

1. Wozu Projektmanagement?

Struktur schafft Effizienz. Ohne Struktur wird Arbeit unkoordiniert – Projektmanagement schafft den Rahmen, der Zusammenarbeit ermöglicht.

2. Wo weichen Theorie und Praxis ab?

Überall. Problematisch wird es erst, wenn Theorie starr angewendet wird, ohne den Kontext zu berücksichtigen.

3. Warum scheitern Projekte?

Weil sie nicht konsequent auf Markt, Kundennutzen und Zielgruppe ausgerichtet sind – Organisationen starten Projekte, „weil man es immer so macht“, statt echten Bedarf zu prüfen.

Kernaussagen aus dem Interview

Agilität ist mehr als ein Label

Felix kritisiert „Label-Agilität“: Scrum, Kanban oder SAFe werden oft nur als Aufkleber auf klassische Projektplanung geklebt. Organisationen behalten starre Pläne und Rituale bei, nennen es „agil“ – ohne wirklich an Flexibilität, Marktanpassung und Reaktionsfähigkeit zu arbeiten. Echte Agilität heißt für ihn: schnell auf Veränderungen und Kundenbedürfnisse reagieren, nicht nur Frameworks einführen.

Scrum gibt Orientierung, Kanban verlangt Reife

Aus Felix’ Sicht wählen viele Firmen Scrum, weil es klare Rollen, Events und Artefakte bietet – das gibt Sicherheit und Struktur, gerade für Organisationen mit klassischer Prägung. Kanban dagegen ist flexibler, aber genau deshalb anspruchsvoller: Teams müssen ihren Flow, Rollen und Regeln selbst gestalten, was ohne Erfahrung und Coaching schnell überfordert. Kanban wirkt besonders stark in reifen, selbstorganisierten Teams mit kontinuierlicher Produkt- oder Supportarbeit.

Kanban wird in seiner Wirkung deutlich unterschätzt

Felix betont, dass Kanban oft auf ein simples Board reduziert wird („ein paar Spalten und Zettel“), während der eigentliche Hebel in Flow, WIP-Limits und kontinuierlicher Verbesserung liegt. Richtig eingesetzt ermöglicht Kanban einen extrem stabilen, wertschaffenden Fluss – vor allem in Produktweiterentwicklung und Operations. Er sieht in Kanban „viel mehr Power“, als in der Praxis meist genutzt wird.

Planungssicherheit scheitert an der Nutzung, nicht an Scrum

Dass in Studien Scrum eine geringe Planungssicherheit zugeschrieben wird, führt Felix vor allem auf Fehlanwendung zurück: Story Points werden zu Stunden umdefiniert, Velocity wird ignoriert, Backlogs sind kaum vollständig geschätzt und es wird oft nur von Sprint zu Sprint gedacht. Für ihn liegt das Problem nicht im Framework, sondern darin, dass Organisationen zwar Scrum-Begriffe verwenden, aber nicht konsequent planen und aus den Daten lernen.

Prinzipien zuerst – Methode an Organisation anpassen

Felix trennt klar zwischen Prinzipien und Methode: Wenn die agilen Prinzipien verinnerlicht sind, ist das konkrete Framework zweitrangig. Organisationen sollten die Prinzipien (Kundennutzen, Feedback, Anpassungsfähigkeit) verstehen und darauf basierend ihre eigene Ausprägung von Scrum oder Kanban gestalten (z.B. Sprintlänge, Skalierung, Rollenverständnis). Projekte scheitern aus seiner Sicht vor allem dann, wenn sie nicht klar auf Markt und Kunden ausgerichtet sind – nicht, weil das „falsche“ Framework gewählt wurde.