Die Prozesssynchronisationsrunde (Teamebene)

Die Prozesssynchronisationsrunde (Fortschritts-Meeting) verbindet die Teamrolle über den SCRUM Master mit der Projektebene. Sie ist das zentrale Element zur Weichenstellung für weitere Verbesserungen im Projekt-/Programmablauf und dem Prozess.

Als ein Zusammentreffen mit Workshopcharakter verbindet dieses Format verschiedene Projekte und projektunterstützende Teams innerhalb eines Programms.

Hier werden Entscheidungen zur Strategieausrichtung, Prozessentwicklung, Ressourcenplanung etc. getroffen. In noch stark klassisch strukturierten Organisationen bildet diese Runde die Schnittstelle vom agilen Projekt(-ablauf) in die klassische Organisationsstruktur.

Länge: 45-120 Min.

Häufigkeit: vorzugsweise nach einer Retrospektive, bzw. zusätzlich 1-mal im Zeitraum zwischen zwei Retrospektiven

• Der SCRUM-Master trägt Blockaden oder Verbesserungsvorschläge vor, die im Team selbst nicht zu lösen sind. Diese sollen so an den entsprechenden Verantwortlichen weitergegeben werden. Es ist nicht unüblich, dass eine Vielzahl dieser Punkte aus einer Retrospektive abgeleitet werden. Es wird besprochen, was seit der letzten Prozesssynchronisationsrunde umgesetzt werden konnte und was noch umgesetzt werden soll / kann.
• Der Product Owner gibt Einblick über den Entwicklungsfortschriitt in Gegenüberstellung zum Backlog.
• Der/die Projektleiter/-in berichtet über den Ressourcenverlauf/-verbrauch, über die Verbindung mit anderen Abteilungen und zum "höheren" Management. Er bzw. sie berichtet über oder ermöglicht notwendige Synergien zu anderen "Kräften" im Unternehmen. Er / sie kann die Inhalte dieses Meetings nutzen, um ggf. ein Informationspaket über den aktuellen "Status" des Projekts zu schnüren.

• Projektleitung
• Product Owner
• SCRUM Master
• Abgesandte aus Teams
  

SCRUM Master:

• Kann ich die Stimmung in "meinem" Team akurat wiedergeben?
• Welche Aussagekraft haben meine Informationen, geplante, verworfene oder umgesetzte Änderungen?
• Sind die Anliegen des / der Teams strukturiert festgehalten?
• Ist die Verteilung für die Ressourcen optimal?
• Habe ich das Gefühl, dass die Rollen im Prozess gut miteinander wirken und kommunizieren?
• Welches Verbesserungspotential sehe ich in meiner Rolle als SCRUM-Master in diesem Prozess? Wie lauten meine Verbesserungsvorschläge?
• Sind nach wie vor alle Verantwortlichen für die Aufgaben klar definiert?

Product Owner:

• Gibt es konkrete Probleme mit dem Planungsprozess?
• Wie ist die Stimmung bei den Stake Holdern?
• Wie ist die Qualität der Informationen von meinen Stake Holdern im Blick auf das Produkt(-Backlog)?
• Durch was / wen / wie wird die Planung beeinflusst (kurzfristig / mittelfristig / langfristig)?

Projektleitung / Management:

• Wie können meine "Dead-Lines" mit dem agilen Vorgang synchronisiert werden (durch wen / bis wann / ggf. mit welchen Hilfsmitteln)?
• Wie verlaufen meine "Bestell"-Prozesse? (Welche Pufferzeiten muss ich vorab kommunizieren?)
• Habe ich die Anliegen und Informationen von meinen Ansprechpartner/-innen und Schnittstellen gesammelt und aufbereitet?
• Wie ist der Status von den Aufgaben aus dem agilen Prozess, die meinem Verantwortlichkeitsbereich unterliegen?
• Werde ich von etwas blockiert? Kann das von einer Rolle aus dem Prozess gelöst werden?

• Projektmanagement/-leitung über die aktuelle Stimmung im Team, den Vorschritt im Projekt und die Prozessentwicklung und den geplanten Tätigkeiten informieren
• Verbinden von klassischen Managementaufgaben mit dem "Management" des agilen Projekts und dem genutzten Prozessablauf

→ Gemeinsam wird die "Roadmap" für den Entwicklungsprozess (Software / Produkt) und Anpassungen im agilen Prozess besprochen und entschieden.

• ausgerichtet als monodirektionales Informationsflusssystem → beispielsweise: SCRUM-Master und Product Owner berichten "nur" den Status and PL
• Eine Plattform, in der Rollen versuchen, ungleichgewichtet egozentrische Entscheidungen mit einem Hang zu Machtkämpfen auszutragen. (Jede Rolle hat natürlich in ihrem Umfeld die Entscheidungskompetenz, in der diese auch Entscheidungen treffen wird. Zielführenderweise aber im Fokus auf das Gesamtprojekt und mit Rücksicht zu angrenzenden Umfeldern, bei denen es zu fließenden Kompetenzübergängen kommen kann.)