Was sind Scrum und Kanban eigentlich?

👋 Schön, dass Du hier bist! Bitte beachte, dass dieser Artikel bereits einige Jahre auf seinem Buckel hat. Seitdem haben sich nicht nur die Welt, sondern auch meine WissenslĂŒcken, Erfahrungen und Ansichten geĂ€ndert. Dennoch stehe ich hinter den Aussagen, die ich damals getĂ€tigt habe. Selbst dann, wenn ich sie mittlerweile anders tĂ€tigen wĂŒrde. Bitte behalte dies beim Lesen im Hinterkopf. Danke. Und viel VergnĂŒgen!

Wovon reden da alle? Was ist das? Und haben die beiden wirklich so viel gemeinsam?

Scrum und Kanban

Scrum und Kanban - wovon reden denn da alle? #

Seit einigen Jahren hört man immer öfter von Scrum und Kanban. Und mittlerweile sind die beiden Begriffe auch außerhalb der IT und außerhalb des Projektmanagements ein Begriff geworden. Aber so wirklich erklĂ€ren, was das eigentlich ist, kann einem kaum jemand. Beziehungsweise, was ist der Unterschied zwischen Scrum und Kanban? Gibt es da ĂŒberhaupt einen? Und wofĂŒr ist das alles eigentlich gut? KlĂ€ren wir die einfachsten zwei Fragen zuerst.

Scrum und Kanban - gibt es da ĂŒberhaupt einen Unterschied? Und wenn ja, welchen? #

Ja, den Unterschied gibt es. Einen ganz gewaltigen sogar. Das eine (Scrum) ist eine Methodik fĂŒr Projektmanagement in der Softwareentwicklung auf Teamebene. Das andere (Kanban) ist eine Planungsmethode der Produktionsprozesssteuerung. Klingt furchtbar kompliziert, ich weiß. Lasst es uns vereinfachen: Scrum ist Projektmanagement, Kanban ist Prozessmanagement. Das eine verwende ich, um etwas zu verĂ€ndern, das andere, um bestehende Prozesse abzuwickeln.

Kann ich Scrum und Kanban dann ĂŒberhaupt miteinander vergleichen? #

Wie so oft im Leben ist die Antwort ein jein. Ja, ich kann einen Vergleich herstellen, aber der wird immer ein sehr kĂŒnstlicher sein. Scrum und Kanban einander gegenĂŒber zu stellen, ist wie wenn ich Kochen und BĂŒgeln miteinander vergleichen möchte. Beides sind TĂ€tigkeiten und beides hat was mit Haushalt zu tun. Aber das war es dann auch schon. Wenn Euer AgilitĂ€ts-Coach also Scrum und Kanban fröhlich miteinander vermischt, wĂŒrde ich das an Eurer Stelle eher mit Vorsicht genießen. Ja, es gibt Methodiken, die Kanban als Projektmanagementtool verwenden (Scrumban, zum Beispiel). Das funktioniert, weil Projektmanagement in gewissen Sinne eine Unterkategorie des Prozessmanagements ist. Und Scrum und Kanban sind beide mehr oder weniger agil (mehr dazu im nĂ€chsten Absatz). Aber im Grunde genommen, reden wir hier von zwei verschiedenen Welten.

A propos AgilitÀt: sind Scrum und Kanban denn nicht agil? #

Und schon wieder: jein. Lasst uns das mal konkreter ansehen. Es gibt mehrere Definitionen von AgilitĂ€t. Aber wenn wir rein nach der Lehre gehen, ist Kanban nicht agil. Ich weiß, ĂŒberall steht, dass es das sei. Aber trotzdem ist es das nicht.
Lasst uns mal kurz einen Blick in die GeschichtsbĂŒcher machen. Kanban hat sich aus dem Toyota Production System entwickelt. Und da wird es mit mehreren anderen Tools unter dem Begriff Lean Management zusammengefasst. Noch so ein Buzzword. Wobei man so fair sein muss, zu erwĂ€hnen, dass es sehr, sehr, sehr viel Diskussion darĂŒber gibt, was agil eigentlich alles beinhaltet und wo die Grenzen sind. Wobei diese Diskussion meiner Meinung nach komplett obsolet ist. Denn es geht nicht nur um die Methodiken an sich, sondern auch um das Menschenbild und das Mindset (wenn wir schon fröhlich Buzzwords herumwerfen). NatĂŒrlich muss ich die Spielregeln kennen, aber das eine macht ohne das andere keinen Sinn.

