Hat ein Team einmal beschlossen, besser gleich eine neue, meist agile Vorgehensweise im Projekt einzuführen statt es beim Status quo des kontrollierten Chaos zu belassen, gewinnt der Begriff “Agile” plötzlich an Bedeutung: War es vorher nur ein Projektmanager der dem Team sagte, was zu tun ist während sich das Team bemühte, die geplante Arbeit zeitgerecht fertig zu bekommen, so sind es auf einmal neue Rollen, Bezeichnungen und Werkzeuge (im Idealfall schon Prozesse), die zu anderen Denk- und Sichtweisen im Team führen können. Doch Arbeit nun selbst zu organisieren, kann sowohl Teammitglieder als auch Manager gleichermaßen verunsichern. Davon abgesehen beschäftigt dem Team vor allem eine Frage: Welche Methode ist für uns die beste?

Einen Prozess auswählen

Die erste Frage im agilen Prozess: Welche agile Variante ist für das Team am geeignetsten? Es gibt viele populäre und formalisierte Ansätze. Bei der Wahl zur richtigen Vorgehensweise ist aber ruhig die Frage erlaubt: “Wo gibt es die wenigsten Unterschiede zu meinem bisherigen Prozess?”

Für einige Unternehmen bedeutet “agil werden” leider nur ein paar Titel und Bezeichnungen einzuführen und sich “agil” zu nennen, ohne einer ernsten Absicht dahinter, bei Arbeitsprozess auch tatsächlich etwas zu ändern. Viel wissen leider noch immer nicht, dass es sich mehr als lohnt, dem Team die Chance auf einen legitimen agilen Workflow zu geben und ggf. zu beobachten, was für wen funktioniert.

Kanban oder Scrum?

Die zwei beliebtesten Methoden sind zweifelsohne Scrum (Rahmenwerk) und Kanban (Vorgehensmodell). Beide sind agil und haben Ähnlichkeiten bei den Prozessen oder Tools. Und beide haben wesentliche Vorteile, welche für unterschiedliche Anwendungen optimal sind.

Scheibchen oder Iteration?

Kanban und Scrum sind legitime Möglichkeiten, um einen agilen Prozess zu strukturieren. Sie haben beide einen gemeinsamen ursprünglichen Kern, verschiedene Vor- und Nachteile und sind im Laufe der Zeit unterschiedlich gereift.

Scrum

Für Teams, die neue Versionen zu einem Produkt in regelmäßigen Abständen realisieren wollen, während sie Anpassung an einen sich ständig verändernden Markt vornehmen wollen, ist Scrum eine ausgezeichnete Wahl.

Scrum definiert klar Rollen, Rituale und Artefakte, die sofort angewandt werden müssen. Scrum ist vielseitig genug um kleine Teams von 3 – 9 Personen zu handhaben – schafft es aber mittlerweile auch, in großen Organisationen (> 1000 Personen) klar zu kommen. Es unterstützt die Autonomie für die Entwickler, die Transparenz für die Manager und die Rechenschaftspflicht für die Organisation als Ganzes.

Dadurch, dass das Team sich zu einem zeitlich vereinbarten Vertrag (= Sprint) verpflichtet, der immer wiederholt wird, erlaubt Scrum den Teams kontinuierliche Adaptierungen ohne die Selbstbestimmung jedes Mitglied des Teams zu behindern.

Kanban

Teams, die sowohl auf Produkt- als auch auf Service-Ebene agieren, bevorzugen oft Kanban vor Scrum.

Während sich Scrum auf die laufenden Iterationen eines Produkts basierend auf regelmäßige Auslieferungen zum Kunden fokussiert, unterstützt Kanban einen konstanten “Flow” von untereinander meist unabhängigen Verbesserungen und Optimierungen. Eine der wichtigsten Stärken von Kanban ist, dass die Menge an Arbeit im Team gesteuert wird.

Kanban und Scrum profitieren von klar definierten, in sich abgeschlossene Aufgaben (“Stories”), welche einzeln bzw. unabhängig voneinander an den Kunden geliefert werden können, um dort letztendlich einen echten Wert zu schaffen. Während Scrum es allerdings jedem Teammitglied selber überlässt, an wie vielen Dingen gleichzeitig gearbeitet wird, begrenzt Kanban die Anzahl an in-Arbeit befindlichen Aufgaben (WiP = “Work in Progress”).

