Organisations-Retrospektive

Die Organisations-Retrospektive bietet dem Organisations-Scrum-Master (OSM) die Gelegenheit, die Arbeitsweisen der Organisation, vertreten durch den Portfolio-Owner (PFO) und die Cluster-System-Engineer-Gruppe (CSEG), zu überprüfen, sowie Verbesserungen der Arbeitsweise für den kommende Cycle zu identifizieren und zu einzuplanen. Die Organisations-Retrospektive findet zwischen dem Portfolio-Review und dem nächsten Portfolio-Planning statt und basiert auf den Ergebnissen der Cluster-Retrospektiven, die meist von der Cluster-Scrum-Master-Gruppe aufbereitet wurden. Für einen vierteljährliche Cycle wird hierfür eine Obergrenze von vier Stunden angesetzt. Der Organisations-Scrum-Master (OSM) sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen. Der OSM sorgt dafür, dass das Meeting konstruktiv und produktiv ist und lehrt alle, den Zeitrahmen einzuhalten (Time-box). Aufgrund seiner Verantwortung für den P4-Prozess nimmt der OSM als gleichberechtigtes Mitglied an der Organisations-Retrospektive teil. Sie wird durchgeführt, um …

  • zu überprüfen wie der vergangene Cycle in Bezug auf die beteiligten Cluster, Teams, Beziehungen, Prozesse, Infrastruktur und Werkzeuge verlief;
  • die wichtigsten und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und
  • einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise der Organisation zu erstellen.

Die Cluster-Scrum-Master-Gruppe arbeitet daran, die Entwicklungsprozesse und -praktiken der Organisation zu verbessern, damit die Cluster im  kommenden Cycle effektiver und befriedigender arbeiten zu können. Vor jeder Organisations-Retrospektive erarbeitet die Cluster-Scrum-Master-Gruppe Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Prozesse oder der Definition-of-Done, sofern diese Änderungen angemessen sind und nicht im Widerspruch mit Produkt- oder Unternehmensstandards stehen. Zum Ende der Organisations-Retrospektive sollte die CSMG Verbesserungen für den kommende Cycle identifiziert haben.

Die CSMG überprüft in der Organisations-Retrospektive ebenfalls die Arbeitsflüsse (Workflows) zwischen den Clustern (z.B. durch Value-Stream-Mapping) und passt die Verantwortungsbereiche der Cluster und ggf. auch die Cluster-Strukturen innerhalb des Organisation an.

Die Cluster-Scrum-Master nehmen die Verbesserungsvorschläge und -maßnahmen mit in ihre Cluster.

Ablauf der Organisations-Retrospektive

Meist bringen die Cluster-Scrum-Master Probleme, Behinderungen (Impediments) und Verbesserungsideen (Improvements) aus ihren Clustern mit in die CSMG, die sie in den Cluster-Retrospektiven der Cluster gesammelt haben. Diese werden im Organisations-Improvement-Backlog gesammelt und priorisiert. In der Arbeitszeit der CSMG werden die am höchsten priorisierten Improvements während des laufenden Cycles analysiert und bearbeitet. In der Organisations-Retrospektive werden Änderungen dann gemeinsam beschlossen und umgesetzt.

Für die Ermittlung von weiteren Problemen, Behinderungen und Verbesserungsideen auf Organisations-Ebene, nutzt die CSMG die gleichen methodischen Ansätze und Fragestellungen, wie auf Team-Ebene, z.B.

  • Glad, Sad, Mad
  • Keep, Change, Puzzled
  • Good, Problems, Questions
  • Start, Stop, Keep, More, Less

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Retrospektive

.

Cluster-Retrospective

.

Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Portfolio-Review

