Scrumban statt Scrum + Kanban

Was ist Scrumban?

Roman: Herzlich willkommen in der TGA-Bar. Heute Scrumban. Sören, was ist denn Scrumban?

Sören: Das ist eine Mischung aus Scrum und Kanban.

Roman: Wir haben unsere Freunde von ZWP befragt — ihr erinnert euch an den Scrum Master Medi?

Sören: Mit dem schönen Satz: früher scheitern, früher wissen.

Roman: Früher scheitern mit Scrum. Agil — früher scheitern. Tobias Göddecke und Medi haben uns tatsächlich erzählt, wie agiles Arbeiten bei ZWP funktioniert. Wir haben uns in der Lounge Projektleitung getroffen und uns einmal zeigen lassen, wie Scrumban funktioniert. Jetzt wollen wir das Wissen kurz teilen. Ich habe ihnen sehr gedankt, dass sie das überhaupt geteilt haben, denn sie geben damit auch ein bisschen Unternehmensgeheimnisse mit. Wir zeigen es hier nicht im Detail — es ist auch eher visuell hilfreich, wenn man es gesehen hat.

Sören: Ist das eine Eigenkreation? Also eine Kombination aus Scrum und Kanban?

Roman: Ja, das ist es wohl. Und es ist auch eine Eigenkreation, die ich da gesehen habe — auf einem digitalen Whiteboard.

Sören: Unserem Lieblingstool, Miro.

Roman: Es war Miro.

Sören: Es gibt auch noch Conceptboard. Wir sind nirgendwo verhaftet.

Roman: Überhaupt nicht, aber wir sind ein bisschen geschädigt von Dingen, die nicht funktionieren, deshalb vorsichtig mit Whiteboards. Auf jeden Fall haben wir uns angeguckt, wie sie damit arbeiten. Ich habe von Tobi gelernt, dass in Köln etwa 50 Prozent aller Projektleiter damit arbeiten würden.

Sören: Guter Schnitt.

Roman: Ich habe ein bisschen gelitten, als ich das gehört habe. Man denkt, da hat man so eine geile Methode, und dann nutzt nur die Hälfte sie.

Sören: Darüber könnten wir mal eine eigene Folge machen: wie man so eine Auswahl an Werkzeugen kanalisiert und einheitlich ins Unternehmen kriegt.

Wie ist das Scrumban-Board aufgebaut?

Roman: Es gibt eine standardisierte Struktur auf einem digitalen Whiteboard, die dort entwickelt wurde, die aber von den Teams wieder individualisiert wird. Wir haben uns eine angeschaut, die ein sehr erfahrenes Team schon lange so macht. Zuerst gab es einen Start-Bereich: Da waren die Vertragsinhalte zu sehen, das Ziel für die Leistungsphase, wo wir überhaupt stehen, wer die Partner sind, die Rollen und die Ziele. Die Rollen im Team sind also sichtbar und die Ziele geklärt.

Warum gibt es bei Scrumban keine festen Sprintlängen?

Roman: Wir haben einen Kalender mit Sprintterminen, in den eingetragen wird, bis wann die Sprints geplant sind. Interessant: Es gibt keine festen Sprintlängen, die sind nicht fixiert. Das ist eigentlich genau das, was Scrum ausmacht — feste Zyklen mit variablen Arbeitspaketen. Hier war es so: keine festen Zyklen, aber trotzdem variable Arbeitspakete.

Sören: Es ist ja diese Anpassbarkeit, über die man häufig nachdenkt — inwiefern kann ich eine Methodik überhaupt auf meine Arbeitsweise transferieren oder anpassen?

Roman: Man könnte das diskutieren. Ich finde diese festen Termine eigentlich sehr charmant, weil das Lösen aus den festen, fixen Terminen wieder zu unrhythmischen Dingen führt.

Sören: Im Zuge von Soziokratie und Organisationsentwicklung geht es ja genau darum, das Wiederkehrende zu finden — eine feste Struktur für die Retro, für das Daily, für andere Meetings, auf die man sich zum festen Zeitpunkt verlassen kann.

