Die moderne Geschäftswelt wandelt sich immer schneller, wird komplexer und fordert kürzere Time-to-Market-Intervalle. Das spiegelt sich in der Softwareentwicklung: Bei vielen Projekten ist es unmöglich, den gesamten Ablauf im Voraus exakt zu planen. Anforderungen sind noch nicht vollständig bekannt, nicht alle Technologien wurden bereits erprobt und der Markt verändert sich fortlaufend.

Vor diesem Hintergrund entstand das agile Projektmanagement. Dessen Grundidee lässt sich so zusammenfassen: Teams sollten pragmatisch vorgehen, gut zusammenarbeiten und flexibel auf neue Situationen reagieren.

Das „Agile Manifest“ übersetzt diesen Gedanken in vier zentrale Werte:

• Teamwork: Es ist wichtiger, dass Menschen im Team gut zusammenarbeiten, als dass die „richtigen“ Prozesse und Werkzeuge verwendet werden.
• Pragmatik: Es ist wichtiger, funktionstüchtige Software auszuliefern, als jedes Detail zu dokumentieren.
• Kooperation: Es ist wichtiger, mit dem Auftraggeber gut zu kooperieren, als einen perfekten Vertrag mit ihm auszuhandeln.
• Flexibilität: Es ist wichtiger, schnell auf Veränderungen zu reagieren, als einen bestimmten Plan exakt zu befolgen.

Scrum und Kanban sind zwei der beliebtesten agilen Projektmanagement-Methoden. Sie werden in der Softwareentwicklung aber auch für andere Projekttypen eingesetzt. Generell lässt sich sagen: Während Scrum auf die Bewältigung von Komplexität abzielt, liegt die Stärke von Kanban im flexiblen Reagieren auf Änderungen. Um die Entscheidung Scrum vs. Kanban leichter treffen zu können, sollten allerdings die exakten Funktionsweisen betrachtet werden.

Wenn Sie etwas Neues entwickeln wollen, von dem Sie zum jetzigen Zeitpunkt noch nicht genau wissen, wie es am Ende aussehen und funktionieren wird – dann ist Scrum der richtige Ansatz. Scrum ist eine empirische Entwicklungsmethode, funktioniert also nach dem Versuch-und-Irrtum-Prinzip: In kleinen, schnellen Arbeitsschritten („Sprints“) entwickelt das Team eine funktionierende Teillösung, testet diese und nutzt die gewonnenen Erkenntnisse für den nächsten Schritt.

Kanban wurde bereits 1947 bei Toyota entwickelt, um den Produktionsprozess von Automobilen effizienter zu gestalten. Die Grundidee: Alle Teammitglieder sollten möglichst konstant ausgelastet sein, zugleich aber flexibel auf Veränderungen reagieren und die Arbeitsprozesse kontinuierlich verbessern können.

Erreicht wird diese Kombination von konstanter Auslastung und Flexibilität, indem die Arbeitslast („Work in Progress“) präzise kontrolliert wird. Auf dem Kanban-Board trägt man in drei Spalten alle Aufgaben ein: „Zu tun“, „In Arbeit“ und „Erledigt“. In der Spalte „In Arbeit“ dürfen nicht mehr als zwei Kärtchen pro Teammitglied stehen. Auf diese Weise sehen alle Beteiligten auf einen Blick, welche Aufgaben sich in der Warteschleife befinden und welche aktuell vorangetrieben werden.

Wenn sich Prioritäten ändern oder neue Anforderungen hinzukommen, werden diese je nach vorhandener Kapazität in Angriff genommen. Bei dringenden Anliegen kann eine Aufgabe, die bereits in Arbeit ist, zugunsten der wichtigeren nochmals zurückgestellt werden.

Das Visualisieren von Aufgaben in einem übersichtlichen, geordneten Board hat neben der eigentlichen Steuerungsfunktion auch eine nicht zu unterschätzende psychologische Wirkung: Alle haben stets das gesamte Projekt vor Augen und sehen, wie es voranschreitet. Damit erzeugt Kanban eine hohe Eigenmotivation im Team und fördert den Zusammenhalt.

Das Kanban-Board ist durch verschiedene Software-Tools mittlerweile allgegenwärtig. Bekannte Beispiele sind Trello, Monday, Asana und MeisterTask.

Auch bei Kanban gibt es regelmäßige kurze Meetings, in denen sich alle gegenseitig über den Fortgang und die Herausforderungen des Projekts informieren.

Scrum und Kanban haben die folgenden Prinzipien des agilen Projektmanagements gemeinsam:

• Teams organisieren sich selbst.

• • Teams entscheiden eigenständig, welche Aufgaben sie als Nächstes in Angriff nehmen („Pull-Prinzip“).
  • Der persönliche Austausch in Form kurzer Meetings ist die zentrale Kommunikationsform.
  • Konzentration auf eine beschränkte Anzahl von Aufgaben anstatt von Multitasking. 
  • Im Vordergrund steht das Ziel, funktionierende Produkte wie zum Beispiel Software-Versionen schnell und in kurzen Abständen auszuliefern.
  • Mittels Meetings und Boards wird der Arbeitsprozess transparent gemacht, sodass er laufend optimiert werden kann.
  • Der Arbeitsprozess wird so gestaltet, dass er theoretisch ewig weitergeführt werden könnte, ohne das Team zu erschöpfen.

• Das Team motiviert sich in beiden Frameworks selbst.

Neben den genannten Gemeinsamkeiten existieren aber auch einige wichtige Unterschiede zwischen den beiden Methoden.