Am Ende jedes Cycles wird ein Portfolio-Review abgehalten, in dem die Cluster-System-Engineer-Gruppe (CSEG) mit dem Portfolio-Owner (PFO), den Stakeholdern die Ergebnisse vorstellen. Dabei bekommen sie Feedback von den Stakeholdern zu den Ergebnissen, damit der Portfolio-Owner bei Bedarf das Portfolio-Backlog anzupasst. Zusammen mit eventuellen Änderungen am Portfolio-Backlog, die während des Cycles eingeflossen sind (z.B. in den Portfolio-Backlog-Refinements), bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Portfolios steigernden Einträgen. Beim Portfolio-Review handelt es sich um ein informelles Meeting, keinen Statusreport im klassischen Sinn. Die Vorführung der Ergebnisse ist als Anregung für Feedback und Basis für die Zusammenarbeit gedacht. Am Ende des Portfolio-Reviews kann der Portfolio-Owner ein Update zu Budgets und wichtigen Meilensteinen geben.

Für einen zwölfwöchigen Cycle wird für dieses Meeting eine Obergrenze von vier Stunden als Zeitrahmen angesetzt. Für kürzere Cycles wird ein entsprechender kürzerer Zeitrahmen veranschlagt. Der Organisations-Scrum-Master (OSM) stellt sicher, dass das Event stattfindet und die Teilnehmer seinen Zweck verstehen. Der OSM bringt allen Beteiligten bei, das Event innerhalb des vorgegebenen Zeitrahmens durchzuführen.

Das Portfolio-Review beinhaltet die folgenden Elemente:

  • Die Teilnehmer, bestehend aus der Cluster-System-Engineer-Gruppe (CSEG) und wichtigen Stakeholdern, die vom Portfolio-Owner eingeladen werden. Dies sind häufig auch die Cluster-Product-Owner der Organisation, d.h. die CPOG.
  • Der Portfoliot-Owner erklärt, welche Portfolio-Backlog-Einträge (PFBI) erledigt sind.
  • Die CSEG stellt dar, was während des Cycles gut lief, welche Probleme aufgetaucht sind, und wie sie diese Probleme gelöst hat. Die CSEG erfragt dabei ggf. Unterstützung durch die Stakeholder.
  • Die CSEG führt die erledigten Arbeitsergebnisse vor, und beantwortet Fragen dazu. Arbeitsergebnisse können sein:
    • nutzbares Wissen und von der CSEG getroffene (Design-)Entscheidungen,
    • integrierte Versionen der Systeme, Plattformen oder Applikationen
  • Der Portfolio-Owner stellt den aktuellen Stand des Portfolio-Backlogs vor. Er gibt bei Bedarf eine aktualisierte Prognose von wahrscheinlichen Ziel- und Lieferterminen auf der Basis des Entwicklungsfortschritts, z.B. durch Nutzung eines Burn-up-Charts auf Basis der Arbeitsgeschwindigkeit der Organisation (Velocity)
  • Alle Teilnehmer erarbeiten gemeinsam, was als nächstes zu tun ist, so dass der Portfolio-Owner wertvollen Input für die kommende Cluster-Planung bekommt.
  • Anschließend werden Zeitplan, Budget, sowie die potentiellen Eigenschaften und Markterwartungen für die nächsten Versionen der Applikationen (Release) überprüft.

Das Ergebnis des Portfolio-Reviews ist ein überarbeitetes Portfolio-Backlog, das dem gemeinsamen Wissenstand der Teilnehmer entspricht und durch das die CSEG im  nächsten Cycle, an den Portfolio-Backlog-Einträgen mit dem höchsten Wert arbeiten kann. Das Portfolio-Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Review

.

Cluster-Review

.

Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Organisations-Retrospektive

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Portfolio-Planung

Die Planung auf Portfolio-Ebene ist im P4-Framework ein semi-kontinuierlicher Prozess, genauso wie z.B. die Budgetplanung, die eng mit der Portfolioplanung verknüpft ist.  Der Planungsprozess besteht aus der Vorbereitung durch das Portfolio-Refinement und das Portfolio-Planungs-Event. Der Planungsprozess findet auf der Ebene der Portfolio-Backlog-Elemente statt. Diese sind:

  • Applikationsversionen (d.h. an den Kunden auslieferungsfähige Produkte)
  • System-Versionen (d.h. fertig getestete, dokumentierte und nutzbare Versionen von System-Plattformen)
  • Modulversionen

