Der Satz 'wir machen Agile' ist das, was ich am häufigsten von Kunden höre, die in Wirklichkeit tägliche Meetings ohne echte Veränderung in der Arbeitsweise abhalten. Agile ist eine Philosophie, keine Methode. Scrum und Kanban sind konkrete Methoden, die diese Philosophie auf sehr unterschiedliche Weise umsetzen. Sie zu verwechseln kostet Zeit, Geld und Glaubwürdigkeit im Projektteam.
1. Agile: der mentale Rahmen, nicht der Prozess. Agile ist die Sammlung von Werten und Prinzipien des Agile Manifests (2001): Menschen vor Prozessen, funktionierende Software vor umfassender Dokumentation, Kundenzusammenarbeit vor Vertragsverhandlung, Reagieren auf Veränderung vor dem Befolgen eines starren Plans. Es sagt nicht, wie man Sprints organisiert, wer was tut oder wie man Fortschritt misst. Deshalb ist Agile-Machen ohne Wahl einer konkreten Methode fast immer organisatorisches Theater.
2. Scrum: wenn die Arbeit vorhersehbar und iterativ ist. Scrum funktioniert, wenn man Arbeitsblöcke (Sprints von 1-4 Wochen) mit klarem Ziel und priorisierbarem Backlog planen kann. Es ist der richtige Rahmen für Produktentwicklung, stabile Teams mit definierten Rollen (Product Owner, Scrum Master, Development Team) und Kontexte, in denen der Kunde regelmäßig Feedback geben kann. Scrum erfordert Rollendisziplin: Wenn der Product Owner keine echte Entscheidungsautorität hat oder der Scrum Master auch als klassischer PM agiert, kollabiert der Rahmen schnell.
3. Kanban: wenn Fluss wichtiger ist als Plan. Kanban funktioniert, wenn Arbeit kontinuierlich und unvorhersehbar eintrifft: Kundensupport, Operations, Wartungsteams oder Multi-Projekt-Kontexte mit häufig wechselnden Prioritäten. Keine Sprints: kontinuierlicher Fluss mit Work-in-Progress-Limits (WIP) pro Spalte. Die Schlüsselmetrik ist nicht Velocity, sondern Lead Time (wie lange eine Aufgabe vom Eingang bis zum Ausgang braucht).
4. Entscheidung in 3 Fragen. Kommt die Arbeit in planbaren Wellen oder kontinuierlich und unvorhersehbar? Wellen bedeutet Scrum. Kontinuierlich bedeutet Kanban. Kann sich das Team 1-4 Wochen auf ein gemeinsames Ziel konzentrieren? Ja bedeutet Scrum. Nein bedeutet Kanban. Braucht es einen tiefen kulturellen Wandel in Rollen oder nur Sichtbarkeit und Flusskontrolle? Tiefer Wandel bedeutet Scrum. Sichtbarkeit bedeutet Kanban.
5. Das Hybridmodell, das in der Praxis funktioniert. Viele reife Teams nutzen Scrumban: Sprint-Struktur von Scrum für die Planung, Kanban-Board mit WIP-Limits für die tägliche Flusssteuerung. Es ist der Ansatz, den ich am häufigsten Organisationen mit gemischten Teams (Entwicklung + Support) empfehle, weil er nicht das gesamte Unternehmen in einen einzigen starren Rahmen zwingt.
FAQ. Kann man mitten im Projekt von Scrum zu Kanban wechseln? Ja, und es ist häufiger als gedacht: Signal ist, wenn Sprints ständig durch dringende externe Anfragen unterbrochen werden. Braucht es eine Zertifizierung (PSM, CSM), um diese Rahmen anzuwenden? Die Zertifizierung hilft bei gemeinsamer Sprache und Glaubwürdigkeit gegenüber Stakeholdern, ersetzt aber nicht die praktische Anpassungserfahrung an den spezifischen Kontext.
Wenn Ihr Team sagt, es mache Agile, aber Sie das Gefühl haben, dass etwas nicht stimmt, sprechen wir darüber: In einem 30-Minuten-Gespräch helfe ich Ihnen zu verstehen, welcher Rahmen wirklich zu Ihrem Kontext passt — ohne Ihnen eine vorgefertigte Methodologie zu verkaufen.
