„Und denken Sie daran: Egal, wohin Sie gehen, Sie sind da.“
– Konfuzius

Vor fast zwei Jahren kam ich als Agile Coach zu PagerDuty , obwohl ich nur wenig Erfahrung mit Kanban-Delivery-Teams hatte. Ich begann mit dem Coaching von zwei Scrum-Teams, aber sobald meine Teams erfuhren, dass ihre Kollegen, die Kanban verwendeten, zufriedener und leistungsfähiger waren, drängten sie auf den Wechsel.

Heute sind hier fast alle Lieferteams von Scrum auf Kanban umgestiegen. Doch bevor wir uns damit befassen, warum die Teams auf Kanban umgestiegen sind, wollen wir über die Kultur sprechen, die ihnen diesen Wechsel überhaupt erst ermöglicht hat.

Wie die PagerDuty Kultur es Teams ermöglichte, auf Kanban umzusteigen

Es gibt ein bekanntes Zitat des ehemaligen Präsidenten und Vorstandsvorsitzenden von 3M, William McKnight: „Stellen Sie gute Leute ein und lassen Sie sie in Ruhe.“ Die Entwicklungskultur von PagerDuty ist ein Beispiel für diese Philosophie. Die Teams hier organisieren sich selbst und haben ihr Schicksal weitgehend selbst in der Hand.

Während alle Lieferteams folgen Sie den Agile-Prinzipien , manche wählen Gedränge und andere Kanban , um ihre tägliche Arbeit zu bewältigen. Wenn sich ein Team weiterentwickelt und sich die Arbeit ändert, kann es sein, dass sie eine andere Art und Weise wählen, Dinge zu erledigen. Als Agile Coach kann ich einem Team dabei helfen, herauszufinden, was für sie am besten geeignet ist, aber ich bin nicht für ihre Prozesslösung verantwortlich. Es ist eine Reise, die das Team letztendlich gemeinsam unternehmen muss.

Warum sind also fast alle unsere Teams auf Kanban umgestiegen? Und war es aus den richtigen Gründen?

Warum die meisten Teams auf Kanban umgestiegen sind

Der Übergang geschah nicht über Nacht. Er begann mit einem Team und wurde im Laufe von zwei Jahren auf die gesamte Produktentwicklung ausgeweitet. Als die Teammitglieder zum ersten Mal von den Erfolgen ihrer Kollegen mit Kanban hörten, waren sie motiviert, es selbst auszuprobieren. Einige ihrer vorgefassten Meinungen über Kanban beruhten auf der Realität, andere waren Missverständnisse. Als Agile Coach war es mein Ziel, zusammen mit dem Rest des Agile Leadership Teams, unseren Teams dabei zu helfen, diese Missverständnisse zu überwinden und aus den richtigen Gründen zu entscheiden, ob sie zu Kanban wechseln sollten oder nicht.

Missverständnisse: Falsche Gründe für die Umstellung auf Kanban

Kanban ist das ultimative Ziel für ein leistungsstarkes Team. Sowohl Scrum als auch Kanban helfen Teams dabei, die schnellstmögliche Wertlieferung an Kunden zu priorisieren, und keines von beiden ist dem anderen überlegen. Aber im Kontext eines bestimmten Teams ist Kanban nicht immer die bessere Wahl. Zu einem bestimmten Zeitpunkt ist ein Team entweder mit Scrum oder mit Kanban besser bedient.

Kanban bedeutet keine Schätzung. Kanban-Teams arbeiten normalerweise darauf hin, ihre gesamte Arbeit ähnlich zu dimensionieren (z. B. indem sie eine „Blockgröße“ von drei Tagen oder weniger pro Ticket verwenden). Dies ist immer noch eine Schätzung, auch wenn keine Story Points oder eine bestimmte Zeitschätzung verwendet werden.

Kanban bedeutet keine Verpflichtungen mehr . Kanban bedeutet zwar keine Sprint-Verpflichtungen mehr (Arbeitsverpflichtungen innerhalb eines Zeitrahmens von 2-4 Wochen), aber das bedeutet nicht, dass es keine Verpflichtungen mehr gibt. Ein Kanban-Team ist für seine Zykluszeit verantwortlich (die Zeit, die zum Abschließen eines Tickets benötigt wird), ähnlich wie ein Scrum-Team für seine zugesagte Sprint-Geschwindigkeit verantwortlich ist (Maß für die Menge an Arbeit, die das Team in einem einzigen Zeitrahmen abschließt). Die Zykluszeit wird sowohl für die empirische Prozessreflexion als auch für die Release-Prognose verwendet.