Zeitlich wird häufig in folgenden Abschnitten geplant, nach dem Prinzip „je näher, desto feiner“:

  • vier Quartale/Cycles (d.h. nächster Cycle, C+1, C+2, C+3)
  • dem Folgejahr (entweder kalendarisch oder C+4 bis C+7)
  • später

Änderungen an der Portfolio-Planung fließen also gut vorbereitet und zu bestimmten Zeiten in die Organisation. Bei Darstellung auf einem Portfolio-Kanban-Board wird auf diese Weise die gesamte Arbeit der Organisation transparent.

Portfolio-Cycle-Planung

Jeder Cycle für die gesamte Organisation beginnt mit einer Portfolio-Planung. In dieser präsentiert der Portfolio-Owner (PFO) der Cluster-System-Engineer-Gruppe (CSEG) den aktuellen Stand des Portfolio-Backlogs. Neue Einträge oder Änderungen, die der Cluster-System-Engineer-Gruppe seit dem letzten Portfolio-Backlog-Refinement noch nicht bekannt sind, werden geschätzt, ggf. durch Akzeptanzkriterien ergänzt und vom Portfolio-Owner innerhalb des Portfolio-Backlogs priorisiert.

Die Cluster-System-Engineer-Gruppe ermittelt die Kapazität für den nächsten Cycle durch einen Blick auf die bisherige Arbeitsgeschwindigkeit der Organisation (Organisations-Velocity) und durch einen Blick auf die Kapazität der Cluster im nächsten Cycle.

Die Cluster-System-Engineer-Gruppe zieht die Anzahl von Portfolio-Backlog-Items (PFBI), die der Einschätzung des CSEG über die Kapazität im nächsten Cycle entspricht, in das Cycle-Backlog der Organisation (Pull). Danach verfeinern die Cluster-Product-Owner mit der CSEG die PFBIs in Cluster-Backlog-Items, die zur Fertigstellung des PFBIs nötig sind.

Danach startet die CSEG den Cycle durch ziehen der ersten Aufgaben von „open“ nach „in progress“.

Alternative: Portfolio-Kanban

Alternativ kann die gesamte Portfolio-Planung auch kontinuierlich durch Nutzung eines Kanban-Systems erfolgen. Dabei entfällt der Cycle als Timebox und die Velocity als Maß für die Arbeitsgeschwindigkeit. Die kontinuierliche Portfolio-Planung erfolgt dann durch regelmäßige Treffen von CSEG und Portfolio-Owner (meist einmal pro Iteration). Die Aktivitäten „Vorstellen“, „Schätzen“ und Priorisieren von Backlog-Elementen passiert dann auf Basis einzelner Elemente. Das Ziehen (Pull) von Backlog-Elementen erfolgt auf Basis von sogn. Work-in-Progress-Limits (WiP-Limit).

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

.

Cluster-Planning

.

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Portfolio-Backlog-Refinement

Als Refinement (Verfeinerung) des Portfolio-Backlogs wird der Vorgang angesehen, in dem Details zu Backlog-Einträgen hinzugefügt, Schätzungen erstellt, Backlog-Einträge zerteilt werden oder die Reihenfolge der Einträge im Portfolio-Backlog geändert werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Porfolio-Owner und die Cluster-System-Engineer-Gruppe (CSEG) gemeinsam die Portfolio-Backlog-Einträge detaillieren. Bei der Verfeinerung des Portfolio-Backlogs werden die Einträge begutachtet und revidiert. Der Portfolio-Owner kann jedoch jederzeit die Einträge im Portfolio-Backlog aktualisieren oder aktualisieren lassen.

Das Portfolio-Backlog-Refinement dient hauptsächlich der Vorbereitung der nächsten Portfolio-Planung. Dabei stellt der Portfolio-Owner der Cluster-System-Engineer-Gruppe (CSEG) neue Backlog-Einträge vor und lässt diese schätzen.  Dies ist eine Voraussetzung für das „Pull“ der CSEG und wird oft auch als Definition-of-Ready bezeichnet. Bei unklaren aber hoch priorisierten Backlog-Einträgen klärt die CSEG die System-Anforderungen, mögliche System-Konzepte und Fähigkeiten. Dies kann sie als Gruppe selbst erarbeiten oder es wird ein entsprechender Backlog-Eintrag als Auftrag für einen der Cluster erzeugt.

