BLOG / COMPANY · SCRUM UND KANBAN

E in frustriertes Team. Eine Idee. Ein geschockter Scrum-Master. Und am Ende besseres Arbeiten. Agilität bedeutet, den Mut zu haben, seine Arbeits­weise zu verändern. Wie ein Team den Schritt von Scrum zu Kanban gewagt hat.

Die agile Transformation beginnt meist durch die Einfüh­rung von Scrum in den Entwicklungs­teams. Alle sind sich einig, dass es an der Zeit ist, agiler zu werden. In der Entwick­lung werden Scrum-Teams gegründet. Ihnen wird gesagt, dass sie von nun an Scrum verwenden sollen. Ein Scrum Master wird ernannt oder eingestellt und die Teams werden in der Verwen­dung von Scrum und im Umgang mit Agilität geschult. Los geht’s.

Doch die Entscheidung für eine agile Entwicklung mit Scrum ist nur der Anfang. Im Laufe der Zeit lernen die Teams und ihre Mitglieder, wie sie Agilität nutzen können, um ihre Effizienz zu verbessern, indem sie Verant­wortung für ihre Arbeit übernehmen.

Dieser Artikel beschreibt, was passiert, wenn man das Team entschei­den lässt, wie es am besten mit einem komplexen Szenario umgeht.

DIE BISHERIGE UMSETZUNG IN SCRUM (OHNE KANBAN)

Das Team, um das es hier geht, hatte über ein Jahr lang Scrum verwendet, um seine Arbeit für die nächsten zwei Wochen (den Sprint) zu planen. Es startete allerdings nicht mit einem Projekt auf der grünen Wiese. Das Team musste sich mehr auf die größeren architek­tonischen Änderungen konzen­trieren als auf die Verbesse­rung des Produkts aus Sicht der Software­nutzer.

Diese große Anzahl von Architekturän­de­run­gen war schwer abzu­schätzen und schwer zu planen. Es war schwierig, das Sprint-Ziel richtig zu formulieren, da diese größeren Änderungen einer­seits wirklich notwendig waren, andererseits aber keinen unmittel­baren Mehrwert für die Produkt­nutzer hatten. Daher bestand das Sprint-Ziel aus der Idee, die verschie­denen Anforde­rungen im Sprint zu erfüllen. Und da das Architek­turteam intensiv am Archi­tektur­design arbeitet, konnten sich die Anfor­derungen sogar während des Sprints ändern.

DIE UMSTELLUNG HIN ZU KANBAN

Es geschah an einem Freitagmorgen. An diesem Morgen hatte das Team sein zwei­wöchiges Scrum-Review und war nicht in der Lage, auch nur eines der geplanten Sprint-Backlog-Elemente vorzu­stellen, obwohl es davon ausging, dass sie am Nach­mittag fertig sein würden. (Das Gefühl, am Nach­mittag fertig zu sein, hat sich am Ende als richtig erwiesen). In der Retro­spektive später an diesem Tag hat sich das Team sehr geärgert, da dies bereits in einigen Sprints zuvor passiert war.

Das Team sprach über die Grenzen, die der Scrum-Prozess seinem Entwick­lungspro­zess setzt, und über den Hintergrund der Kunden­bedürf­nisse, die im Zusammen­hang mit fehlge­schlagenen Sprints stehen.

Im Rahmen der Retrospektive kam ein Teammitglied auf die Idee, Kanban anstelle von Scrum zu bevor­zugen. Dies würde die Bedür­fnisse des Teams viel besser wider­spiegeln als Scrum.

ERINNERUNG AN DAS AGILE MANIFEST

Als Scrum Master war ich im ersten Moment geschockt, als diese Idee vorge­schlagen wurde. Umso mehr, als sie zudem sehr gut ange­nommen wurde. Ich fragte mich, was eine Umstel­lung auf Kanban mit sich bringen und was es für das Team bedeuten würde. Ich war mir nicht sicher, ob dies für das Team funktio­nieren könnte. Doch dann erinnerte ich mich an das agile Manifest:

“INDIVIDUEN UND INTERAKTIONEN VOR PROZESSEN UND WERKZEUGEN”

Das bedeutet, dass das Team nicht an Scrum festhalten muss, wenn Kanban im Moment das bessere Instrument für seine Arbeit ist. Je länger wir über die Verän­derung sprachen, desto zufrie­dener war ich mit ihr. Nicht nur, weil sie richtig war, sondern auch, weil das Team gelernt hat, über seinen Arbeits­prozess zu sprechen und ihn bei Bedarf zu verändern.

Sicherlich hatte das Team alle Instrumente, die es brauchte, um seinen Scrum-Prozess an seine Bedürf­nisse anzupassen. Der Fort­schritt, den das Team an diesem Punkt gemacht hat, besteht nicht darin, Kanban gegenüber Scrum vorzu­ziehen. Das Bewusst­sein, die agile Transfor­mation selbst in der Hand zu haben, zeigt vielmehr, welch großen Schritt dieses Team in Rich­tung Verständ­nis von Agili­tät gemacht hat.

WAS VON SCRUM UND KANBAN BLEIBT

In der Diskussion mit dem Team, wie sich der Wechsel zu Kanban auf den Entwick­lungsfort­schritt auswirken würde, stellten wir fest, dass die Verän­derung gar nicht so groß ist. Denn das Team hatte beschlossen, das Daily, die Reviews und die Retro­spektiven beizube­halten. Diese Besprechungen waren für das Team immer hilfreich und verhalfen ihm vor allem dazu, regel­mäßig zu kommuni­zieren und sich zu ver­bessern.

Der Produktivitätsschub, den das Team in den zwei Monaten nach der Umstel­lung auf Kanban erlebte, könnte auf die Umstel­lung zurück­zuführen sein. Ehrlich gesagt, wir wissen es nicht. Die Art und Weise, wie das Team mit den Software­änderungen umgeht, die es durchführt, fühlt sich jedoch für alle Team­mitglie­der viel natürlicher an. Mit dem agilen Coaching im Hinterkopf war das Team also in der Lage, innerhalb von nur 90 Minuten seine bishe­rigen Arbeits­gewohn­heiten von Scrum auf Kanban umzu­stellen.


Mehr zu agilen Methoden bei FLS:
➡ DER SPRINT
➡ DIE/DER SCRUM MASTER*IN
➡ DIE/DER PRODUCT OWNER*IN
➡ EINBLICKE IN UNSERE AGILE ARBEITSWEISE
➡ DEEP DIVE IN DAS SCRUM-ENTWICKLER-TEAM


Lust auf agile Arbeitsweisen und spannende Software­entwick­lung? Zu unserem Karriere-Portal: