Agile, Lean, Scrum, Kanban: Alle diese Begriffe beschreiben sehr ähnliche Projektmanagement-Ansätze. Zudem werden sie häufig synonym verwendet: Scrum-Zeremonien werden als agile Zeremonien bezeichnet, Kanban-Boards für Scrum verwendet – alles gar nicht so einfach, wenn man zum ersten Mal mit dem Begriff Agilität zu tun hat. Deshalb haben wir für Sie einen Leitfaden zum Vergleich von Scrum und Kanban erstellt, der Sie bei der Wahl des optimalen Tools unterstützt.
Was bedeutet Agilität?
Bevor wir uns mit der Definition von Scrum und Kanban befassen, ist es wichtig, den Begriff Agilität – das Kernstück beider Methoden – besser zu verstehen. Im Vergleich zu Scrum und Kanban beschreibt Agilität mehr eine Philosophie als eine Projektmanagement-Methodik.
Der Begriff Agilität wurde erstmals 2001 von “The Agile Alliance”, einer Gruppe aus 17 Softwareentwicklern, verwendet. Innerhalb von zwei Tagen schrieben die Entwickler das Agile Manifest, eine Sammlung von Prinzipien, die den stetigen Fortschritt sowie die Zusammenarbeit bei Prozessdokumentationen und Vertragsverhandlungen fördern sollen.
Bevor das Agile Manifest veröffentlicht wurde, basierten die meisten Softwareentwicklungsprojekte auf dem sogenannten Wasserfallprinzip, einer Projektmanagement-Methode, bei der alle Anforderungen für Projekte vor Beginn der Entwicklung festgelegt werden. Dabei verpflichten sich Entwicklerteams, eine bestimmte Anzahl an Aufgaben in einer bestimmten Zeit zu erledigen.
Dies führt jedoch zu mehreren Problemen:
- Taucht während des Entwicklungsprozesses ein Problem auf, ist dieses nur schwer zu lösen, da sich die Teams auf einen bestimmten Arbeitsumfang festgelegt haben.
- Da die Projektanforderungen bereits im Voraus vollständig niedergeschrieben werden, erhalten die Entwicklerteams nur sehr wenig Input von Projektsponsoren.
- Da das Entwicklerteam in einem Silo arbeitet, sehen die Projektsponsoren oft erst nach Abschluss des Entwicklungsprozesses ein Ergebnis. Das kann dazu führen, dass Projektsponsoren mit dem Endprodukt nicht zufrieden sind.
Als Antwort auf diese Probleme stellte The Agile Alliance einen neuen, besseren Entwicklungsansatz vor, in dem Teams während des gesamten Entwicklungsprozesses mit Projektsponsoren zusammenarbeiten, Anforderungen sammeln und den Code mit einem iterativen Ansatz erstellen.
Ein iterativer Ansatz ermöglicht es Entwicklern, alle während des Entwicklungsprozesses aufgetretenen Probleme anzugehen und verschafft den Projektsponsoren einen Überblick über das gesamte Projekt, um eventuelle Bedenken einzubringen, bevor es zu spät ist.
Was ist Scrum?
Im Vergleich zu Agilität – einer Philosophie, die einen kollaborativen, iterativen Ansatz für die Softwareentwicklung befürwortet – ist Scrum eine Methode, die häufig verwendet wird, um die agile Philosophie in die Praxis umzusetzen.
Der Scrum-Ansatz stellt Rahmenbedingungen zur Verfügung, die Projektsponsoren und Softwareentwickler nutzen können, um zusammenzuarbeiten und dabei den agilen Prinzipien zu folgen. Er wurde von Ken Schwaber und Jeff Sutherland, zwei Mitgliedern der Agile Alliance, entwickelt und im Scrum Guide beschrieben.
In einem Scrum-Team gibt es drei Rollen:
- Product Owner: Der Product Owner ist ein Vertreter aller Projektbeteiligten, der während des gesamten Entwicklungsprozesses zur Verfügung steht, um Fragen zu beantworten, abgeschlossene Aufgaben zu überprüfen und Anforderungen zu priorisieren. Das Einbinden des Product Owner in das Entwicklungsteam hilft dem Team, die Forderung des agilen Ansatzes nach effektiver Zusammenarbeit einzuhalten.
- Scrum Master: Der Scrum Master leitet das Entwicklungsteam, sorgt dafür, dass sich alle auf ihre Arbeit konzentrieren können, und führt Scrum-Meetings durch. Der Scrum Master fungiert als Dirigent des Teams und stellt sicher, dass der gesamte Workflow reibungslos abläuft und die Scrum-Regeln eingehalten werden.
- Entwicklungsteam: Das Entwicklerteam ist eine Gruppe von drei bis neun Entwicklern, die für alle Aufgaben verantwortlich sind, die vom Product Owner festgelegt und priorisiert werden.
Das Entwicklerteam arbeitet mit einem priorisierten Product Backlog (Liste aller Projektanforderungen), der aus User Stories besteht. User Stories erklären dabei nicht, was zu tun ist, sondern beschreiben die Anforderungen des Product Owner an das Produkt aus Sicht des Benutzers.
User Stories folgen immer einem bestimmten Format: Als [wer] möchte ich [was], damit [warum]. Zum Beispiel:
Als MeisterTask-Benutzer möchte ich Kacheln innerhalb von Bahnen auf meinem Board per Drag & Drop verschieben können, damit ich die Aufgaben in meinen Listen priorisieren kann.
Die Arbeit während des Entwicklungsprozesses wird in einer als Sprint bezeichneten Iteration abgeschlossen – ein Zeitraum von einer Woche bis zu einem Monat, in dem sich das Team auf eine bestimmte, geplante Anzahl an Aufgaben konzentriert. Diese Aufgaben werden in der Sprintplanung skizziert, bei der die Teams Aufgaben für User Stories festlegen und planen, die ihrer Meinung nach während des Sprints abgeschlossen werden können.
Während des Sprints haben Scrum-Teams ein tägliches Scrum-Meeting, bei dem jedes Mitglied des Entwicklerteams drei Fragen beantwortet:
- Woran haben Sie gestern gearbeitet?
- Woran werden Sie heute arbeiten?
- Gibt es Probleme, die Sie daran hindern, Ihre Aufgaben abzuschließen?
Am Ende jedes Sprints hält das Team zwei Meetings ab. Das erste ist der Sprint-Review, bei dem das Entwicklerteam dem Product Owner alle während des Sprints abgeschlossenen Aufgaben zur Freigabe präsentiert. Das zweite Meeting ist die Sprint-Retrospektive, bei der das Team versucht, sich in zukünftigen Sprints zu verbessern. Folgende drei Fragen werden dazu beantwortet:
- Was ist in diesem Sprint gut gelaufen?
- Was ist nicht gut gelaufen?
- Was sollten wir im nächsten Sprint anders machen?
Scrum hilft Teams dabei, einen agilen Ansatz zu implementieren und gleichzeitig sicherzustellen, dass alle Teammitglieder in einem konstanten Tempo arbeiten, das Ergebnis mit den Wünschen der Projektsponsoren übereinstimmt und sich Teams im Laufe eines Projekts verbessern.
Was ist Kanban?
Kanban wurde ursprünglich von Taiichi Ohno, einem Wirtschaftsingenieur bei Toyota, entwickelt, um einen effizienten Produktionsprozess zu schaffen. 2010 wurde die Kanban-Methode von David J. Anderson in dessen Buch Kanban: Evolutionäres Change Management für IT-Unternehmen auf die Softwareentwicklung angewendet.
Kanban verwendet einen Fließband-Ansatz: Einzelne Aufgaben werden in einer tafelähnlichen Ansicht mit Spalten angezeigt und in verschiedene Phasen verschoben, bis sie erledigt sind. Wie Scrum hat auch Kanban einen Backlog mit priorisierten Projektaufgaben – aber anstatt die Arbeit in Sprints zu planen, wählen Teammitglieder im Backlog die Aufgabe mit der höchsten Priorität aus.
Das Hauptmerkmal der Kanban-Methode ist das Kanban-Board. Wie in der Produktion, wo Produkte aus einzelnen Teilen auf einem Fließband zusammengebaut werden, durchlaufen Kanban-Aufgaben eine Reihe von Spalten, bis sie abgeschlossen sind.
Zum Beispiel:
Wenn für jede Aufgabe in Ihrem Backlog zuerst eine Entwicklung im Backend, dann eine Entwicklung im Frontend sowie ein Test und abschließend eine Freigabe erforderlich ist, könnte Ihr Kanban-Board so aussehen:
Aufgaben wandern von einer Spalte zur nächsten, bis alle Arbeitsschritte abgeschlossen sind.
Ein weiteres wichtiges Merkmal von Kanban ist das Work-In-Progress-Limit (WIP). Nehmen wir an, Ihr Backend-Entwicklerteam arbeitet viel schneller als Ihr Frontend-Entwicklerteam. Das hätte zur Folge, dass Ihr Frontend-Team am Ende noch zahlreiche offene Aufgaben hat, während Ihre Tester herumsitzen und nichts zu tun haben.
WIP-Limits begrenzen die Anzahl an Aufgaben, die sich gleichzeitig in einer Spalte befinden können. Ist das WIP-Limit eines Teams erreicht, so ist das ein Signal, dass das Team möglicherweise überlastet ist.
In solchen Fällen könnten andere Mitglieder des Teams helfen, die noch offenen Aufgaben zu reduzieren. Ein erreichtes WIP-Limit ist jedoch meist ein Zeichen dafür, dass die Arbeitsaufteilung im Team unausgewogen ist. Um auf unser Beispielszenario zurückzukommen: Hier würden Sie weniger Backend-Entwickler und mehr Frontend-Entwickler benötigen.
Obwohl bei Kanban die Scrum-spezifischen Retrospektiv-Zeremonien fehlen, zählt die kontinuierliche Verbesserung zu den Grundprinzipien. Teams müssen schrittweise nach Möglichkeiten suchen, den Workflow zu verbessern, Blockaden zu beseitigen und ihre Prozesse zu rationalisieren.
Kanban vs. Scrum
Wie Sie wahrscheinlich schon bemerkt haben, ist Scrum eine komplexe und verhältnismäßig strikte Methode mit klar definierten Regeln und einem sehr spezifischen Rahmen, an den sich Teams halten müssen. Kanban hingegen ist der schlankere Ansatz mit weniger Regeln und einem simpleren Rahmen. Dennoch helfen beide Ansätze Teams dabei, die Grundprinzipien von Agilität einzuhalten: Zusammenarbeit und Flexibilität.
Um die richtige Methode für Ihr Team auszuwählen, sollten Sie einige Faktoren berücksichtigen:
- Wie viel Struktur braucht Ihr Team? Wenn Ihr Team besser mit detaillierten, klar definierten Regeln und Prozessen arbeitet, ist Scrum wahrscheinlich der geeignetere Ansatz. Kanban ist um einiges flexibler.
- Sind Sie von anderen Teams/Projekten abhängig? Die detaillierten Planungsprozesse von Scrum sind dann effizient, wenn Ihre Arbeit hauptsächlich von Einzelpersonen und Teams außerhalb Ihres Scrum-Teams abhängt. Kanban funktioniert besser, wenn Ihre gesamte Arbeit von Ihrem eigenen Team erledigt werden kann.
- Sind Ihre Aufgaben von anderen Aufgaben abhängig? Die Scrum-Planung funktioniert dann reibungslos, wenn einige Aufgaben in Ihrem Backlog abgeschlossen sein müssen, bevor andere bearbeitet werden können. Kanban eignet sich besser, wenn jede Aufgabe isoliert von anderen erledigt werden kann.
Keine der beiden Methoden ist von Natur aus besser als die andere. Die “richtige” Wahl für Ihr Team hängt von Ihrer Unternehmensstruktur, Ihren Präferenzen im Team sowie den Besonderheiten Ihrer Arbeit und Ihres Projekts ab.
Sie müssen sich auch nicht unbedingt immer an die eine oder die andere Methode halten. Tatsächlich können Teams, die schon eine Weile zusammenarbeiten, problemlos zwischen beiden Ansätzen hin- und herwechseln, um verschiedenen Projekttypen und Arbeitsbereichen gerecht zu werden.
Scrum und Kanban außerhalb der Softwareentwicklung
Obwohl Scrum und Kanban ihre Wurzeln in der Softwareentwicklung haben, sind die Philosophien und Rahmenbedingungen beider Methoden in vielen verschiedenen Bereichen nützlich.
Kanban eignet sich zum Beispiel sehr gut für das Content Marketing. Die meisten Arbeitsabläufe im Content Marketing beginnen mit einem Backlog von Ideen – einem Redaktionskalender –, die von einem Content Marketing Manager geplant werden. Von dort aus werden sie vielleicht an einen SEO-Spezialisten weitergeleitet, dann an einen Content Writer, an einen Redakteur und an einen Designer, bevor sie letztendlich veröffentlicht werden.
Kanban kann auch für HR-Teams während des Einstellungsprozesses ein hilfreicher Ansatz sein. Da verschiedene Aufgaben von verschiedenen Personen (einige von der Personalabteilung, andere vom Personalleiter) zu unterschiedlichen Zeiten erledigt werden müssen, gelingt es mit der Kanban-Methode viel besser, effizient zusammenzuarbeiten.
Scrum könnte beispielsweise auch von einem Designteam eingesetzt werden, das an der Neugestaltung einer Website arbeitet. Angenommen, Sie müssen die neue Website in sechs Monaten veröffentlichen und es gibt zahlreiche Aufgaben, die im Rahmen dieses Projekts erledigt werden müssen:
- Elemente wie Navigationsmenüs, Schaltflächen und CTAs aktualisieren
- Bilder aktualisieren, die in einzelnen Blogbeiträgen und Zielseiten verwendet werden
- Layouts aller Zielseiten aktualisieren
- Den Styleguide Ihres Unternehmens aktualisieren, um die neuen Richtlinien widerzuspiegeln
Aufgrund des engen Zeitfensters und der Zusammenarbeit des Designteams mit anderen Teams wie Entwicklung, Vertrieb, Produkt und Marketing könnte Scrum die optimale Lösung für die Verwaltung des Projekts sein.
Für die meisten großen und komplexen Projekte – unabhängig vom Aufgabenbereich – ist die klare Struktur von Scrum oft von Vorteil. Für Arbeitsabläufe, die den Input oder die Aufmerksamkeit mehrerer Personen erfordern, eignet sich die Kanban-Methode.
Das richtige Kanban- und/oder Scrum-Tool auswählen
Wenn sich Ihr Team für Scrum und/oder Kanban interessiert, steht Ihnen mittlerweile eine große Menge an Tools zur Verfügung. Einige wurden dabei spezifisch für Scrum entwickelt, bieten dementsprechend viele Funktionen für Scrum-spezifische Zeremonien wie Sprintplanung und Release-Planung und nutzen Scrum-Terminologien wie User Stories und Sprints.
Obwohl Scrum-spezifische Tools zwar gut funktionieren, wenn Ihr Team ausschließlich mit der Scrum-Methode arbeitet, so sind sie schnell weniger effektiv – und um einiges umständlicher –, wenn sie gelegentlich einen Kanban-Ansatz verfolgen möchten.
Kanban-Tools bieten mehr Flexibilität für Teams, die mit beiden Methoden arbeiten möchten – abhängig von den Anforderungen der Aufgaben.
Natürlich sind Kanban-Tools für die Kanban-Methode konzipiert und dementsprechend gut dafür geeignet. Aber sie eignen sich genauso gut für einen Scrum-Ansatz: Viele Teams nutzen für Scrum ein Kanban-Board – eine Praxis, die auch als ScrumBan bezeichnet wird.
Ein Kanban-Board kann mit der Spalte Produkt-Backlog beginnen, in der alle offenen User Stories gelistet sind. Die Product Owner arbeiten in dieser Spalte, erstellen für das Projekt benötigte User Stories und priorisieren diese, indem sie Kacheln je nach Priorität der Reihe nach anordnen.
Für die Sprintplanung zieht das Entwicklerteam anschließend alle User Stories in die Spalte Sprint-Plan, um einen Ablauf für den kommenden Sprint zu erstellen. Bei Bedarf können auch Schätzungen hinzugefügt und Checklisten verwendet werden, um die User Stories in einzelne Aufgaben aufzuteilen.
Wenn das Entwicklerteam an einer User Story arbeitet, können Teammitglieder die Karte in die Spalte In Bearbeitung verschieben. Zusätzlich kann die Spalte Blockiert hinzugefügt werden, in die alle User Stories eingefügt werden, die aufgrund eines Blockers (der vom Scrum Master entfernt werden muss) nicht abgeschlossen werden können.
Schließlich können Sie die Spalte Abgeschlossen oder Freigabe für alle User Stories hinzufügen, die dem Product Owner zur Freigabe präsentiert werden müssen. Sobald die User Stories genehmigt wurden, kann jede Karte in die Spalte Fertig für den Sprint verschoben werden, in dem die User Story abgeschlossen wurde.
Kanban-Tools sind flexibel und für alle interessierten Parteien außerhalb des Teams leicht verständlich. Projektmanager, Projektsponsoren und Teammanager können das Board jederzeit einsehen, um einen schnellen Gesamtüberblick über den Projektfortschritt zu gewinnen.
Der Überblick über das gesamte Projekt ist auch für die Teams von Vorteil, da viel weniger Besprechungen über den Projektstatus abgehalten werden müssen.
Agile Teams und Prozesse aufbauen
Im Grunde geht es bei Agilität um kontinuierliche Verbesserungen. The Agile Alliance konzentrierte sich bei ihren angestrebten Verbesserungen auf Zusammenarbeit, Flexibilität und schrittweiser Leistungssteigerung. Aber das sind vielleicht nicht die Verbesserungen, die Ihr Team braucht – und das ist auch in Ordnung so.
Als ich noch als Product Owner gearbeitet habe, habe ich Leute oft sagen hören: “Wenn du x machst, bist du nicht agil.” Aber Agilität selbst ist kein regelbasiertes System, es ist ein System von Prinzipien. Und diese Prinzipien können von jedem Team auf die Art und Weise angewendet werden, die für sie funktioniert – solange das Ziel, nämlich die kontinuierliche Verbesserung, nicht aus den Augen verloren wird.
Daher rate ich Ihnen, Ihren Blick bei der Recherche verschiedener agiler Methoden weniger auf die Theorie zu fokussieren, sondern darauf, die Probleme zu lösen, die Ihre Teamarbeit erschweren und Ihren Fortschritt verzögern.
Die Definitionen und Prozesse sind letztendlich nur Beschreibungen. Wie das agile Manifest besagt, ist eine funktionierende Software – beziehungsweise das Endergebnis – viel wichtiger als der Weg dorthin.