Schätzung des Realisierungsaufwands von Backlog-Einträgen

Schätzungen durch die gesamte Cluster-System-Engineer-Gruppe sind aus zwei Gründen wichtig:

  1. Durch das gemeinsame Schätzen analysiert die CSEG den jeweiligen Backlog-Eintrag aus verschiedenen Blickwinkeln und reichert diesen dabei mit Informationen an, wie Akzeptanzkriterien und Randbedingungen. Außerdem werden erste Ideen zur Umsetzung erzeugt.
  2. Das Ergebnis der Schätzung ist eine Zahl, mit der einzelne Backlog-Elemente bewertet werden können, z.B. zur Priorisierung. Außerdem läßt sich nun einfach errechnen, wie viele Backlog-Elemente in einen Cycle gezogen werden können, nämlich durch Vergleich der in den letzten Cycles fertiggestellten Backlog-Elementen (Velocity der Organisation).

Zur Schätzung des Aufwands bedient sich das Team der Methodik des Planning-Poker®.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Backlog-Refinement

.

Cluster-Backlog-Refinement

.

Portfolio-Planung

Organisations-Sync

Portfolio-Review

Organisations-Retrospektive

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Cluster-Retrospektive

Die Cluster-Retrospektive bietet dem Cluster-Scrum-Master (CSM) die Gelegenheit, die Arbeitsweisen des Clusters, vertreten durch den Cluster-Product-Owner und die Team-System-Engineer-Gruppe (TSEG), zu überprüfen, sowie Verbesserungen der Arbeitsweise für den kommende Cycle zu identifizieren und zu einzuplanen. Die Cluster-Retrospektive findet zwischen dem Cluster-Review und dem nächsten Cluster-Planning statt und basiert auf den Ergebnissen der Team-Retrospektiven der Teams, die meist von der Team-Scrum-Master-Gruppe aufbereitet wurden. Für einen vierteljährliche Cycle wird hierfür eine Obergrenze von vier Stunden angesetzt. Bei kürzeren Cycles ist das Meeting in der Regel kürzer. Der CSM sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen. Der CSM sorgt dafür, dass das Meeting konstruktiv und produktiv ist und lehrt alle, den Zeitrahmen einzuhalten (Time-box). Aufgrund seiner Verantwortung für den P4-Prozess nimmt der CSM als gleichberechtigtes Mitglied an der Cluster-Retrospektive teil. Sie wird durchgeführt, um …

  • zu überprüfen wie der vergangene Cycle in Bezug auf die beteiligten Teams, Beziehungen, Prozesse, Infrastruktur und Werkzeuge verlief;
  • die wichtigsten und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und
  • einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Clusters zu erstellen.

Die Team-Scrum-Master-Gruppe arbeitet daran, die Entwicklungsprozesse und -praktiken des Clusters zu verbessern, damit die Teams des Clusters im  kommenden Cycle effektiver und befriedigender arbeiten zu können. Vor jeder Cluster-Retrospektive erarbeitet die Team-Scrum-Master-Gruppe Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Prozesse oder der Definition-of-Done, sofern diese Änderungen angemessen sind und nicht im Widerspruch mit Produkt- oder Unternehmensstandards stehen. Zum Ende der Cluster-Retrospektive sollte die TSMG Verbesserungen für den kommende Cycle identifiziert haben.

Die Team-Scrum-Master-Gruppe überprüft in der Cluster-Retrospektive ebenfalls die Arbeitsflüsse (Worksflows) zwischen den Teams (z.B. durch Value-Stream-Mapping) und passt die Verantwortungsbereiche der Teams und ggf. auch die Team-Strukturen innerhalb des Clusters an.

Die Team-Scrum-Master nehmen die Verbesserungsvorschläge und -maßnahmen mit in ihre Teams.

Ablauf der Cluster-Retrospektive

