Gespeichert von Christoph Mathis am Mi, 06/03/2015 - 08:00

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.