Walk the Board: Effektives Arbeiten mit Task-Boards in Software-Projekten
In Software-Projekten, die mit Tools wie Jira oder Azure DevOps verwaltet werden, ist es üblich, Aufgaben und User Stories auf einem Board zu visualisieren. Dieses Board hilft dem ganzen Team, den Stand der Arbeit zu verfolgen und eventuelle Engpässe im Workflow zu identifizieren. In täglichen Standup-Meetings wird aufgrund des Boards der Fortschritt der aktuellen Entwicklungs-Iteration besprochen.
Wie man in einem agilen Projektumfeld mit einem solchen Task-Board arbeitet, um nicht nur Output sondern Outcome zu liefern und nicht in ein blosses Status-Reporting verfällt, zeige ich in diesem Blogbeitrag.
Die meisten Software-Teams, die in Iterationen arbeiten, nutzen ein Task-Board in irgendeiner Form. Diese verfügen über mehrere Spalten, die den aktuellen Status einer Aufgabe repräsentieren. Im einfachsten Fall genügen drei Spalten TODO, DOING und DONE. Je nach Projekt-Setup können am Anfang noch weitere Spalten für die Design- und Refinement-Phasen stehen. Am anderen Ende können Spalten für das Testing oder die Abnahme durch den/die Product Owner oder andere Personen eingefügt werden. Zusätzlich hat man die Möglichkeit, jedem Item auf dem Board eine Person zuzuweisen, die gerade an der entsprechenden Aufgabe arbeitet.
Shared Ownership
Das gesamte Team ist für die Erfüllung der Aufgaben zuständig. Daher werden User Stories (oder Bugs oder Issues) keiner einzelnen Person zugewiesen. Das Team committed sich zu Begin einer Iteration auf einen Arbeitsumfang, den es bewältigen will und kann. Sobald eine neue Aufgabe angegangen wird, wird diese auf konkrete zu erledigende Task heruntergebrochen. Auch während der Umsetzen können weitere Task hinzukommen, sobald sich herausstellt, das weitere Arbeiten notwendig sind. Diese Sub-Task werden nun von einzelnen Personen bearbeitet und diesen auch im Board zugeordnet. An einer Story können so durchaus mehrere Personen parallel arbeiten. So behält man den Überblick, welche Aufgaben wie viele Personen bindet.
Damit ist jeder im Team für die Erfüllung der aktuell aktiven Aufgaben verantwortlich. Es gibt im gesamten Prozess keine “meine” und “deine” Stories. Ist man mit seinem aktuellen Task fertig, kann man sich einer anderen Story anschliessen. Erst, wenn kein weiteres parallels Arbeiten sinnvoll möglich ist, beginnt man mit der Umsetzung einer neuen Story.
Priorisieren
Wie entscheide ich, welchen Task ich als nächstes angehe? Durch die Shared Ownership für den gesamten Iterations-Umfang, habe ich keine “eigenen” Stories, die ich abzuarbeiten habe. Um nicht wahllos mit der nächsten Story zu beginnen, ist es wichtig, die aktuell auf dem Board stattfindenden Arbeiten zu priorisieren. Stories, die weiter rechts auf dem Board liegen, sind wichtiger als solche weiter links. Diese sind also immer von höherer Priorität. Befindet sich eine Story in der Spalte TESTING, nehme ich mir diese vor und teste sie. Anstatt einer Spalte TESTING kann man auch einfach einen Sub-Task aufs Board legen. Befindet sich eine Story in der Spalte DOING, arbeite ich an dieser Story mit. Erst wenn keine Stories mehr auf der rechten Seite des Boards übrig sind und kein paralleles Arbeiten an aktiven Stories möglich ist, wird mit der Arbeit an einer neuen Aufgabe begonnen.
Im Kanban-Framework gibt es dafür das Work in Progress Limit.
Der Hintergrund dieses Vorgehens ist einfach: User Stories, die nicht fertig, also im Status DONE sind, haben für das Produkt keinen Mehrwert. Eine abgeschlossene Story ist wertvoller als fünf angefangene. Auch ein “fast fertig” ist kein “fertig”.
Stop Starting, Start Finishing
Walk the Board
Oben haben wir gesehen, dass wir unser Task-Board von rechts nach links abarbeiten. Dies gilt auch für unsere täglichen Sync-Meetings mit dem/der Product Owner. Wir gehen das Board von rechts nach links durch, klären welche Arbeiten umgesetzt sind und abgenommen werden können. Hier genügt es, wenn eine Person über das Board führt. Es muss sich nicht jeder zu seinen aktuellen Tätigkeiten äussern. Es geht nicht darum, zu rechtfertigen, womit man den letzten Arbeitstag verbracht hat oder zu zeigen, wie weit man mit seiner “eigenen” Story gekommen ist. Treten Probleme auf, wird als Team diskutiert, wie man zu einer Lösung kommt.
Mit diesem Vorgehen schafft man es, auch in stressigen Situationen den Fokus zu bewahren und für eine kontinuierliche Weiterentwicklung des Produktes zu sorgen.