Worum geht es?
Firmen und Menschen, die sich mit dem Thema “Agilität” beschäftigen, setzen sich früher oder später auch mit dem Thema “Methoden und Frameworks” auseinander.
- Was gibt es für Möglichkeiten?
- Was sind die Unterschiede?
- Wann können wir was einsetzen?
In diesem Blogbeitrag möchte ich ein Beispiel aufzeigen, wie ein Team von Scrum auf Kanban wechselte.
Der Kontext
Die Firma publiziert Nachrichten auf Web, Mobile und Sozialen Medien. Zur Erstellung dieses Inhalts wird ein Enterprise Content-Management-System eingesetzt, welches entsprechend der Nutzerbedürfnisse von der internen Informatikabteilung angepasst wird.
Das Team
Das Team bestand vor der Umstellung von Scrum auf Kanban aus einem Product Owner, einem Scrum Master und einem 13-köpfigen Entwicklungsteam aus Software Entwicklern, Testern und Betriebsspezialisten. Diese arbeiteten phasenweise als ein grösseres Scrum Team, sowie auch in zwei Scrum Teams, um unterschiedliche Projekte / Schwerpunktthemen zu bearbeiten.
Meine Rolle
Aufgrund der kurzen Kündigungsfrist des Product Owners suchten sie jemanden der schnell starten konnte und ich durfte diese Rolle übernehmen. Mit meinem Hintergrund als Agile Coach habe ich initial das Augenmerk auf die Prozesse gelegt. Wie wurde Scrum umgesetzt? Was lief gut, was nicht und wie sah es mit der Zufriedenheit im Team aus? Als Input dafür habe ich die Outputs aus den vergangenen Retrospektiven genommen, sowie Gespräche mit den Teammitgliedern, dem Scrum Master und dem IT Leiter geführt.
Die Projekte
Eine der Erkenntnisse durch die Gespräche und die Visualisierung der Epics war, dass das Team an zu vielen verschiedenen Projekten arbeitete. Die Aufteilung in 2 Scrum Teams war kontraproduktiv, da der Know-How-Transfer innerhalb des Gesamtteams kaum stattgefunden hat. Zudem litt die Motivation einzelner Teammitglieder, da sie nicht frühzeitig in Neuentwicklungen einbezogen wurden.
Die Methode
Beim Arbeiten nach Scrum arbeitete das Team in anfänglich in dreiwöchigen, später einwöchigen Sprints und alle Meetings wurden eingehalten. Die Produktinkremente wurden nach Bedarf veröffentlicht.
Der Scrum-Zyklus
Die Pain-Points
- Viele Teammitglieder waren unzufrieden mit der Meeting-Struktur:
- zu viele Meetings in zu kurzen Zeitabständen
- zu lange Meetings
- zu grosse Teilnehmerzahl für zielgerichtete Diskussionen (z.B. im Refinement)
- Sie waren unzufrieden mit dem Austausch zwischen der IT und den Nutzern
- Als Product Owner hatte ich grosse Mühe eine Übersicht zu bekommen wer woran arbeitet
- Zudem war es schwierig die unterschiedlichen Tätigkeiten zu strukturieren und zu priorisieren
Der Change
Ich bin der Meinung, dass ein Weglassen von Meetings keine Lösung ist. Die Themen, welche die Scrum Meetings behandeln, sind alle von Relevanz. Ich habe daher den Vorschlag eingebracht den Scrum-Prozess auf einem Kanban-Board abzubilden und nach Bedarf die Meetings durchzuführen. Wir liessen unseren Meetingblock am Mittwochvormittag bestehen und schauten jeweils, wo es Klärungsbedarf gab. Folgende Fragestellungen waren dafür sehr hilfreich:
- Müssen wir neue Tickets verfeinern (Refinement)?
- Brauchen wir ein Planning mit dem gesamten Team?
- Gibt es allgemeine Themen (Prozess, Team, Release, Testing, Priorisierung oder Zusammenarbeit), die wir besprechen bzw. verbessern müssen?
So konnten wir als Team entscheiden und nutzten die Meetings nach Bedarf.
Die Umstellung
Zunächst haben wir eine Kanban-Schulung gemacht, worin dem Team die Prinzipien und Praktiken von Kanban vermittelt wurden. Das erste Prinzip von Kanban lautet “start where you are”. Das haben wir eingehalten, indem wir nichts am Prozess geändert haben. Wir schufen mehr Transparenz durch die Visualisierung auf einem Kanban Board. Das Board half dabei zu erkennen, wie die Arbeit durch den Prozess (Spalten) fliesst. Wichtig dafür ist eine WIP-Limite (Einschränkung der Arbeit, die gleichzeitig in einem Arbeitsschritt (Spalte) bearbeitet werden darf) zu definieren.
Das Kanbanboard
Fazit des Teamleiters & Scrum Masters nach sieben Monaten mit Kanban:
Das Team ist motivierter und der Knowhow Austausch im Team wurde massiv verbessert. Die Meetings werden genau dann durchgeführt, wenn es vom Arbeitsprozess und -fortschritt Sinn macht und nicht nach einem sturen Raster. Der Fortschritt ist durch die Visualisierung auf dem Kanban Board offensichtlicher. Durch die physische Abbildung auf dem Board findet der Austausch wesentlich proaktiver statt, als würde nur via Jira gearbeitet.
Die wichtigsten Erfolgsfaktoren aus seiner Sicht
- physisches Boards trotz Remotework (Schweiz, Deutschland und Singapur)
- fixes Daily, aber flexible Meetingstruktur ohne auf die elementaren Meetings zu verzichten
- gemeinsame Analyse / Groomingphasen der beteiligten Personen
- Konsequentes Einhalten des WIP
Dank der Visualisierung und der Retrospektiven, welche Bestandteile von Kanban sind, wurden auch Qualitätsmassnahmen wie Peer Code Reviews & Pair Programming vermehrt.
Als PO finde ich die Arbeit mit Kanban sehr hilfreich. Die Transparenz anhand des Boards helfen mir in der Kommunikation mit den Stakeholdern, als Argumentationsgrundlage für die Priorisierung und vor allem für die Planung und Vorbereitung der laufenden sowie der künftigen Themen.