„Wir machen Scrum.“ Aber das Daily findet nur alle paar Tage statt, die Retrospektive fällt regelmäßig aus, und vom Sprintziel spricht niemand. Oder: „Wir machen Kanban“ – weil ein Board in Jira existiert.
Was für den Laien nett klingt, ist für andere ein Graus. Die Annahme ein Rahmenwerk auszuführen, auch wenn man nicht alles einhält oder zu glauben Kanban zu tun, weil man ein Board hat, ist üblicherweise eher ein Anzeichen von Unwissenheit als von Agilität.
01 · ÜberblickAgile Ansätze auf einen Blick
Scrum als Rahmenwerk gibt eben genau das vor, was notwendig ist zu tun, um sagen zu können „wir arbeiten nach Scrum“. Machst Du dein Scrum Daily nur alle zwei Tage – machst Du kein Scrum. So ist das mit Rahmenwerken.
Bei Kanban sieht die Welt anders aus. Kanban ist eine Management-Methodik aus dem Lean Management, welche viel Zustimmung in der agilen Welt widerfährt. Kanban startet mit dem was du hast, keine Vorgabe, kein Zwang. Kein Big Bang, sondern evolutionäre Verbesserung.
02 · AbgrenzungRahmenwerk oder Methode – das ist nicht dasselbe
Gibt vor, was du tun musst: Events, Verantwortlichkeiten, Artefakte. Lässt du Teile weg, arbeitest du nicht nach dem Rahmenwerk.
Überlässt dir mehr. Evolutionär, ohne harte Vorgaben. Leichter einzuführen, verlangt dafür Disziplin.
Ein Rahmenwerk wie Scrum, Nexus oder LeSS gibt dir einen Rahmen vor: Es definiert ziemlich klar, was du tun musst, damit es funktioniert – welche Events, welche Verantwortlichkeiten, welche Artefakte. Lässt du Teile weg, arbeitest du nicht nach dem Rahmenwerk. Sobald mehrere Teams an einem Produkt arbeiten, kommen Skalierungs-Rahmenwerke ins Spiel: Nexus ergänzt Scrum schlank um die Koordination weniger Teams und basiert dabei auf dem neusten Scrum Guide, während LeSS sich noch der Methodiken aus dem Scrum Guide von 2017 bedient und auf eine zentrale Organisationseinheit aus Nexus, dem NIT (Nexus Integration Team), gänzlich verzichtet.
LeSS und Nexus sind übrigens beide skalierende Rahmenwerk aus der Feder von Scrum. Bei mehr als drei Teams von jeweils bis zu 10 Menschen wird es schwierig eine effiziente Kommunikation und Produktentwicklung zu gewährleisten. Das Produkt wird immer komplexer, Abhängigkeiten steigen, Ziele überschneiden sich und Abstimmungen nehmen zu. LeSS und Nexus versuchen dem entgegenzuwirken erweitern dabei das Scrum Rahmenwerk lediglich.
Eine Methode wie Kanban überlässt dir mehr. Du musst nicht alle Kernpraktiken auf einmal umsetzen, um mit Kanban zu starten. Sie ist flexibler – evolutionär, ohne harte Vorgaben. Das macht sie leichter einzuführen, verlangt dir aber Disziplin ab, damit aus Flexibilität nicht Beliebigkeit wird. Kanban setzt auf wenige, dafür konsequente Praktiken: den Arbeitsfluss sichtbar machen, die Menge paralleler Arbeit begrenzen – die WIP-Limits – und den Engpass aktiv steuern. Du beginnst dort, wo ihr heute steht, und verbesserst Schritt für Schritt, statt alles auf einmal umzustellen.
03 · ScrumDas bekannteste agile Framework im Detail
Scrum definiert drei Verantwortlichkeiten, fünf Events und drei Artefakte wie Commitments und richtet sich üblicherweise an ein bis drei Teams.
Der Product Owner ist für Wertmaximierung des Produktes verantwortlich. Darunter fällt vom Stakeholder- und Anforderungsmanagement auch die Priorisierung, das Erarbeiten klarer Ziele und die Brücke bilden zwischen Scrum Team und Nutzern.
Einem Scrum Master wiederrum obliegt die Verantwortung das Leben und Handeln nach dem Scrum Guide, das Fördern von Selbstorganisation und prägen stetiger Verbesserung.
Die Developer sind für das regelmäßige Ausliefern von Inkrement verantwortlich, welche einen Mehrwert für den Endnutzer bringen sollen.
Der Sprint ist ein fester Zeitrahmen von meist zwei bis vier Wochen, in dem aus den wichtigsten Product-Backlog-Items, abseits von Scrum gerne in der Praxis als User Stories formuliert, ein fertiges Inkrement (Ergebnis) entsteht. Jeden Tag stimmt sich das Team im Daily Scrum ab, wie es um den Fortschritt zum Sprintziel steht. So bleibt das Scrum Team auf Kurs, und schafft Transparenz für sich über Ablauf und notwendigen Handlungsbedarf. Scrum wird am häufigsten in der Softwareentwicklung genutzt, aber auch im Ingenieurwesen bis hin zu HR-Prozessen schafft es Nutzen.
04 · KanbanKanban – evolutionäre Verbesserung dank Kaizen
Kanban hat seine Wurzeln im Lean Management und ist vor allem dank Toyota und den Erfolgen dort bekannt geworden. Anfang der 2000er Jahre wurde Kanban für die Wissensarbeit übersetzt – raus aus der Produktion, rein in den Büroalltag.
Viele verbinden Kanban mit dem Board und glauben: Board eingeführt, „wir arbeiten nach Kanban“. Kanban liefert eigene Werte, eigene Meetings (sogenannte Kadenzen), eigene Rollen und Methodiken, die sogenannten Kanban Kernpraktiken. Und trotzdem bleibt bei vielen nur das Board hängen.
Das Wichtigste an Kanban? Kleine Schritte, kein Big Bang. Kein Zwang irgendetwas einzuführen. Mit dem zu starten, wo man ist. Der beste Startpunkt ist vermutlich das Visualisieren, erst dies schafft Transparenz auf dessen Basis wir weiterarbeiten können. Die eigene Arbeit als zu visualisieren, mit Hilfe eines Boards, verbessert viele Prozesse und Abläufe bereits immens.
In Kanban versteht man Arbeit so, dass Arbeit fließen muss. Auf dem Board würde es bedeuten, dass deine Arbeit von links (der Quelle, wo Arbeit entsteht) nach rechts bis hin zur Senke (wo Arbeit fertiggestellt wird) fließt. Fließt Arbeit nicht, spricht Kanban von einem Engpass. In Kanban gilt: Engpassmanagement, dort wo es am schmerzhaftesten stockt, inspizieren und adaptieren wird, wir verbessern den Prozess. Wichtiger Hinweis: Engpassmanagement hat kein Ende und sollte als kontinuierlicher Prozess verstanden werden. Lösen wir einen Engpass, entsteht an anderer Stelle ein neuer.
Sehr spannend: Während Scrum mit seinen Sprints eure Zeit limitiert (bspw. durch einen vier Wochen Sprint) limitiert Kanban die Kapazität, die ihr leisten könnt. Dies passiert mit Hilfe von WIP-Limits, den Work in progress Limits. Wenn dein Board eure Arbeit visualisiert, bedeutet es, ihr habt den Prozess wie Arbeit fließt von links nach rechts in Spalten abgebildet. Für jede Spalte, also einem Teilprozess, bis Arbeit fertiggestellt ist, identifiziert ihr für euch ein Limit wie viel parallele Arbeit gleichzeitig bearbeitet werden kann. Ein elementarer Unterschied zu Scrum und wenn die GAC sich diesen Kommentar erlauben darf: Der bedeutendste Unterschied, der eindeutig für Kanban spricht.
05 · AuswahlUnd was passt nun zu mir?
Wer es agil machen möchte, wirklich agil, der sollte diese Frage aufschieben. Und klar, wer trotzdem sofort eine Entscheidung haben möchte, muss sich mit dem eigenen Kontext, den aktuellen Prozessen, dem Umfang, der Komplexität, der Größenordnung der Teams und des Produktes, der Timeline, den Erwartungen und der zur Zeit die zur Verfügung steht auseinandersetzen.
Scrum, LeSS, Nexus haben eines gemeinsam. Sie erfordern einen Big Bang. Kanban dagegen die evolutionäre Verbesserung – ggf. hilft das sogar schon bei der Entscheidung.
Viel wichtiger wären aber andere Fragen zu klären.
- Wie wollen wir mit unvorhergesehenen Änderungen umgehen?
- Warum möchten wir agil arbeiten?
- Was können wir ändern, was nicht und warum ist das so?
- Wie Veränderungsbereit sind wir – als Einzelner, als Team, als Organisation?
- Was macht unsere Kultur heute aus und worin unterscheidet sie sich zu dem, was im agilen Manifest als Leitplanken in Form von Werten und Prinzipien definiert wurde?
- Wie arbeiten mit Kunden, Stakeholdern und wie wollen wir zukünftig mit diesen arbeiten und warum wollen wir das so ändern?
- Wie gehen wir mit echter Transparenz um? Zeigen wir mit dem Finger auf den Schuldigen oder denken und arbeiten wir lösungsorientiert?
Agilität ist kein Selbstzweck.
Wer diese Fragen gemeinsam beantwortet, steigt völlig anders in die Frage der richtigen Methode ein. Der Weg dahin ist allerdings ein längerer, als sich einfach dem Gefühl oder Berater nach für eine Methodik zu entscheiden.
Pick dir eine der Fragen raus und teile deine Antwort!
Die Methode ist schnell gewählt. Die Haltung dahinter braucht Übung.
In der Guided Agile Community beantwortest du diese Fragen nicht allein, sondern über drei Monate an deinen echten Fällen. Begleitet, mit Feedback und Menschen, die denselben Weg gehen.
Gründer der Guided Agile Community (GAC), PSM III-zertifiziert und Dozent an der Universität Hildesheim. Stefan begleitet Praktiker:innen dabei, agiles Wissen iterativ und praxisnah im Berufsalltag zu verankern.
Mehr über Stefan auf LinkedIn