Der Unterschied mag marginal erscheinen, macht sich aber bemerkbar, wenn man ein Kanban-Board und ein Scrum Board nebeneinander stellt.

Das größte Unterscheidungsmerkmal zwischen den beiden ist, dass Scrum das Produktivitätsniveau in Bezug auf die Geschwindigkeit des Teams misst und kontrolliert, wie viele agile Punkte (Story Points) ein Team während eines Sprints abarbeitet. Kanban hingegen steuert nachhaltig die noch unfertige Arbeit (WiP) und begrenzt die Anzahl der Aufgaben, welche das Team gleichzeitig bearbeiten darf.

Transparenz

Sowohl Scrum als auch Kanban praktizieren eine Kultur des raschen Feedbacks. So finden tägliche Stand-up-Treffen statt, bei dem die Team-Mitglieder über das berichten, was sie seit dem letzten mal getan haben, was sie zu tun wollen und ob sie irgendwelche “Blocker” haben, die sie von der Arbeit abhalten. In beiden Ansätzen geht es darum, dass sich die Entwickler untereinander austauschen sollen und daher auch oft niemand anderer (Product Owner, Manager) dem Stand-up beiwohnt.

Scrum gibt dem Team einen ganzen Sprint Zeit um zu entscheiden, wie sie selbst-organisiert die Arbeit verrichten wollen. Kanban hingegen überwacht ständig den Arbeitsfluss (Workflow) und achtet sorgfältig darauf, wann neue Aufgaben begonnen werden. Dies alles hat erhebliche Auswirkungen auf die Art und Weise, wie Manager, Projekt- bzw. Produkt-Verantwortliche und Entwickler zusammenarbeiten.

Mit Kanban kann das Team die unfertige WiP-Ebene dynamisch anpassen, um Leerlauf oder Überarbeitung von Entwicklern zu vermeiden – etwas, dass auch vom Management verfolgt werden kann.

In Scrum arbeitet das Team selbst-angepasst am Fortschritt und auf Grundlage der Anzahl von Aufgaben, welche sie zu Sprintanfang begangen haben, mit dem Ziel, jeden Task laut deren Definition abzuschließen.

Rhythmus

Der Rhythmus in Scrum (= Sprint) wird durch das Team auf Grundlage der Arbeit, die getan werden muss, vereinbart und liegt in der Regel zwischen zwei und vier Wochen. Jeden Sprint, den das Team durchläuft, muss eine Reihe von Ritualen einhalten, um den Wert zu demonstrieren und zu lernen, was gut funktioniert hat und was besser laufen hätte können. Danach verpflichtet sie sich auf ein neues Set von Aufgaben im nächsten Sprint. Weil Sprints als zeitbasierte Iterationen ein wesentlicher Bestandteil in Scrum ist, werden die Rituale innerhalb des Prozess abgehalten.

Kanban Iterationen sind viel flexibler. In Kanban kann die Entscheidung, wann der Workflow pausiert wird, im Zuge von Reflexionen und im Interesse des Kunden vereinbart werden, zB nach Datum, nach Meilenstein oder durch andere Metriken, die mit dem Team vor Beginn der Arbeit vereinbart wurden. Das Risiko für eine Kanban-Team ist, dass die Unregelmäßigkeiten des Prozesses sie ermutigen könnte, Reflexionen zu überspringen oder weniger Aufmerksamkeit zu schenken, obwohl diese für den agilen Prozess wichtig sind, um Dinge zu wiederholen oder zu verbessern.

Agiles Arbeiten

Es ist wichtig für Ihr Team, sorgfältig zu prüfen, welche Vorgehensweise für sie am meisten Sinn macht, um das Ziel zu erreichen. Wenn Sie Produkte entwickeln und klare Rollen bevorzugen, wird Scrum ihr wahrscheinlicher Favorit sein. Wenn Sie Services und Dienstleistungen anbieten, wird Kanban besser zu Ihnen passen.

Verschiedene Teams in unterschiedlichen Situationen erfordern unterschiedliche Ansätze. Den einzigen Fehler den Sie machen können ist, alles beim alten zu lassen und gleichzeitig zu hoffen, dass alles gut wird!