Wie Sie die Leistung von Scrum-Teams mit Kanban verbessern

Dieser Blogpost ist in Zusammenarbeit mit Jeroen Willemsen und Jasper Sonnevelt entstanden.

In diesem Beitrag werfen wir einen Blick auf ein praktisches Beispiel für die Umstellung eines Scrum-Teams auf Kanban. Wir werden einige Fallstricke ansprechen und erörtern, wie diese umgangen werden können. Damit bieten wir Ihnen zusätzliche Einblicke, um Ihre agile Arbeitsweise voranzubringen.

Das Beispiel Zu der Zeit, als wir zu diesem Projekt stießen, arbeiteten drei Scrum-Teams gemeinsam an der Entwicklung eines großen Softwareprodukts. Die Teams teilten sich einen Product Owner (PO) und ein Backlog und hatten gerade ihr MVP veröffentlicht. Nun gingen Fehlerberichte ein und die Scrum-Teams sahen sich verschiedenen Problemen gegenüber:

• Die Entwickler machten in jedem Sprint große Fortschritte, so dass der PO viel Arbeit in das Backlog stecken musste, um einen ausreichend großen Arbeitsvorrat zu erstellen.neue Fehler kamen ans Licht, als das Produkt angenommen wurde. Die Ablage und Behebung dieser Fehler und die Überwachung des Fortschritts nahmen den PO sehr in Anspruch. Die Behebung jedes Fehlers im nächsten Sprint reduzierte die Reaktionszeit des Teams.
• Die Priorisierung der Fehlerbehebung und der neu angeforderten Funktionen wurde schwierig, da der PO zu viele Interessengruppen zu verwalten hatte.
• Der Product Owner sah Kanban als eine mögliche Lösung für diese Probleme. Er überzeugte das Team, Kanban einzuführen, um diese Probleme zu lösen und eine bessere Arbeitsweise zu ermöglichen.

Zu den umgesetzten Praktiken gehören:

• Kein Sprint-Replenishment-Rhythmus mehr (Planung & Backlog-Verfeinerung);
• Ein Work in Progress (WIP) Limit.

Infolgedessen begann die Qualität des Backlogs zu sinken. Es wurden weniger Informationen zu einer Story aufgeschrieben und die Entwickler nahmen sich nicht die Zeit, die richtigen Fragen an den PO zu stellen. Das WIP-Limit maximierte den Umfang der Arbeit, die das Team übernehmen konnte. Dies führte dazu, dass sie sich auf die aktuellen, manchmal unklaren und zu komplexen Stories konzentrierten. Aus diesem Grund arbeiteten die Entwickler weiter an ihren aktuellen Aufgaben und stellten dabei Annahmen auf. Diese Annahmen konnten manchmal zu widersprüchlichen Erkenntnissen führen, da die Entwickler an den Stories arbeiteten, während sie gleichzeitig von verschiedenen Interessengruppen beeinflusst wurden. Dies führte zu einer Fehlanpassung.All diese Maßnahmen führten zu einer geringeren Burn-Down-Rate, weniger Vorhersehbarkeit und damit zu nervösen Stakeholdern. Und nach ein paar Wochen beschloss der PO, die Umstellung auf Kanban abzubrechen und zu Scrum zurückzukehren. Letzteres war aber vielleicht gar nicht nötig, damit das Team erfolgreich war. Schließlich kommt es darauf an, wie Sie Kanban implementieren. Es fehlten zum Beispiel ein paar Schlüsselelemente. Unserer Erfahrung nach haben Teams, die erfolgreich sind (würden), auch implementiert:

• Prognosen auf der Grundlage von historischen Daten und Simulationen: Scrum-Teams verwenden Planning Poker und Velocity, um Vorhersagen über den Umfang der Arbeit zu machen, die sie in einem Sprint erledigen können. Wenn die Sprintkadenz aufgehoben wird, wird dies schwieriger. Die Praktiken der Kanban-Methode besagen, dass durch die Verwendung historischer Daten in Simulationen die gleiche und wahrscheinlich sogar eine höhere Vorhersagbarkeit erreicht werden kann.
• Richtlinien für die Priorisierung, WIP-Überwachung und Übergabekriterien: Kanban verlangt von allen Beteiligten ein sehr hohes Maß an Disziplin. Richtlinien werden hier helfen. Im Falle dieses Teams hätte es sehr davon profitiert, wenn es klar definierte Richtlinien für Prioritäten und Prioritätensetzung gegeben hätte. Zum Beispiel: Wer kann (und darf) Prioritäten setzen? Wie kann das Team erkennen, was die höchste Priorität hat? Gibt es verschiedene Klassen von Dienstleistungen, die wir identifizieren können? Und wie behandeln wir diese? Das Gleiche gilt für WIP-Limits und Übergabekriterien. Wir verwenden in Scrum-Teams immer eine Definition von Fertig und eine Definition von Erledigt. Diese in einem Kanban-Team beizubehalten, ist eine sehr gute Praxis.
• Ein Feedback-Zyklus zur regelmäßigen Überprüfung von Daten und Prozessen: Während Scrum nach jedem Sprint eine Retrospektive verlangt, ist so etwas bei Kanban nicht ausdrücklich vorgesehen. Kanban schreibt lediglich vor, dass Sie Feedback-Schleifen einrichten sollten. Wenn ein Unternehmen mit der Einführung von Kanban beginnt, ist es von entscheidender Bedeutung, dass es die Implementierung, die Daten und den Prozess in regelmäßigen Abständen überprüft. Das ist besonders in den ersten Wochen wichtig: Alle Beteiligten müssen sich an die neue Arbeitsweise gewöhnen. Auch die Richtlinien sollten überprüft werden, da sie möglicherweise angepasst werden müssen, um dem Team einen optimalen Arbeitsablauf zu ermöglichen.

Das Schwierige an Kanban Was die meisten Leute denken und vor Augen haben, wenn sie über Kanban sprechen, ist die Einführung von WIP-Limits auf ihrer Tafel, das Hinzufügen von Spalten (außer To do, In Progress, Done) und die Einstellung von Sprints. Und hier liegt eines der Probleme. Für Unternehmen, die es gewohnt sind, mit Scrum zu arbeiten, ist die Abschaffung von Sprints eine sehr unnatürliche Angelegenheit. Es fühlt sich an, als würde man die Vorhersehbarkeit und das regelmäßige Feedback aufgeben. Und anstatt die Organisation ein bisschen besser zu machen, haben die Leute das Gefühl, einen Schritt zurück gemacht zu haben. Das Schwierige an Kanban ist, dass es Ihnen nicht wie Scrum eine klare Lösung für Ihre Probleme bietet. Kanban ist eine Methode, die Ihnen hilft, die Probleme in Ihrer Organisation auf eine Weise zu lösen, die am besten zu Ihrem Kontext passt. Zum Beispiel: Sie sagt Ihnen, dass Sie viele Dinge visualisieren sollen, gibt aber nur Beispiele dafür, was Sie visualisieren könnten. Typischerweise visualisieren Teams und Organisationen ihre Prozesse und Arbeits(typen). Um es zusammenzufassen:

• Kanban nutzt den aktuellen Prozess und erzwingt keinen eigenen Prozess. Daher erfordert es ein höheres Maß an Disziplin, sowohl von den Teammitgliedern als auch vom Rest der Organisation. Wenn Sie sich dessen nicht bewusst sind, wird die Einführung von Kanban nur zu Chaos führen.
• Kanban sagt nichts über die Häufigkeit des Nachschubs (Spalte To Do) oder die Häufigkeit der Vorführung aus.

Empfehlungen:

• Implementieren Sie Prognosen auf der Grundlage historischer Daten und Simulationen, Richtlinien für die Priorisierung, WIP-Limits und Übergabekriterien sowie einen Feedback-Zyklus zur regelmäßigen Überprüfung von Daten und Prozessen.
• Definieren Sie klare Richtlinien für die Zusammenarbeit. So schaffen Sie Transparenz und Vorhersehbarkeit.
• Die Scrum-Zeremonien laufen in einem Rhythmus ab, der für die Beteiligten sehr leicht zu verstehen und zu erlernen ist. Denken Sie daran, wenn Sie Kanban-Richtlinien entwerfen.