Roman: Genau, ein Punkt, an dem ich mich austausche, Hilfe bekomme, neue Aufgaben bekomme oder Aufgaben erledige. Die Dauer des Sprints wurde also gelockert, aber es gibt einen Kalender mit Sprintterminen: Bis wann wollen wir was innerhalb der Leistungsphase erreichen?

Sören: Das ist vielleicht auch besser auf unsere Planungsprozesse übertragbar, weil wir die Meilensteine eher zum Ende hin haben und nicht so über das ganze Projekt verteilt.

Wie funktioniert das Pull-Prinzip mit Swimlanes?

Roman: Dann gab es ein Backlog mit allen Aufgaben der Leistungsphase: Heizlastberechnung, Kühllastberechnung, Schema A, B, C und so weiter. Das ist ein Standard, der immer reinkopiert und nicht groß verändert wird — eine Übersicht, was zu tun ist. Und jetzt kommt das eigentliche Scrumban: das wesentliche Board, ein Kanban. In den Spalten stehen verschiedene Aufgaben-Status, von Backlog an. Backlog heißt hier, dass die Projektleitung gesagt hat: Das müsste im nächsten Sprint erledigt werden. In den Zeilen darunter stehen die verschiedenen Personen im Team — das war für mich neu, so hatte ich es noch nie gesehen.

Sören: Wenn du in die Templates schaust, findest du viele Kanban-Boards, die auch die Horizontalebene aufteilen — Swimlanes.

Roman: Genau, das waren Swimlanes, eine je Person. Die Projektleitung schiebt Aufgaben in die erste Spalte, ordnet sie aber nicht konkret jemandem zu, sondern sagt nur: ist wahrscheinlich am besten bei dieser Person platziert, kann auch zwischen Swimlanes wechseln — organisiert euch. Und jetzt kommt der interessante Part: Das Team holt sich im Pull-Prinzip die Aufgaben, wenn es bereit ist, und zieht sie in die nächste Spalte — Aufgabe jetzt in Arbeit. Dann kommen weitere Spalten: Arbeit steht/ist behindert, weil mir etwas fehlt; fast erledigt, muss noch ein Review bekommen; erledigt und abgenommen. Dieses Pullen fand ich sehr spannend: Ich werde nicht gezwungen, eine zugewiesene Aufgabe zu erledigen, sondern es gibt einen Vorschlag, und ich ziehe sie mir für den nächsten Sprint selbst.

Sören: Das ist der entscheidende Punkt — das Commitment: Ich habe nicht jemanden in der Projektrolle, der mir die Aufgaben zuweist, sondern ich ziehe mir die Aufgaben proaktiv selbst.

Wie werden dringende Aufgaben und Aufwände abgebildet?

Roman: Schwierig war wohl, dass es manchmal dringende Themen gibt — etwas wurde vergessen oder es muss schnell noch eine Variante verglichen werden. Diese Karten haben eine andere Farbe, das sind orange Kärtchen. Die schiebt die Projektleitung rein, und sie haben Vorrang — die schnellen Läufer. Da die Swimlanes nach Personen unterteilt sind, stehen sie nicht oben, sondern sind einfach orange, dann sieht man das. So aufregend war das gar nicht: ein Kanban mit horizontaler Unterteilung nach Personen, in den Spalten verschiedene Aufgaben-Status. Sobald das Team startet und diese Grenze überschritten ist, kommt der Scrum Master ins Spiel.

Sören: Eine Sache, die man mal ausprobieren und als Erweiterung des eigenen Werkzeugkoffers nehmen kann.