Agiles Board

Und was ist Scrum jetzt also? #

Scrum stellt uns Methoden zur VerfĂŒgung, mit deren Hilfe ein Team von drei bis neun Personen ein Projekt abwickeln kann. UrsprĂŒnglich ein reines Softwareentwicklungs-Framework, gibt es mittlerweile auch Versuche, Scrum (mit mehr oder weniger Verbiegungen) in anderen Bereichen einzusetzen. Hinter Scrum steht ein recht einfacher Gedankengang: wenn ich nicht genau weiß, wie mein fertiges Produkt am Ende des Projektes aussehen und die Umsetzung genau ablaufen wird, benötige ich kleine Schritte und viele Feedbackschleifen (iterativ und inkrementell), um gegebenenfalls schnell (agil) meine Marschrichtung korrigieren zu können.

Damit das gut geht, muss ich empirisch - sprich, auf Fakten basierend - arbeiten. Scrum hat deshalb (wie alle agilen Projektmanagementmethoden) ein großes Mantra: Inspect & adapt. Beobachte und verbessere. Und die dritte SĂ€ule in diesem Modell lĂ€sst sich daraus ableiten: Transparenz. Absolute Transparenz, wenn Ihr mich fragt. Anders kann das nicht funktionieren.
Und damit mein Team sich nicht verzettelt und verirrt, gibt es eine Konstante: customer value. Was benötigt der Kunde, was hilft ihm weiter? Und wie kann ich ihm das ehestmöglich liefern und dann schrittweise verbessern?

Zur UnterstĂŒtzung bekommt so ein Scrumteam zwei Rollen an die Seite gestellt. Einen Scrum Master, der Steine aus dem Weg rĂ€umt und das Team motiviert. Und einen Product Owner, der die Schnittstelle zum Kunden ist. Und um fĂŒr die Transparenz, Beobachtung, und Verbesserung zu sorgen, gibt es fixe Termine. Gedacht wird in zweiwöchigen Zyklen, den sogenannten Sprints. Zu Beginn eines Sprints plant das Team, was es in den kommenden zwei Wochen umsetzen wird (alle Todos stehen in einer nach Kundennutzen sortierten Liste, dem Product Backlog). Und am Ende eines Sprints wird dem Kunden die getanene Arbeit gezeigt und Feedback eingeholt. Danach setzt das Team sich zusammen und beredet, wie es besser werden kann.

Ihr seht, da gibt es viele Wörter und Begrifflichkeiten und Besonderheiten und Tam-Tam. Scrum driftet auch, wenn man nicht aufpasst, sehr schnell ins Rituelle ab. Aber mit ein wenig Hausverstand ist es ein sehr mĂ€chtiges Werkzeug, um kleine Projekte in einem Umfeld, in dem grĂ¶ĂŸere Unklarheit herrscht, erfolgreich abzuwickeln.

Und was ist Kanban jetzt also? #

Auch hier beginne ich gerne mit etwas Geschichte. Wenn ich weiß, wo etwas herkommt, kann ich es besser verstehen. Außerdem: Coaches erzĂ€hlen gerne die phantasievollsten MĂ€rchen, wo Kanban denn herkomme (vom Drama des zweiten Weltkrieges in England bis zu Eintrittskarten fĂŒr kaiserliche GĂ€rten im Tokio des 16. Jahrhunderts habe ich schon alles gehört). Dabei ist es fast schon banal: Toyota (die ĂŒbrigens ursprĂŒnglich WebstĂŒhle herstellten) hatten in den 1940er-Jahren ziemlich Probleme mit großen LagerstĂ€nden. Auf der Suche nach Vorbildern fĂŒr Just in Time-Produktion kam Taiichi Ohno auf die Idee, sich mit den damals aufkommenden großen SupermĂ€rkten nĂ€her zu beschĂ€ftigen. Und aus diesen Erkenntnissen hat er Kanban formuliert.

