Noch im Sommer herrschte das Chaos: Unsere Lieferzeiten waren unklar, das Ticketmanagement wurde von uns selbst durchgeführt und die Fachabteilung, die am lautesten brüllte, hat ihr Ticket als erstes umgesetzt bekommen. Immer wieder erwischten wir uns dabei, wie wir an viel zu vielen Tickets gleichzeitig arbeiteten und die Zeit für technische Verbesserungen auch auf der Strecke blieb.
Es war Zeit, etwas zu ändern!
Unser Team.
Die Zusammensetzung unseres Teams ist dabei noch recht neu. Insgesamt sind wir zu viert. Zwei Entwickler sind frisch hinzugekommen und neben mir gibt es noch einen langjährigen Entwickler, der sich am Besten in den Systemen auskennt und der Wissensträger in unserem Team ist.
Kanban-Team, Fotorealistische Darstellung.
Die Aufgaben.
Unsere Aufgaben sind ziemlich unterschiedlich. Hätten wir nur neue Features zu entwickeln, bzw. Bugfixes durchzuführen, könnten wir auch bequem mit Scrum arbeiten. Allerdings kümmern wir uns auch um das Tagesgeschäft, nehmen noch an einem Projekt teil und ein CMS hat unser Portal leider auch nicht. – Ist ja schließlich historisch gewachsen und es herrscht immer chronischer Entwicklermangel, um das Portal neu aufzusetzen.
Wie alles besser wurde.
Als erste Verbesserung wurde personell aufgestockt und wir bekamen einen Applikationsmanager. Dieser übernahm ab jetzt die Koordination der Tickets und fungierte als Proxy zwischen unserem Entwicklerteam und den Fachabteilungen. Lediglich direkte Absprachen zu Tickets führten wir mit den Fachabteilungen zusammen.
Als zweite Verbesserung entdeckten wir Kanban für uns. Endlich konnten wir unsere Lieferzeiten messen und bekamen eine Übersicht über alle aktuell bearbeiteten Tickets, den „Work In Progress“ (WiP). Wir definierten uns also unsere Prozessschritte und kategorisierten unsere Aufgaben, in dem wir sogenannte „swim lanes“, also abgetrennte Bereiche für verschiedene Aufgabentypen, erstellten. So sah unser Board daraufhin aus:
Wir haben uns entschieden, die Analyse nicht als Prozessschritt, sondern als eigene swim lane zu definieren. Denn nicht jede Aufgabe muss in die Analyse gehen (z.B. Content Changes) und wir wollen altmodische, lange Analysephasen vermeiden und lieber in agilen, kleinen Häppchen liefern. Gleichzeitig können wir später mit Limits vermeiden, dass wir nur noch analysieren. Ansonsten unterteilen sich unsere Aufgaben in:
Bugfixes in die später auch kritische Blockertickets aus dem Tagesgeschäft einfließen können
Business Support d.h. Content Changes, Auswertungen, Sonstiges
Projekt größere Feature Entwicklungen aus dem Projekt
RFC (Request for Change) größere Feature-Anfragen aus dem Unternehmen, bei denen das Portal nur ein Teil des Feature-Implementierung ist
Unsere Prozesse gliedern sich in Ready, Implement, Review, Deployment und Done. Alle Tickets zwischen Implement und Deployment bilden den o.g. Work in Progress .
Entschuldigung, die Tickets, bitte!
Es gibt viele Stakeholder für unser Portal und damit prallen jede Menge unterschiedlicher Voraussetzungen und Anforderungen aufeinander. Die Priorisierung unserer Tickets haben wir an die Fachabteilung abgetreten, die auch das Projekt, an welchem wir teilnehmen, betreut. Das hat den Vorteil, dass wir allen anderen Anforderer an diese verweisen können und die Tickets nun aus einer Hand priorisiert werden. Wir achten als Entwickler darauf, dass die Tickets, die an das Board kommen, in jeder swim lane immer ungefähr denselben Umfang, also die gleiche Mächtigkeit, besitzen. Folgende Ticketarten haben wir uns für unser System definiert:
Jede Farbe steht für eine verschiedene Ticketart.
Grün Standardtickets mit normaler Priorität
Gelbe Tickets Diese Tickets besitzen eine zeitliche Vorgabe und haben eine leicht erhöhte Priorität.
Beispiel: Zum 01. Januar 2013 ändern sich gesetzliche Vorschriften, daher müssen die Anpassungen bis zu diesem Datum umgesetzt sein.
Blaue Tickets Technische Tickets, die vom Team priorisiert werden, um technische Schulden abzubauen. Diese Tickets sind notwendig, haben aber keinen wirklichen Business Value für die priorisierende Fachabteilung.
Orangene Tickets Blocker-Tickets mit höchster Priorität, d.h. man arbeitet solange ausschließlich an diesen Tickets, bis diese abgeschlossen werden können.
Weiße Tickets Tickets mit unklarem Business Value deren Bearbeitungszeit teilw. Ebenfalls nicht abschätzbar ist. Sie können bei uns auch Abhängigkeiten zu Fremdabteilungen sein, die nicht genügend Ressourcen haben, um mit unserer Entwicklungsgeschwindigkeit mitzuhalten. (Heißen „intangible“ in der Fachliteratur)
Jedes Ticket, welches sich in progress befindet, ist außerdem einem Entwickler zugeordnet. Dieser muss nicht zwingend alleine an dem Ticket arbeiten, sondern hat für dessen Umsetzung den Hut auf und kümmert sich um den Fortschritt.
Die Tickets können aus verschiedenen Gründen in ihrem Fortschritt blockiert werden, beispielsweise wenn man bei der Implementierung auf wichtiges Feedback durch die Fachabteilung wartet und der Kollege evtl. an dem Tag nicht da ist. Die Bearbeitung ist also zunächst unmöglich. Dieser Zustand wird bei uns nicht, wie in der gängigen Literatur empfohlen, durch eine 45° Drehung des Tickets symbolisiert. Wir hängen kleine rosa Fähnchen mit einer kurzen, stichpunktartigen Begründung der Blockierung daran.
Arbeitsrichtung: Von rechts nach links und von oben nach unten.
Die Arbeitsrichtung beim Kanban erfolgt mit der „Pull-Strategie“ und von rechts nach links. Beendet man z.B. die Implementierungsphase eines Tickets, schiebt man es nicht in Review, sondern holt sich das Ticket im Review erst, wenn man die notwendigen Kapazitäten dafür frei hat.
Gesamtansicht des Kanban Boards mit den verschiedenen Ticket- und Limit-Arten.
Außerdem arbeiten wir innerhalb eines Prozessschrittes innerhalb einer swim lane von oben nach unten. Das machen wir, in dem wir die älteren Tickets innerhalb dieses Bereiches nach oben hängen und die jüngeren darunter. Wir wollen hier natürlich die Tickets zuerst bearbeiten, die es schon länger gibt, um insgesamt die Durchlaufzeit der Tickets zu reduzieren.
Die Arbeitsrichtung ist auch eine wichtige Voraussetzung für die Beachtung der Limits:
Die Einführung von Limits hat beim Kanban gleich mehrere Vorteile: Wir verkürzen die Durchlaufzeit und erhöhen die Qualität unserer Arbeit, indem wir weniger Kontextwechsel zwischen den Tickets haben und deshalb nicht mehr so abgelenkt sind. Wir haben für uns folgende Limits eingesetzt:
Spaltenlimit, z.B. bei den Reviews
Wir können nicht viel mehr als drei Tickets gleichzeitig im Review behandeln oder die Fachabteilungen bei den Reviews betreuen.
Blocklimits
Tickets in den swim lanes „RFC“ und „Projekt“ haben ungefähr dieselbe Mächtigkeit und gehören im Gegensatz zu Bugfixes zu den größeren Tickets. Die Aufgaben werden inhaltlich voneinander getrennt, aber über die Limits dann doch wieder zusammen gesteuert.
Technikticket-Limits
Diese Tickets priorisieren wir uns ja selbst (siehe oben). Die technischen Schulden sind über die Jahre größer geworden. Dennoch wollen wir uns auch hier einschränken und nicht zu viele Schulden auf einmal abbauen oder in Gefahr laufen, nur noch Refactorings durchzuführen und keine Zeit mehr für fachliche Anforderungen zu haben.
Personenlimits
Diesen Punkt haben wir noch nicht wirklich umgesetzt, aber angedacht. Unser erfahrenster Entwickler mit den größten Kenntnissen aller Systeme bekommt alle Tickets, weil er diese ja am schnellsten erledigen kann. Dies ist jedoch die falsche Vorgehensweise. Besser wäre es, wenn er ein Limit von z.B. maximal drei Tickets hat. Außerdem sollte er auch die Tickets mit den nicht so erfahrenen Entwicklern zusammen umsetzen, damit sich sein Wissen im Team verbreitet.
Hands off – Wir haben Meeting!
Um neue Tickets in das Kanban einfließen zu lassen, führen wir einmal wöchentlich am Dienstag ein Befüllungsmeeting durch. Eingeladen sind neben den Entwicklern und dem Applikationsmanager auch noch Vertreter der Fachabteilungen und des Projekts, über welches ja priorisiert wird. So entsteht Transparenz unserer Vorgehensweise gegenüber den Stakeholdern, wir können während des Meetings noch über die Prioritäten diskutieren und ggf. Fragen zu den Tickets klären.
Um als Entwickler vorbereitet zu sein, treffen wir uns vor der Befüllung noch zu einem Backlog Grooming, welches wir aus dem Scrum übernommen haben. Wir gehen gemeinsam die offenen Tickets im Backlog durch und besprechen diese grob. Auch dieses Meeting führen wir im wöchentlichen Rhythmus durch, was den Vorteil hat, dass die Meetings nicht zu lange werden, weil man die neuen Tickets inkrementell abarbeiten kann und nicht jedes Mal alle Tickets ansehen muss.
Unseren täglichen, aktuellen Stand besprechen wir im klassischen Daily Standup um 10 Uhr. Sollten sich im Standup weitere Diskussionspunkte herauskristallisieren, klären wir diese (ebenfalls klassisch) mit Anschlussmeetings, an denen dann zwei bis drei Leute zusammenkommen und diskutieren können.
Zuletzt tauschen wir uns in einer wöchentlichen Retrospektive im Team aus und analysieren dabei die Blockierungen der Tickets, sofern diese aufgetreten sind. Dieses Meeting nutzen wir auch, um den Kanbanprozess weiter für uns zu verbessern – im Kaizen-Stil halt.
Alles ist gut.
So hat uns Kanban geholfen, unsere Leistungsfähigkeit zu steigern und Ordnung in unsere Arbeit zu bringen. Auch die Arbeitsatmosphäre hat sich deutlich verbessert und die Fachabteilungen sind zufriedener mit unserer Arbeit.
Im nächsten Blogartikel zu Kanban erzähle ich davon, wie man Aufwandsschätzungen durch Aufwandsprognosen substituiert, die auf gewonnenen Erfahrungen basieren.
Jens Broos betreut seit 2011 Kundenprojekte für die Mayflower GmbH.
Durch sein Studium der Medieninformatik und als „echter“ Pfadfinder kennt er sowohl die technischen Anforderungen an große Softwareprojekte, als auch die zwischenmenschlichen und organisatorischen Bedürfnisse agiler Teams.
Als Agile Coach berät er Entwickler und Kunden vor Ort bei der Umsetzung und Integration agiler Methoden und Prozesse.
Die gemeinschaftliche Bearbeitung von Themen sind seine Passion.
Verpasse keinen Artikel mehr und lass Dich von uns benachrichtigen, sobald es etwas Neues im Blog gibt.
Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.
Schreibe einen Kommentar