Meist bringen die Team-Scrum-Master Probleme, Behinderungen (Impediments) und Verbesserungsideen (Improvements) aus ihren Teams mit in die TSMG, die sie in den Team-Retrospektiven der Teams gesammelt haben. Diese werden im Cluster-Improvement-Backlog gesammelt und priorisiert. In der Arbeitszeit der TSMG werden die am höchsten priorisierten Improvements während des laufenden Cycles analysiert und bearbeitet. In der Cluster-Retrospektive werden Änderungen dann gemeinsam beschlossen und umgesetzt.

Für die Ermittlung von weiteren Problemen, Behinderungen und Verbesserungsideen auf Cluster-Ebene nutzt die TSMG die gleichen methodischen Ansätze und Fragestellungen, wie auf Team-Ebene, z.B.

  • Glad, Sad, Mad
  • Keep, Change, Puzzled
  • Good, Problems, Questions
  • Start, Stop, Keep, More, Less

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Retrospektive

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

.

Organisations-Retrospektive

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

Cluster-Review

Am Ende jedes Cycles wird ein Cluster-Review abgehalten, in dem die Team-System-Engineer-Gruppe (TSEG) mit dem Cluster-Product-Owner (CPO), den Stakeholdern die Ergebnisse vorstellen. Dabei bekommen sie Feedback von den Stakeholdern zu den Ergebnissen, damit der CPO bei Bedarf das Cluster-Backlog anzupasst. Zusammen mit eventuellen Änderungen am Cluster-Backlog, die während des Cycles eingeflossen sind (z.B. in den Cluster-Backlog-Refinements), bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert der „Cluster-Produkte“ steigernden Einträgen. Beim Cluster-Review handelt es sich um ein informelles Meeting, keinen Statusreport im klassischen Sinn. Die Vorführung der Ergebnisse ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht. Am Ende des Cluster-Reviews kann der Cluster-Product-Owner ein Update zu Kosten und geplanten Terminen bzw. Meilensteinen geben.

Für einen zwölfwöchigen Cycle wird für dieses Meeting eine Obergrenze von vier Stunden als Zeitrahmen angesetzt. Für kürzere Cycles wird ein entsprechender kürzerer Zeitrahmen veranschlagt. Der Cluster-Scrum-Master (CSM) stellt sicher, dass das Event stattfindet und die Teilnehmer seinen Zweck verstehen. Der CSM bringt allen Beteiligten bei, das Event innerhalb des vorgegebenen Zeitrahmens durchzuführen.

Das Cluster-Review beinhaltet die folgenden Elemente:

Das Ergebnis des Cluster-Reviews ist ein überarbeitetes Cluster-Backlog, das dem gemeinsamen Wissenstand der Teilnehmer entspricht und durch das die TSEG im  nächsten Cycle, an den Cluster-Backlog-Einträgen mit dem höchsten Wert arbeiten kann. Das Cluster-Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Review

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Retrospective

.

Portfolio-Review

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

Cluster-Planning

Cluster-Planning in Cycles

Jeder Cycle beginnt mit einem Cluster-Planning-Event. In diesem präsentiert der Cluster-Product-Owner der Team-System-Engineer-Gruppe (TSEG) den aktuellen Stand des Cluster-Backlogs. Neue Einträge oder Änderungen, die der Team-System-Engineer-Gruppe seit dem letzten Cluster-Backlog-Refinement noch nicht bekannt sind, werden geschätzt, ggf. durch Akzeptanzkriterien ergänzt und vom Cluster-Product-Owner innerhalb des Cluster-Backlogs priorisiert.

Die Team-System-Engineer-Gruppe ermittelt die Kapazität für den nächste Cycle durch einen Blick auf die bisherige Arbeitsgeschwindigkeit des Clusters (Cluster-Velocity) und durch einen Blick auf die Kapazität der Teams im nächsten Cycle.

Die Team-System-Engineer-Gruppe zieht die Anzahl von Cluster-Backlog-Items (CBI), die der Einschätzung des TSEG über die Kapazität im nächsten Cycle entspricht, in das Cycle-Backlog des Clusters (Pull). Danach verfeinern die Team-Product-Owner mit den TSEG die CBIs in Team-Backlog-Items, die zur Fertigstellung des CBIs nötig sind.

Danach startet die TSEG den Cycle durch ziehen der ersten Aufgaben von „open“ nach „in progress“.

