Team-Methoden – Teams in skalierter Umgebung, Teil 3

Scrum/XP als Grundlage

Teams nutzen in der Regel eine solide Implementierung von Scrum als Hauptgrundlage und liefern wertvolle Software nach jedem Sprint, also in der Regel alle zwei Wochen.

Sie verwenden die Rollen, die in Scrum definiert sind: der Product Owner repräsentiert die Autorität über die umzusetzenden User Stories. Der Scrum Master treibt den kontinuierlichen Verbesserungsprozess auf Teamebene und arbeitet an der Beseitigung von Hindernissen. Die Teammitglieder arbeiten gemeinsam an der Realisierung der Software. Sie sind Spezialisten und gleichzeitig Generalisten, die bei Bedarf auch außerhalb ihres Spezialgebiets aushelfen können.

In Scrum hat sich herausgestellt, dass Teams eine schwere Zeit haben, wenn sie keine adäquaten agilen Softwaretechniken verwenden und das Versprechen, flexibel änderbare Software im Sprinttakt zu liefern, schwer einlösen können. Diese agilen Softwaretechniken kommen aus Extreme Programming und sind normalerweise ein fester Bestandteil der Scrum-Implementierung.

Teams im Kanban-Modus

Manche Teams finden es einfacher, sich selbst als Kanban-Teams zu verstehen, wenn ein Großteil ihrer Arbeit Event-getrieben definiert ist. Das können Teams mit einem hohen Anteil an Wartungsarbeiten sein, vor allem haben aber System-Teams und DevOps einen Aufgabenmix, der die Nutzung von Kanban nahe legt.

Der Vorteil von Kanban gegenüber Scrum kann in einer schnelleren Reaktionszeit für neue Anforderungen und in einem geringeren Planungsoverhead liegen. Kanban nutzt auch stärker Metriken, um die Arbeit des Teams zu verbessern und zu beurteilen. Insbesondere das kumulative Flussdiagramm (cumulative flow diagram, CFD) zeigt sehr schnell die Entwicklung der Wertschöpfung eines Teams und ggfls. ein zu hohes WIP-Limit.

Auf der anderen Seite unterliegen Kanban-Teams ähnlichen Restriktionen wie Scrum-Teams, damit sie effektiv in einem Release Train arbeiten können:

  • Kanban-Teams haben dieselben Anforderungen an Code-Qualität
  • Sie brauchen ein Äquivalent zum Product Owner, um schnelle, dezentralisierte Entscheidungen herbeizuführen
  • Sie übernehmen dasselbe Commitment zu Release-Zielen und managen Abhängigkeiten zu anderen Teams
  • Sie nehmen an der Release-Planung, den anderen Meetings und der dazugehörigen Planung und Schätzung teil und arbeiten im selben Release-Rhythmus

In einem Release Train können mit diesen Randbedingungen Scrum und Kanban basierte Teams koexistieren und jeweils die für sie beste Arbeitsform nutzen.

Twitter
LinkedIn

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

mehr dazu

Der VSM Quick Guide: das Modell

Die Einführung in die Serie über Jon Walker’s VSM quick Guide. Er beschreibt das vereinfachte VSM-Vokabular, wie es im Rest der Schritte verwendet wird.

VSM Quick Guide Nuggets Teil 2

Über Teil 2: Teil 2 meiner Serie ist eigentlich Teil 1 von Jon Walker’s Quick Guide. Er beschäftigt sich damit, wie man die relevante Teile

Zucker Nuggets

VSM Quick Guide Nuggets Teil 1

Nuggets ausgraben Eine Menge neuer Texte sehe ich, seit ich eine Rudermaschine im Keller habe. Ich plane jeden Morgen, was ich mir in der nächsten