Nudge am 14.10.2011

Scrum-Standups in Kanban-Workflows?

in Projektmanagement | Tags: Board, Kanban, Scrum, Standup, Workflow

Scrum und Kanban sind keine Gegensätze. Beide agilen Projektmanagement-Methoden lassen sich eigentlich wunderbar kombinieren. Allerdings nicht immer und überall. Letzte Woche kam mir eine Idee, das täglich Standup, was bisher nach Scrum verlief, etwas zu Kanban-isieren. Wie das geht, möchte ich Euch kurz vorstellen.

Master of Desaster

Zunächst ist es wichtig zu wissen, was das führende System ist. In einem IT-Unternehmen werden das sicherlich keine Papierzettel sein, sondern ein Ticket-System. Im Ticket-System, bei uns das JIRA, liegen die Aufgaben alle elektronisch vor und sind immer auf dem aktuellen Stand (offen, erledigt, abgelehnt etc). Man könnte also durchweg auch nur im JIRA arbeiten. Dort gibt es zum Beispiel seit den letzten Versionen auch agile Ansichten wie Boards und Burndown-Charts. Eins unserer Teams arbeitet zum Beispiel nur im JIRA und führen damit Standups durch.

Scrum-Standups

Die Standups nach Scrum verlaufen so: Alle Team-Mitglieder versammeln sich im Stehen. Das Stehen ist wichtig: Wenn einer stehmüde wird, ist das Meeting zu lang. Der Reihe nach beantworten alle Entwickler folgende drei Fragen:

1
2
3
1. Was habe ich gestern gemacht?
2. Was werde ich heute tun?
3. Was könnte mich davon abhalten?
1. Was habe ich gestern gemacht?
2. Was werde ich heute tun?
3. Was könnte mich davon abhalten?

Die letzte Frage benennt Schwierigkeiten, die der Projektleiter gleich mitnehmen kann, um diese, gegebenenfalls organisatorisch, zu lösen.

Standups synchronisieren also die Team-Mitglieder. Jeder weiß Bescheid, jeder braucht nur 3 Minuten, und der Tag kann beginnen. Voraussetzung ist natürlich, dass der Projektleiter, bei Scrum hier der Product Owner,  das Backlog (die Sammlung offener nächster Aufgaben) sauber aufbereitet und priorisiert hat. Das Backlog ist vor einem Sprint, also einem abgeschlossenen Entwicklungszyklus, mit dem Team zusammengestellt worden. Jeder kennt also den Umfang und die Zeitdauer der aktuellen Entwicklung. Jeder der Entwickler sollte zu 100% an diesem Projekt arbeiten.

Kanban-Boards

Anstatt wie bei Scrum eine fixe Zeitdauer, das Timeboxing, zu verwenden, setzt Kanban eher auf eine Optimierung des Arbeitsflusses, dem Workflow. Es eignet sich daher sehr gut für Teams, die an vielen Projekten kleinere Dinge umsetzen, wo man keine sauberen Sprints aufsetzen kann. Zum Beispiel das Thema Support kann damit gut unterstützt werden. Auch hier ist wichtig, dass der Projektleiter die Tickets vorher im Backlog priorisiert und eventuelle Unklarheiten in den Anforderungen auflöst. Im Gegensatz zu Scrum ist es aber nicht wichtig, periodisch über die nächsten Tickets zu sprechen: Ist die Zeit reif, d.h. Zeit für ein neues Ticket vorhanden, wandert es einfach durch den Workflow der Entwicklungsphasen: Entwicklung, QA, Test, Deployment oder ähnliches  – diese Phasen muss jedes Team für sich selbst finden.

Statt in einem PUSH-Verfahren die Tickets in die nächste Phase zu geben und einem Bearbeiter zuzuweisen, setzt Kanban auf ein PULL-Prinzip: Tickets werden immer im Prozess von rechts nach links abgearbeitet. Ein Kanban-Board visualisiert diese Phasen für alle. Hier nimmt man den Overhead, Tickets nochmals auf Papier zu bringen, in Kauf, um die Synchronisation des Teams deutlich zu erleichtern. Außerdem erlaubt das Board, sich auf die im Moment wesentlichen Dinge zu konzentrieren. Das geht eventuell bei verteilten Teams vielleicht nicht besonders gut. Für Teams aber, die im gleichen Raum sitzen, ist ein Kanban-Board eine schöne und motivierende Sache. Ein Ticket umzuhängen, ist gleichermaßen Belohnung für die getane Arbeit wie auch Ansporn für andere, die Fackel der Wertschöpfung weiterzutragen.

Scrum-Standups im Kanban-Workflow

Das Magento-Team von Netresearch führte die Standups bisher nach Scrum durch. Wir standen vor dem Kanban-Board und sagten unsere Sprüchlein auf. Allerdings gab es immer kleine Hakeligkeiten: Wenn ein Entwickler sagte “Heute hätte ich das vor.”, so interventierte ich als PL oft mit “Warte mal, da wäre glaube ich dies hier wichtiger.” oder “Das sollte eigentlich er machen.” Grund ist, dass dieses Jeder-Nacheinander die nächsten Aufgaben verplant, obwohl noch nicht alle wissen, wer was am Vortag gemacht hat und wie der aktuelle Teamstand ist. Daher sollten zunächst alle den gestrigen Tag Revue passieren lassen, bis wir wissen, was tatsächlich die wichtigste Aufgabe des Tages ist. Auf Kanban-Boards bedeutet das, die Tickets an die richtige Stelle zu bringen. Außerdem ist bei Kanban das Pull-Prinzip führend vor der Sicht, was jeder einzelne Entwickler tut. Die Beantwortung der Scrum-Fragen führte dazu, dass wir auf verschiedene Tickets am Board zeigten – letztlich blieb so der Überblick oft vermisst. Wir brauchten wiederum kleine Notizblöcke, in denen jeder seine Tagesaufgaben notierte (das mag in Situationen, wo nur 1 Projekt vorherrscht, kein Problem sein).

Die erste Frage des Tages sollte also reihum lauten: Wer tat was? Im Kanban-Prinzip von hinten nach vorn durchgehend, wird die Ticket-basierte Vorgehensweise zu einem “Wer tat es?“. Der letzte Bearbeiter eines Tickets kann kurz dazu etwas sagen, zum Beispiel Schwierigkeiten benennen. Und die nächste Frage muss folgerichtig lauten: “Wer tut es?“, also wer wird dieses Ticket weitertragen? So kommt derjenige Wert, welcher im Prinzip schon fast beim Kunden ist, als erstes Aufmerksamkeit. Ein fertig entwickeltes und getestetes Ticket wird zum Beispiel ausgerollt. Und das sorgt wiederum sowohl für Freude beim Kunden als auch für eine Kopfklarheit der Entwickler: Dinge eher abschließen und sich auf die nächsten Schritte konzentrieren können.

Das Board ist also eine Art Mikrokosmos, ein Ausschnitt aus dem riesigen Universum des Ticket-Systems. Für die Position dieser Konzentrations-Lupe ist der Projektleiter zuständig, er steuert die Tickets in das Board ein und verarbeitet sie danach weiter: Kunden oder Geschäftsführung informieren, Abrechnungen triggern, die nächsten Schritte mit dem Kunden absprechen oder schlicht Projekte und Sprints im Ticket-System schließen. Wohlbemerkt ist der Entwickler natürlich angehalten, das Ticket im Ticket-System stets aktuell zu halten: beispielsweise das Setzen des Ticket-Status, zum Loggen von Notizen, der Zeiterfassung oder Ablage von Mails an und vom Kunden.

Übersicht inklusive

Während der Benennung von “Wer tut es?” schreiben wir rechts an einer freien Stelle am Board mit, welcher Entwickler welche Tickets bearbeiten wird. Dadurch entstehen kleine Listen der Tagesaufgaben pro Team-Mitglied. Jeder belohnt sich selbst mit kleinen Häkchen daneben und machen es mir als Projektleiter am nächsten Tag ganz einfach, eine Art Mini-Controlling durchzuführen. Tickets, die nicht bearbeitet wurden, falls deutlich schneller auf. Mit denen muss irgendetwas nicht stimmen – ein wichtiger Impuls für mich als Projektleiter. Der spürbare Effekt in der Runde ist, dass die Standups nicht mehr so stagnieren, sondern spielerischer, konstruktiver Natur sind. Und das macht richtig Spaß.


Das mark ich mir: Alltagz Mr Wong Yigg Del.icio.us Yahoo MyWeb Blinklist Google folkd
 

Leave a Reply

Your email address will not be published. Required fields are marked *