Kanban basiert auf einer einfachen PrĂ€misse: wenn ein Arbeiter sich sein nĂ€chstes ArbeitsstĂŒck selber organisiert (Pull-Prinzip) und es nicht befohlen bekommt (Push-Prinzip), kann er effektiver arbeiten. Dazu ist es essentiell, die Aufgaben, an denen ich gleichzeitig arbeite, zu reduzieren - das berĂŒhmte Work in Progress-Limit. Und dafĂŒr wiederum ist es notwendig, meine Arbeit zu visualisieren. Klingt kompliziert, ist ganz einfach. Ich schreibe alle meine Todos auf Zettel und hĂ€nge diese an ein Whiteboard mit drei Spalten: Todo, Work in Progress und Done. Und nun wird ein Zettel nach dem anderen ĂŒbers Brett gezogen - sprich: ich arbeite eine TĂ€tigkeit nach der anderen ab.

Kanban ist - anders als Scrum - sehr weit gegriffen und sehr theoretisch. Das hat den Vorteil, dass es sich nahezu ĂŒberall gut einsetzen lĂ€sst. Ich habe es im Lauf der Jahre von der Produktionshalle einer Lebensmittelfabrik bis zur Buchhaltung einer Internetagentur schon in allen möglichen Bereichen erlebt.

Und was haben Scrum und Kanban nun gemeinsam? Worum geht es im Wesentlichen? #

Mit einem Wort (und das kam bereits vor): Mindset. Und das ist auch der Grund, warum die beiden oft in einem Atemzug genannt werden. Scrum und Kanban verschieben beide die Verantwortung, wie die tĂ€gliche Arbeit erledigt wird weg von den FĂŒhrungskrĂ€ften und hin zu den Stellen, an denen diese tĂ€gliche Arbeit auch gemacht wird. Von Taiichi Ohno, dem Formulierer von Kanban, gibt es ein schönes Zitat: “Unsere Mitarbeiter kommen nicht zu uns, um zu arbeiten, sondern um zu denken.”

Das bedeutet, dass sich Teams selbst organisieren. Das bedeutet, dass Organisationen sich neue Strukturen geben (die gute, alte Matrix feiert da oft ein Revival). Das bedeutet, dass Organisationen wesentlich transparenter werden. MĂŒssen. Das bedeutet neues Management, neues Arbeiten, neues Denken. Und dafĂŒr gibt es keine Blaupause, das muss jede Organisation fĂŒr sich finden. Scrum und Kanban sind da nur die Hilfsmittel dazu.

Und zum Abschluß: gibt es Alternativen zu Scrum und Kanban? #

NatĂŒrlich gibt es die. Ich zĂ€hle mal die bekanntesten und verbreitetesten auf, damit Ihr sie zumindest mal gehört habt und wisst, dass es da auch jenseits des Tellerrandes noch viel zu entdecken gibt. Zuerst mal zu Scrum. Agile Projektmanagementmethoden gibt es viele, unter anderem:

Und Kanban hat aufgrund seiner inhaltlichen Breite viele GegenstĂŒcke und ErgĂ€nzungen im Prozessmanagement:

Da muss ich mich wiederholen: welches System das beste ist, kann man da schwer sagen, dafĂŒr gibt es keine Blaupause. Das beste ist das, was fĂŒr die eigene Organisation am besten funktioniert.

Vielen Dank fĂŒr Deine Zeit! Du kannst den Artikel gerne teilen. Und ich freue mich immer, von Euch zu lesen. Bilder von rawpixel und Daria Nepriakhina auf Unsplash.

← Vorheriger Artikel: SchĂ€tzen im agilen Projektmanagement, aber richtig
→ NĂ€chster Artikel: Ist Scrum tot?

Veröffentlicht am