Scrum sieht drei Team-Rollen vor: Product-Owner, Scrum-Master und Entwickler. Jedes Team arbeitet autonom, führt also sein eigenes Scrum-Board.

Bei Kanban gibt es keine festen Team-Rollen; mehrere Teams können nebeneinander auf demselben Kanban-Board arbeiten.

Bei Scrum steht ein möglichst präzises Timing im Vordergrund: Zu Beginn schätzt das Team die Zeitdauer, die für ein Arbeitspaket bzw. für einzelne Aufgaben erforderlich ist. („Team-Forecast“). Bei Kanban spielt der Zeitfaktor eine untergeordnete Rolle.

In Scrum optimieren die Teams den Entwicklungsprozess anhand der Erkenntnisse, die sie aus der Retrospektive am Ende eines Sprints gewinnen.

Kanban arbeitet dagegen mit der „Lead-Time“, der durchschnittlich benötigten Abwicklungszeit. Das Ziel ist eine stetige Optimierung der Effizienz, also eine Verkürzung der Lead-Time.

Scrum arbeitet von Sprint zu Sprint. Jeder Sprint beginnt mit einem neuen, leeren Scrum-Board. Kanban verwendet dagegen einen kontinuierlichen Arbeitsfluss über das gesamte Projekt hinweg. Das Team bewegt sich in einem permanenten, gleichbleibenden Strom von Aufgaben. Das Kanban-Board bleibt von Anfang bis Ende des Projekts bestehen.

In der Sprint-Planung schätzt das Scrum-Team ab, wie viel Zeit für die einzelnen Arbeitspakete eingesetzt werden muss. Statt absoluter Stundenangaben erfolgt die Bewertung unter Verwendung von relativen Zahlenwerten, sogenannten Story-Points. Die durchschnittliche Anzahl der abgeschlossenen Story-Points pro Sprint nennt man Velocity.

Kanban misst unter Verwendung der bereits erwähnten Lead-Time und der Cycle-Time. Die Lead-Time bezeichnet die totale Zeit von der Bestellung bis zum Abschluss einer Aufgabe, die Cycle-Time dagegen die enger gefasste Fertigungszeit.

Scrum lässt im Normalfall keine Änderungen während eines Sprints zu. Tauchen unvorhergesehene Arbeiten auf, wird das Scrum-Team diese in den Product-Backlog verschieben und erst nach Beendigung des aktuellen Sprints darauf zurückkommen.

In Kanban wird anhand der verfügbaren Arbeitskapazität entschieden, ob die neue Aufgabe sofort oder erst später in Angriff genommen werden soll. Gegebenenfalls wird man eine aktuelle Aufgabe „In Arbeit“ vorerst zurückstellen, falls etwas Dringendes ansteht.

Die Entscheidung Scrum vs. Kanban richtet sich vor allem nach der Beschaffenheit des Projekts. Wenn die Anforderungen und/oder die Technologie mehr Unbekanntes als Bekanntes enthält, spricht man von komplexen Aufgaben. Dies trifft beispielsweise auf viele Softwareprodukte oder IT-Serviceleistungen zu sowie auf Projekte im Bereich Forschung und Entwicklung. Hier entfaltet Scrum seine Stärken: Anstatt umfangreiche Pläne zu erstellen, arbeitet man sich in kurzen Intervallen und Iterationszyklen an die bestmögliche Lösung heran.

Ein steter Strom neuer Aufgaben, welche in sich nicht allzu komplex sind, wird am besten mit Kanban bewältigt. Bezeichnenderweise wird Kanban gerne von Support- und Wartungsteams eingesetzt, wo täglich neue Support-Tickets hereinkommen, die beantwortet werden müssen. Die Stärke von Kanban liegt in der smarten Arbeitsstrategie, welche auf die kontinuierliche Verbesserung des Prozesses abzielt.

Zum Schluss ein bildhafter Vergleich, der das Gesagte nochmals verdeutlicht: Wenn Sie sich mitten im Dschungel befinden und nicht genau wissen, wo Sie sind, entscheiden Sie sich am besten für eine Marschrichtung und Distanz, halten an einem markanten Geländepunkt an, orientieren sich neu und nehmen die nächste Etappe in Angriff. Das ist Scrum.

Wenn Sie eine Bergwanderung unternehmen, entscheiden Sie sich für ein Marschtempo, das Sie durchhalten können, nehmen eine gute Landkarte mit und laufen los. Wenn ein Hindernis auftaucht, ändern Sie Ihre Route, ohne das Ziel aus den Augen zu verlieren. Das ist Kanban.

Erinnern Sie sich an die eingangs erwähnten agilen Grundsätze? Einer davon lautet, dass Menschen wichtiger sind als Methoden. Insofern ist die Frage Scrum vs. Kanban keine Entweder-Oder-Entscheidung. Beide Frameworks haben ihre Daseinsberechtigung und können bei Bedarf auch flexibel kombiniert werden. Wählen Sie die agilen Elemente aus, die für Ihre Organisation und Ihre Mitarbeiter am meisten Sinn machen.

Die Agilität Ihres Unternehmens hängt nicht nur von der Arbeitsweise Ihrer Teams ab. Auch wie flexibel Sie auf neue Infrastruktur- und Dienstleistungsanforderungen reagieren, spielt eine wichtige Rolle. Hier unterstützen Sie die Experten der ahd mit leicht skalierenden Cloud-Lösungen und modular buchbaren IT-Services. Kontaktieren Sie uns jetzt, um eine unverbindliche Beratung zu vereinbaren.