Schlagwort: Stakeholder

Stakeholder

Oliver Schönfeld

Stakeholder sind alle von einem System betroffenen Personen und Personengruppen, sowie alle direkt am Produkt Interessierten oder Beteiligten. Stakeholder werden auf allen Ebenen in die Reviews eingeladen und können optional in Backlog-Refinement-Meetings eingeladen werden, um ihre Anforderungen zu erläutern.

Um Stakeholder zu identifizieren verwendet das P4-Framework zwei unterschiedliche Lebenszyklen als gedankliche Leitfäden. Dies sind

  • der Produktlebenszyplus (von der Idee bis zum Ende der Produktpflege) und
  • der Einzelstücklebenszyklus (vom Einkauf des Rohmaterials bis zum Recycling)

Für jedes Produkt oder System lassen sich an diesen die unterschiedlichen Stakeholder (=Intressengruppen) identifizieren.

Produktlebenszyklus

Einzelstücklebenszyklus

Im P4-Framework werden drei Gruppen von Stakeholder unterschieden, die den drei Bereichen zugeordnet werden

Weitere Stakeholder

Im Anforderungsmanagement werden neben den „direkten“ Stakeholdern auch meist weitere, „allgemeinere“ Stakeholder definiert. Dies sind z.B.

  • die Gesellschaft, bestehend aus den öffentlichen und staatlichen Organisationen
  • die Umwelt (meist betroffen durch Emissionen und Abfälle)
  • Mitbewerber und Konkurrenten

Diese Stakeholder werden im P4-Framework nicht durch Stakeholder-Needs repräsentiert, sondern durch spezielle Ziele (z.B. zur Beschreibung der Wettbewerbssituation) oder sie werden durch Normen und Standards im Bereich Qualitätsattribute und Einschränkungen (QA&C).

Stakeholder-Map

Eine Stakeholder-Map zeigt die verschiedenen Stakeholder mit ihren Bedürfnissen und der Stärke der Einflüsse auf das System.

\r\n

Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Backlog-Refinement

Team-Review

.

Cluster-Backlog-Refinement

Cluster-Review

.

Portfolio-Refinement

Portfolio-Review

 Team-Product-Owner

.

Cluster-Product-Owner

.

Portfolio-Owner

 Team-Product-Owner-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Managementkreis der Organisation

 Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Cluster-Review

Oliver Schönfeld

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-Backlog, Cycle-Backlog und Cluster-Kanban

Oliver Schönfeld

Jeder Cluster hat für seinen Verantwortungsbereich und seine Aufgaben genau ein Backlog, das Cluster-Backlog. Es besteht in der einfachsten Form aus Elementen nur eines Systems, an dem alle Teams des Clusters arbeiten. In diesem Fall kann das Cluster-Backlog als System-Backlog bezeichnet werden. Werden von dem Cluster mehrere Systeme verantwortet und bearbeitet, befinden sich alle Backlog-Elemente der verschiedenen Systeme im Cluster-Backlog.

Das Cluster-Backlog wird von der Team-Product-Owner-Gruppe verantwortet und priorisiert. Die Team-Product-Owner-Gruppe besteht aus den Product-Ownern der Teams und dem Cluster-Product-Owner des Clusters. Ein großer Teil des Cluster-Backlogs wird durch die Cluster-Product-Owner-Gruppe und die Cluster-System-Engineer-Gruppe aus dem Portfolio-Backlog durch Verfeinerung im Portfolio-Backlog-Refinement abgeleitet.

Der andere Teil des Cluster-Backlogs besteht aus Arbeiten und Maßnahmen, die der Cluster zur Verbesserung der Arbeits- und Ergebnisqualität durchführt, z.B.

  • Qualitätsmaßnahmen und Verbesserung des Cluster-Prozesses
  • Pflege der vom Cluster verantworteten Produkte, Systeme und Module
  • Wartung und Instandhaltung von Werkzeugen und Tools.

Um die Arbeitsgeschwindigkeit der Cluster vorhersagbarer zu machen, sollte der Anteil an Backlog-Einträgen, die aus dem Portfolio-Backlog abgeleitet werden, über die Zeit relativ stabil sein.

Das Cluster-Backlog wird vom Cluster-Product-Owner priorisiert.

Im Cluster-Backlog-Refinement werden die Cluster-Backlog-Items vom Cluster-Product-Owner vorgestellt und von der Team-System-Engineer-Gruppe (TSEG) geschätzt. Da diese aus Mitgliedern aller Teams des Clusters besteht, ist diese Gruppe am besten dazu geeignet.

Im Cluster-Planning zieht die TSEG so viele Cluster-Backlog-Einträge, wie sich die TSEG durch die bisherige Arbeitsgeschwindigkeit des Clusters zutraut. Dies ist dann das Cycle-Backlog, das den Plan für den nächsten Cycle darstellt.

Arbeit in Cycles oder im kontinuierlichen Kanban-Modus

Cluster haben die Wahl, die Planung, Durchführung und Kontrolle ihrer Arbeit in einem Rhythmus von festen Zeiteinheiten, d.h. in Cycles durchzuführen, oder in einem kontinuierlichen Fluss, wobei jedes Backlog-Element einzeln die verschiedene Zustände des Arbeitsprozesses des Clusters durchläuft. Dies wird dann auf einem Kanban-Board transparent gemacht.

Ein Cluster wählt zwischen Cycle- und Kanban-Modus, je nach Produkt und wie Planung und Freigaben erfolgen. Bei einem regelmäßigen Freigabe-Rhythmus, z.B. alle drei Monate, bietet sich die Arbeit in Cycles an.

Cycle-Backlog

Das Cycle-Backlog reflektiert die Arbeit eines Clusters für einen gerade laufenden Cycle. Die abgeschätzten Arbeiten, d.h. Backlog-Elemente, werden dabei zu Beginn des Cycles von der TSEG in das Cycle-Backlog gezogen (Pull) und damit für den nächsten Cycle eingeplant (Forecast).

Cluster-Kanban

Arbeitet der Cluster im Kanban-Modus verwendet er statt des Cycle-Backlogs ein Cluster-Kanban-Board. Hierbei entspricht die erste Spalte dem Cluster-Backlog und die letzte Spalte dem Zustand „Erledigt“ oder „Done“. Alle anderen Spalten werden vom der Team-Scrum-Master-Gruppe des Clusters definiert, entsprechend des Cluster-internen Arbeitsprozesses..

.

\r\n

Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

 Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

 Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

 Team-Backlog

.

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Verantwortung von Markt und Business durch den Product Owner

Oliver Schönfeld

Das P4-Framework gliedert seine Organisations- und Managementstruktur der Produktentwicklung in drei Bereiche:

Markt und Business

Die Product-Owner-Rollen der verschiedenen Ebenen tragen die Verantwortung für die Produkte und deren Märkte. Dabei kommunizieren sie mit den Stakeholdern dieses Bereichs: Benutzer, Kunden und der (meist interne) Vertrieb.

Die Rolle des Product-Owners

Product, Product Backlog und Product Owner sind im P4-Framework generische Begriffe, d.h. sie existieren ausschließlich in spezifischen Ausprägungen. So hängen sowohl die generischen Artefakte „Product“, „Product Backlog“ als auch die generische Rolle „Product-Owner“ von der Art des jeweiligen Teams und der Ebene innerhalb der Organisation ab.

Der Product-Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Working-Teams entsteht. Wie dies geschieht, kann je nach Organisation, Cluster oder Team und Einzelpersonen stark variieren. Der Product-Owner ist die einzige Person, die für das Management des Product-Backlogs verantwortlich ist. Das Management des Product-Backlogs umfasst:

  • Die Product-Backlog-Einträge klar zu formulieren;
  • Die Reihenfolge der Einträge im Product-Backlog so anzuordnen, dass Ziele und Missionen optimal erreicht werden können;
  • Den Wert der Arbeit zu optimieren, die das Working-Team durchführt;
  • Sicherzustellen, dass das Product-Backlog sichtbar, transparent und für alle klar ist und zeigt, woran das Team als nächstes arbeiten wird;
  • Sicherzustellen, dass das Working-Team die Product-Backlog-Einträge im erforderlichen Maße versteht; und
  • Die Ergebnisse des Working-Teams zu begutachten und abzunehmen.

Der Product-Owner kann die oben genannten Arbeiten selbst durchführen oder sie durch das Working-Team oder einzelne Mitglieder durchführen lassen. Der Product-Owner bleibt jedoch immer rechenschaftspflichtig (accountable).

Der Product-Owner ist eine einzelne Person, kein Komitee. Er kann zwar die Wünsche eines Komitees im Product-Backlog wiedergeben, aber diejenigen, die einen Eintrag des Product-Backlogs in seiner Priorität verändern möchten, müssen sich an den Product-Owner wenden. Damit der Product-Owner erfolgreich sein kann, muss die gesamte Organisation seine Entscheidungen respektieren. Die Entscheidungen des Product-Owners sind in Inhalt und Reihenfolge des Product-Backlogs sichtbar. Niemand anderer darf dem Working-Team Anforderungen oder Arbeit zuordnen.

Die Product-Owner im P4-Framework

Im P4-Framework wird die generische Rolle des Product-Owners auf allen drei Ebenen konkretisiert und erweitert: Wichtig dabei ist, dass die Product-Owner auf  jeder Ebene sich untereinander innerhalb der jeweiligen PO-Gruppe abstimmen und dabei die Prioritäten für ihre Teams aus dem übergeordneten Backlog ableiten. (Mehr zu dem Überlappungsprinzip)

.

\r\n

Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Planning

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospektive

.

Portfolio-Planung

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

 Team-System-Engineer

Team-Scrum-Master

.

Cluster-System-Engineer

Cluster-Scrum-Master

.

Portfolio-Architekt

Organisations-Scrum-Master

 Team-Product-Owner-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Managementkreis der Organisation

 Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD