Team-Skills und –Qualitäten – Teams in skalierter Umgebung, Teil 2

Codequalität und Architektur

In einer größeren Entwicklung wird der Effekt schlechter Codequalität viel stärker wirksam: die Teams verlassen sich nicht mehr auf Zulieferungen, können keine realistischen Vorhersagen machen oder Commitments abgeben.

Eine skalierte Umgebung produziert in aller Regel langlebigen Code, die Effekte schlechter Qualität summieren sich auf und behindern die Lieferfähigkeit nachhaltig. Deshalb ist Codequalität ein zentraler Baustein für ein effektives agiles Team und einen effektiven Release Train.

SAFe zieht daraus die Konsequenzen:

  • Kontinuierliche Integration beibehalten (erfolgreiche Integration ist der wichtigste Indikator für Codequalität und stellt die agile Qualität des gesamten Organisation in Frage)
  • So viel Vorausschau wie nötig – mit dem „architectural runway“ werden auf kooperative Weise notwendige zentrale Festlegungen getroffen
  • Im Takt stabilisieren – auf Teamebene und auf Train-Ebene gibt es regelmäßige diese Stabilisierungspunkte mit dem Sprint Review und dem Release-Review Meeting.

Alignment – Unterschiede zu einzelnen Teams

Da ein SAFe Team nicht mehr autonom über alle Aspekte seiner Arbeit bestimmen kann, muss der Backlog für das Team mit dem übergreifenden Backlog abgestimmt werden, zum anderen, dass kritischen übergreifende Entscheidungen zu Schnittstellen und zur Architektur koordiniert werden müssen.

Der Product Owner, Scrum Master und die übrigen Teammitglieder haben zusätzliche Aufgaben, an der übergreifenden Planung, Koordination und dem Lernprozess des gesamten Trains mitzuarbeiten.

Transparenz

Agile Teams benötigen umfassende Transparenz, um gut funktionieren zu können. Verschiedene Maßnahmen tragen zu dieser Transparenz bei:

  • Alle Backlogs und der Arbeitsstand aller Teams sind kontinuierlich sichtbar
  • Die Teams stellen sinnvolle Kennzahlen bereit, die auf funktionierendem, getestetem und abgenommenen Code beruht.
  • Alle Beteiligten verstehen die Konzepte eines Backlogs, Velocity und Work-in-Progress.

Diese Transparenz muss übergreifend sichergestellt werden, die dazu notwendige offene Umgebung muss durch das Management sichergestellt und unterstützt werden.

Planung und Schätzung

Das einzelne Team leistet auf verschiedenen Ebenen einen Beitrag zur Planung:

  • Das Team schätzt in seiner Scrum-Rolle seine User Stories (als Teil des IP-Sprint oder in Backlog-Refinement-Meetings) und liefert damit für seinen Product Owner eine Schätzung für die nächsten Sprints
  • Das Team übernimmt als Ergebnis der Sprint-Planung die Verantwortung für User Stories
  • Die Teammitglieder nehmen zuvor am Planungsmeeting der Programmebenen-Iteration, dem Programm-Inkrement (PI) teil und erstellen dort eine gröbere Vorausschau für die Sprints während des Programm-Inkrement (PI, der grundlegende Releasezyklus bei SAFe).
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

Cookie Consent Banner von Real Cookie Banner