Roman: Das fortgeschrittene Team, das uns gezeigt wurde, war auch in der Lage, den Zeitaufwand der Aufgaben zu schätzen — sie haben auf ihre Kärtchen geschrieben, wie viele Stunden wohl drinstecken. Das hat nicht die Projektleitung gemacht, die hat nur die Aufgabe reingeschrieben; das Team hat sie gepullt und den Aufwand geschätzt. Das kenne ich auch so aus Scrum. Dafür braucht man wohl ein erfahrenes Team. Die Schätzung wird nicht so intensiv genutzt, aber man sieht cool: Hier sind noch zehn Aufgaben in Arbeit, die brauchen im Schnitt acht Stunden — schaffen wir das noch? Was haben wir gelernt: keine fixen Sprinttermine, Pull-Prinzip für die Aufgaben, die Projektleitung kann Dringlichkeit zeigen. Dringende Aufgaben haben nur eine andere Farbe, und Medi sagte, die sollten möglichst selten auftreten — je mehr orange Karten, desto eher funktioniert etwas nicht.

Sören: Wenn alles Prio 1 ist. Klassiker. Ich finde die Kombination aus beiden Methodiken aber spannend — auch als Denkanstoß, wenn man ein Thema gar nicht so in der Tiefe nutzt.

Für welche Projekte und Teams eignet sich Scrumban?

Roman: Es gab auch Fragen zum Scrumban. Etwa: Eignet sich das für jede Projektgröße? Die Antwort war: ja, schon. Sie haben zwar nur Projekte mit Baukosten von drei bis fünf Millionen Euro TGA, also eher größere Projekte. Aber es hängt nicht von der Projektgröße ab, sondern von der Teamgröße. Und welche Leistungsphase: zwei bis drei wurde als sehr sinnvoll empfunden, fünf gegebenenfalls.

Sören: Ich finde die Prinzipien dahinter sehr gut. Da könnte man — wenn wir über Teamkultur sprechen — daran arbeiten: Muss ich mehr Pull-Prinzipien anwenden, was Eigenständigkeit und Effizienz angeht? Und wenn ich so ein System anwende, um das zu befeuern: Passt das für mich zusammen?

Kann der Bauherr oder Generalplaner Scrumban vorgeben?

Roman: Die Projektleitung wird hier zum Product Owner — jemand, der die Bedürfnisse des Kunden reinbringt, aber nicht das Team leitet. Das Team leitet sich selbst, der Scrum Master unterstützt. Dann kam die interessante Frage, ob so ein System nicht nur fürs Büro selbst möglich ist, sondern auch für das gesamte Projekt — dass der Bauherr es vorgibt. Wir hatten einen Bauherrn von der Sprinkenhof GmbH in der Runde, der sagte: Ich kenne das. Es gab einen Nutzer, der das sehr intensiv gelebt und vorgegeben hat — das waren ITler, die kannten es nur so. Es hat aber nur mäßig funktioniert. Man braucht für alles ein einheitliches Verständnis, sonst erkennt nicht jeder den Mehrwert.

Der Mehrwert ist aber gegeben beim Generalplaner. Wir hatten eine Generalplanerin am Start, Katharina Lennartz, die sagte: Da funktioniert das ziemlich gut. Du kannst es vorgeben, bist als Hauptauftragnehmer eh in der Position und kannst die Nachunternehmer damit steuern: Jetzt müsste Folgendes getan werden, jetzt pullt mal. Das ist die geile Möglichkeit zu sagen: Ich gebe dir nicht genau vor, was du machen musst, aber das müsste jetzt passieren, damit es weitergeht.

Sören: Und über den Meilenstein sage ich am Ende des Sprints, dass ich es dann haben möchte. Ganz smart.

Roman: Über Software haben wir auch noch gesprochen. Es gab aber nicht das System, sondern wir lernen wieder: digitales Whiteboard und sich etwas selbst bauen. Dass auch Vertrag, Rollen und Ziele sichtbar sind, kriegst du in keiner Software so abgebildet — das ist individuell. Wir sind gerade dabei, Standard-Whiteboards für jedes Projekt zu bauen, und ich würde das mal ausprobieren. Meine Sprintplanung ist immer noch ein Thema — die funktioniert vielleicht mit Scrumban in Kombination besser, wenn man ein Aufgaben-Kanban Richtung Scrumban mit Pull-Prinzip legt. Schauen wir mal. Viel Spaß mit Scrumban, wenn ihr mal damit spielt.