Cluster – P4-Dev Framework

Jeder Cluster besteht aus mehreren Teams und unterteilt die Organisation in zusammenhängende Wertströme (Value Streams). Die verschiedenen Systeme, Applikationen (Produkte) für bestimmte Märkte werden von den Clustern verantwortet.

Für die Umsetzung umfangreicher und komplexer Systeme werden in der Regel viele verschiedene Kompetenzen benötigt. Um gemeinsam an einem solchen Vorhaben zu arbeiten, reicht ein einzelnes Team mit maximal 10 Personen meist nicht aus. Die Zusammenarbeit und die Workflows zwischen den Teams müssen hierfür geregelt, und Verantwortungsbereiche müssen festgelegt werden. Um das zu erreichen, werden Teams in einer übergeordneten Organisationseinheit zusammengefasst. Diese übergreifende organisatorische Einheit wird im P4-Framework Cluster genannt. Ein Cluster hat die Systemverantwortung für ein oder mehrere verwandte Systeme (oder Produkte), für einen Produktbereich, für eine Plattform oder einen großen Modulbereich.

Durch Skalierung der Scrum-Rollen auf die Cluster-Ebene gibt es …

einen Cluster-Product-Owner (CPO) als Vertreter der Team-Product-Owner (TPOG),
einen Cluster-System-Engineer und die Team-System-Engineer-Gruppe (TSEG) als Vertreter der Working-Teams des Clusters und
einen Cluster-Scrum-Master als Vertreter der Team-Scrum-Master (TSMG)

Die drei Rollen Cluster-Product-Owner, der Cluster-Scrum-Master und der Cluster-System-Engineer bilden den Management-Kreis des Clusters (siehe auch im übernächstes Absatz).

Rollen & Gruppen

Um die Zusammenarbeit zu organisieren werden, zusätzlich zu den Teams, verschiedene Gruppen gebildet, die die drei unterschiedlichen Verantwortungsbereiche regeln. Die Gruppen werden nach dem Prinzip der Überlappung aus Mitgliedern der Working-Teams gebildet. Um diese Doppelzugehörigkeit klar zu regeln, werden die Arbeitszeiten für die Arbeit in der Gruppe zentral festgelegt. Es gibt von vornherein eine eindeutige Vereinbarung, wann und wie lange die Gruppe zusammenarbeitet (Cadence).

Entsprechend der drei Verantwortungsbereiche gibt es folgende Gruppen:

Market und Business: Die Team-Product-Owner-Gruppe (TPOG) mit dem Cluster-Product-Owner (CPO)
Technologie und Architektur: Die Team-System-Engineer-Gruppe (TSEG) mit dem Cluster-System-Engineer (CSE)
Prozesse, Infrastruktur und Kultur: Die Team-Scrum-Master-Gruppe (TSMG) mit dem Cluster-Scrum-Master (CSM)

Management-Kreis des Clusters

Der Cluster-PO, der Cluster-System-Engineer und der Cluster-SM bilden zusammen den Management-Kreis des Clusters (Cluster Management Circle, CMC) nach dem Prinzip der Gewaltenteilung. Sie unterstützen und ergänzen sich bei der Entscheidungsfindung von Themen, die auf ihre Ebene reichen, bzw. von einer der drei Gruppen an sie eskaliert wurden. Nach dem Prinzip der lokalen Entscheidung werden die meisten Entscheidungen sowieso auf Team-Ebene getroffen und nur ein geringer Anteil eskaliert.

Durch diese Konstrukte werden „einsame Einzelentscheidungen“ von Managern effektiv unterbunden, da Entscheidungen vorher aus allen drei Richtungen beleuchtet und diskutiert werden, und damit eine effektive Balance erreicht wird.

Der Management-Kreis des Clusters bildet eine interdisziplinäre Gruppe von Managern, die wie alle anderen Gruppen und Teams, tägliche oder wöchentliche Sync-Meetings und Retrospektiven abhalten.

Team-Setup und Team-Zusammenarbeitsmodelle

Teams, die innerhalb des Clusters arbeiten, liefern sich häufig gegenseitig Teilergebnisse und Zwischenprodukte zu. Um dies für alle transparent zu machen, beschreibt das Team-Setup, welche Personen in welchen Team arbeiten und wie die Team miteinander arbeiten. Hierzu gibt es folgende Möglichkeiten:

Ein Team bekommt ein Artefakt als Zulieferung (Wissen, Arbeitsergebnisse, Muster oder Module)
Ein Team bekommt eine Dienstleistung als Zulieferung (z.B. eine EMV- oder Akustikmessung)
Ein Service-/Experten-Team stellt einen Mitarbeiter für einige Iterationen einem anderen Team zur Verfügung (Vollzeit im Nucleus oder Teilzeit als Extended-Team-Mitglieder)
Zwei oder drei Teams teilen sich Extended-Team-Mitglieder
Zwei eng zusammenarbeitende Teams können auf folgende Art kollaborieren (z.B. zwei Feature-Teams, die an der gleichen Applikation arbeiten oder zwei Modulteams, die gegen eine komplexe technische Schnittstelle arbeiten):
- Sie ziehen ihren Team-Iteration-Backlog aus dem gleichen Team-Backlog und haben ggf. den selben Team-Product-Owner,
- Sie haben ein oder mehrmals pro Woche ein Joint-Team-Sync,
- Sie machen das Team-Planning, das Team-Backlog-Refinement, das Team-Review und/oder die Team-Retrospektive zusammen.

Das Zusammenarbeitsmodell zwischen zwei Teams lässt sich auf spielerische Art mit dem Team-Collaboration-Poker diskutieren und vereinbaren.

Workflows & Value Streams (Wertströme)

Value-Stream-Maps beschreiben die unterschiedlichen Verantwortungsbereiche und Lieferobjekte. Hierzu verwendet das P4-Framework die SIPOC-Beschreibung aus der klassischen Organisationsentwicklung. (Supplier >> Input >> Process >> Output >> Customer).

Beispiel eines Wertstoms

Dieses Beispiel einer mittelgroßen Organisation zeigt, neben den Teams auch den Wertstrom (Value Stream, Workflow) durch Pfeile an. Die Pfeile zu den Teams deuten die Planungs-, Analyse, Verfeinerungs- und Priorisierungsaktivitäten an, die stattfinden bevor die Teams Arbeitspakete bearbeiten. Die Pfeile von Ergebnissen der Teams zu anderen Teams bedeuten Zulieferungen.

Applikationsteams arbeiten eng mit dem Kunden/Anwender zusammen (hier nicht dargestellt). Daraus entsteht ein Großteil der eigenen Backlog-Items. Müssen mehrere Teams an Kunden-Anfragen arbeiten, nimmt der Product-Owner des Applikationsteams diese Anforderungen mit in die Team-Product-Owner-Gruppe. Applikationsteams liefern ihre Arbeitsergebnisse in Form von freigegebenen Produkten (oder Applikationen) an Kunden aus.

Modul- und Plattformteams liefern ihre versionierten und getesteten Module und Plattformen an Feature- und Applikationsteams.

Service-Teams unterstützen andere Teams durch die Erbringung ihrer Dienstleistungen.