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).