Kanban bedeutet weniger Meetings. Kanban empfiehlt bestimmte Meetings, schreibt sie aber nicht so vor wie Scrum. Allerdings wäre es für die meisten Teams schwierig, ohne organisierte Meetings erfolgreich zu sein. Erfolgreiche Teams müssen sich auf ihre Ziele einigen und einen Plan erstellen, um diese zu erreichen, unabhängig davon, ob sie Scrum oder Kanban verwenden.

Die meisten Kanban-Teams bei PagerDuty haben Story-Time-Meetings durch Replenishment-Meetings ersetzt (beide dienen dazu, das Team auf zukünftige Arbeiten vorzubereiten) und führen weiterhin Retrospektiven, Reviews und Daily Stand Ups durch. Da der Backlog eines Teams weiterhin gepflegt werden muss, führen einige Teams auch weiterhin Backlog-Refinement-Meetings durch. Sprint Planning wird bei Kanban abgeschafft.

Zwar kann es zu einigen Einsparungen bei den Meetings kommen, insgesamt ist der Unterschied zwischen Scrum und Kanban jedoch nicht signifikant.

Realitäten: Gute Gründe für die Umstellung auf Kanban

Scrum ist weniger flexibel. Scrum verwendet eine Iteration als Zeit- und Umfangsrahmen, und es gibt wenig Flexibilität, Arbeit hinzuzufügen oder zu entfernen, sobald eine Iteration begonnen hat. Bei PagerDuty sind unsere Teams Eigentümer dessen, was sie bauen, was bedeutet, dass wir eine echte DevOps-Organisation sind. Da wir Eigentümer dessen sind, was wir bauen, werden einige Teams durch Arbeit unterbrochen, die beschleunigt werden muss. Scrum betrachtet dies negativ als „Sprint-Injektion“, die den Geschwindigkeitsmetriken des Teams zuwiderläuft. Kanban ist flexibel und ermöglicht es dem Team, eine Serviceklasse zu erstellen, um dringende Arbeit zu beschleunigen.

Scrum ist eher normativ. Scrum hat mehr Regeln, die befolgt werden müssen, und ist stärker strukturiert. Daher ist es besser für neu gebildete Teams geeignet, die die zusätzliche strukturelle Unterstützung gebrauchen können. Bei reiferen Teams können die Scrum-Regeln das Team behindern und ausbremsen.

Die Team- und Organisationskultur ist wichtig. Manche Teams sind motiviert, regelmäßig interne Verpflichtungen zur Erreichung ihrer Meilensteine einzugehen (z. B. Sprint-Verpflichtungen). Andere Teams empfinden dies als stressig und ziehen es vor, ihre Leistung zu verbessern, indem sie sich auf die Verbesserung ihrer Zykluszeit konzentrieren. Manche Teams bevorzugen es, Work In Progress (WIP) über eine Sprint-Verpflichtung zu verwalten, andere Teams bevorzugen es, WIP durch die Kontrolle des Ticketflusses im System zu verwalten. Manche Teams finden es sinnvoll, ihre Arbeit mithilfe von Story Points zu dimensionieren. Andere stellen fest, dass Gespräche mit Hinweisen abnehmende Erträge bringen, und finden, dass die Aufteilung ihrer Arbeit mithilfe einer Chunk-Größe (z. B. drei Tage oder weniger) ein effizienterer Prozess ist.

Kanban ist großartig … Aber

Fast alle Teams bei PagerDuty verwenden heute Kanban. Agile Coaches halfen den Teams bei der Entscheidung, ob sie aus den richtigen Gründen umsteigen. Wenn die Teams die Umstellung nicht aus den richtigen Gründen vornahmen (z. B. weil sie dachten, dass dadurch eine Funktionsstörung bei Scrum behoben würde), stellten sie bald fest, dass die für Scrum erforderliche Disziplin, Kommunikation und Einschätzung auch für den Erfolg mit Kanban erforderlich waren.

Bei der Auswahl eines Prozesses für Ihr Team müssen viele Aspekte berücksichtigt werden. Ich hoffe, dass dieser Blogbeitrag Ihnen dabei hilft, über den Prozess Ihres Teams nachzudenken und festzustellen, ob eine Umstellung auf Kanban Ihrem Team tatsächlich dabei helfen würde, seine Endziele besser zu erreichen, oder ob es seine Scrum-Probleme einfach auf Kanban übertragen würde.

Haben Sie Erfahrungen oder Geschichten über den Einsatz von Scrum oder Kanban in Ihrem Team? Teilen Sie sie auf unserer Community-Seite um uns mitzuteilen, was für Ihr Team am besten funktioniert.

Dieser Blogbeitrag wurde inspiriert von Andrea Roberts' internem Blogbeitrag von PagerDuty „Scrum oder Kanban? Wählen Sie das richtige Tool für Ihr Team.“