Kontinuierliches Cluster-Planning

Alternativ zum Planungsrhythmus in Cycles, kann die Planung der Arbeiten für den Cluster auch kontinuierlich erfolgen. Hierfür werden die Cluster-Backlog-Refinements genutzt, wobei ein Cluster-Backlog-Items direkt nach der Analyse und Schätzung, in Bearbeitung gehen kann.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

.

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

.

Portfolio-Planung

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

Organisations-Sync

Organisations-Sync (Scrum-of-Scrums-of-Scrums)

Dieses Event ermöglicht, dass mehrere Cluster miteinander kommunizieren, um Abhängigkeiten, Störungen, neue Erkenntnisse und Entscheidungen, etc. während der laufenden Arbeit untereinander abzustimmen. Die Cluster entscheiden selbst, wie häufig dies benötigt wird (z.B. täglich, wöchentlich).

Die Vertreter des Clusters können die Cluster-System-Engineers der Cluster sein. Es können aber auch andere technische Vertreter des Clusters dazu bestimmt werden.

Das Organisation-Sync findet (meist im Halbkreis) vor dem Portfolio-Kanban-Board der Organisation statt, da die Mitglieder im Organisations-Sync die Portfolio-Backlog-Items bewegen.

Die drei Fragen im Organisations-Sync lauten:

  1. Was hat mein Cluster seit dem letzten Organisations-Sync gemacht?
  2. Was wird mein Cluster voraussichtlich bis zum nächsten Organisations-Sync tun?
  3. An welchen Stellen ist mein Cluster blockiert und benötigt Unterstützung?

In ähnlicher Weise kann die Struktur des Organisations-Sync auch für den Austausch bestimmter Rollen oder Expertisen genutzt werden, z.B. ein Sync der Cluster-Scrum-Master, der Cluster-Product-Owner, der Tester, der Konstrukteure, Designer, etc. eines Clusters.

Durch die Kürze von maximal 15 Minuten ist das Organisations-Sync nur dazu geeignet, Probleme zu identifizieren, nicht aber diese zu diskutieren oder zu lösen. Für die Diskussion von Problemen können die benötigten Mitglieder die Zeit nach dem Organisations-Sync nutzen, während die nicht benötigten Mitglieder weiterarbeiten können.

Besucher im Organisations-Sync

Besucher, die das Organisations-Sync miterleben wollen, können mit Erlaubnis der Mitglieder teilnehmen. Dabei stehen die Besucher in der zweiten Reihe und hören nur zu, außer sie werden von einem aktiven Mitglied angesprochen. Besucher können sein:

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Sync

.

Cluster-Sync

.

Portfolio-Planning

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospective

Portfolio-Owner

Portfolio-Architect

Organisation-Scrum-Master

Cluster-Product-Owner-Group

Cluster-System-Engineer-Group

Cluster-Scrum-Master-Group

Managementkreis der Organisation

Portfolio-Backlog

Systems & Applications

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Kadenz (Cadence) eines Jahres

Die Kadenz (englisch Cadence) ist eine zentral festgelegte Event-Planung für die Organisation. Sie ermöglicht es, ähnlich einem Stundenplan an einer Schule oder Universität, dass …

  •  alle Rollen innerhalb der Organisation an den für sie vorgesehenen Events teilnehmen können. (Keine überlappenden Einladungen)
  • alle privaten Events der Teams und Gruppen gleichzeitig stattfinden, um möglichst viel freie Arbeitszeit innerhalb der Teams und Gruppen zu ermöglichen

Die Kadenz eines Jahres besteht im P4-Framework aus vier sogenannten Cycles, die jeweils ein Vierteljahr betragen. An Übergängen zwischen den Cycles finden verschiedene Organisations- und Cluster-Events statt, ähnlich dem Iterationswechsel in Scrum. Es ist empfehlenswert, den Cycle-Wechsel nicht auf kalendarische Viereljahresgrenzen zu legen, damit ein Wechsel z.B. nicht mit dem Jahreswechsel und die davor liegenden Weihnachtszeit kollidiert.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

.

Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

.

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Working-Team

Community-of-Practice

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog