Kategorie: Cluster-Ebene

Cluster-Backlog

Nutzbares-Wissen

Cluster-Backlog, Cycle-Backlog und Cluster-Kanban

29. September 201916. Mai 2020 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

Nutzbares-Wissen & System-Inkrement

Team-Backlog

Portfolio-Backlog

Integrated System Sample & Increments

21. August 201915. April 2020 Oliver Schönfeld

System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie (je nach Grad der Regulierung) durch Nutzer- oder sogar Markttests verifiziert werden.

System-Inkremente werden häufig auf Cluster-Ebene erzeugt d.h. durch die Integration von Teilprodukten der verschiedenen Teams eines Clusters.

Für das System-Inkrement hat P4 die Arten und Definitionen von Mustern aus dem Design Thinking Framework übernommen. Sie definieren damit auch die Reifegrade der Muster (Samples).

Der Reifegrad wird letztlich über die Art und Anzahl der Knowledge-Gaps definiert. Um Knowledge Gaps zu schließen werden Muster aufgebaut

Prototype	Name	Description
B	Base Prototype	for design space exploration
C	Critical Function Prototype	Need finding; feasibility; fail early
D	Dark Horse Prototype	The alternative; thinking out of the box
E	Emergent Prototype	Combining several functions and ideas; iterative and incremental
F	Functional Prototype	Fully functional, but differs in (e.g. form-factor)
G	Gap Closing Prototype	Specific to close Knowledge Gaps or prove Hypotheses
H	Hindmost Prototype	Closest to series production

All Prototype can appear as iterating Prototypes, like G1, G2, G3.

\r\n

Passende und weiterführende Artikel:

Cycle-Wechsel in der Inter-Cycle-Week

18. August 201915. Mai 2020 Oliver Schönfeld

Der Cycle stellt eine Art große Iteration auf Cluster-Ebene dar, man könnte ihn auch als „Cluster-Iteration“ bezeichnen. Meist wird der Cycle auch für die Portfolio-Ebene der gesamten Organisation verwendet. Der Zyklus besteht aus mehreren Iterationen, einem Vorspann, bestehend aus Cluster-Planning und einem Nachspann, bestehend aus Cluster-Review und Cluster-Retrospektive. Da diese Events eine nicht zu vernachlässigende Zeit benötigen, sieht das P4-Framework dafür eine komplette Woche pro Vierteljahr vor, die als Interzykluswoche bezeichnet wird. Durch diesen Ansatz kommen die Iterations-Events, die ja immer am gleichen Wochentag stattfinden, nicht durcheinander.

Die Interzykluswoche befindet sich exakt zwischen den Iterationen zweier Zyklen und beginnt am Tag nach den Team-Retrospektiven, nicht etwa am folgenden Montag. Sie beendet den vorangegangen Zyklus durch ein gemeinsam im Cluster abgehaltenes Cluster-Review und eine Cluster-Retrospective (sowie einem Portfolio-Review und einer Organisations-Retrospective, falls die Organisationebene ebenfalls in Cycles arbeitet) und startet den nächsten Cycle durch ein Cluster-Planning (mit einem ggf. vorherigen Portfolio-Planning). Das folgende Bild illustriert dies:

Legende:

CPL=Cluster-Planning, CRef=Cluster-Backlog-Refinement, CRv=Cluster-Review, CRt=Cluster-Retrospective.

\r\n

Passende und weiterführende Artikel:

Events

Rollen

Gruppen

Artefakte

Team-Planning

Team-Sync

Team-Backlog-Refinement

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Organisations-Scrum-Master

Portfolio-Owner

Portfolio-Architekt

Working-Team

Community-of-Practice

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

System-Plattformen & Varianten

Portfolio-Backlog

Systeme & Applikationen

Organisations-DoD

Organisations-Improvement-Backlog

Samples & Integrations (Backlog-Elementtyp)

13. August 201914. Mai 2020 Oliver Schönfeld

Samples & Integrations repräsentieren alle Arbeiten, die für Aufbauten (egal, ob virtuell oder physisch) und deren Tests anfallen. Dies können Konzepte, Simulationen, prototypische Teilaufbauten, virtuelle Prototypen, rapid Prototypes, bis hin zu Vorserienmustern sein, die ggf. in Anwenderstudien getestet werden. Samples & Integrations werden erzeugt, um durch Lernen Wissenslücken zu schließen. Daher werden die Samples stets bewusst so geplant, dass sie mit minimalem Zeitaufwand erzeugt und getestet werden können, damit Wissenslücken in nutzbares Wissen verwandelt werden. Samples, die keine Wissenslücken schließen, werden nicht gebaut!

\r\n

Passende und weiterführende Artikel:

Wissenslücken (Knowledge Gaps)

13. August 201914. Mai 2020 Oliver Schönfeld

Produktentwicklungen beginnen heute sehr selten „auf der grünen Wiese“. Je nach Kompetenz der Organisation, sind gewisse Dinge bereits bekannt und können wiederverwendet werden. Alle unbekannten Dinge bezeichnet das P4-Framework als „Knowledge-Gaps“. Die Idee dahinter ist, dass eine Produktentwicklung als beendet betrachtet werden kann, wenn alle Knowledge-Gaps in nutzbares Wissen und Design-Entscheidungen verwandelt wurden.

(Anmerkung für Prozessexperten: Knowledge-Gaps stellen ein neues Konzept dar. Sie verbinden die Idee der „Hypothesen“ aus Lean-Startup mit dem „Knowledge-based“ Development von LPPD, dem Risiko-Management klassischer Prozesse und dem risiko-basierten Vorgehen aus dem Unified Process.)

Die Gap-Map

Die Gap-Map zeigt auf dem Hintergrund einer geeigneten Darstellung des „System-under-Development“ und seines Kontexts, die dazugehörenden Knowledge-Gaps als rotes Post-it. Grüne Post-its visualisieren Elemente und Schnittstellen, die nicht geändert werden oder im Laufe des Vorhabens bereits durch Gelerntes entschieden wurden.

Folgende Dinge können über die Gap-Map abgelesen werden:

Bereiche, mit einer Häufung von Knowledge-Gaps bedürfen einer höheren Aufmerksamkeit
Die Summe aller gewichteten Knowledge-Gaps ergeben den (Rest-)Aufwand der Produktentwicklung! Die Gewichtung bzw. Aufwandsschätzung wird von dem durchführenden, interdisziplinären Team vorgenommen, z.B. mittels Planning Poker.
Knowledge-Gaps sind Backlog-Elemente auf einer hohen Flughöhe und werden durch Herunterbrechen (Refinement) in kleinere, ausführbare Elemente zerlegt. Damit stellen Knowledge-Gaps den inhaltlichen Plan der Produktentwicklung dar.
Knowledge-Gaps ermöglichen ein einfaches Risiko-Management, da sie die produktbezogenen Unsicherheiten darstellen. (Achtung: Organisatorisches Risikomanagement ist zusätzlich notwendig)
Wenn alle roten Post-its in grüne Post-its verwandelt wurden ist die Produktentwicklung beendet

Durch die Einfachheit und Übersichtlichkeit stellt eine Gap-Map ein hervorragend geeignetes Kommunikationsmittel zwischen dem Team und dem Management dar.

\r\n

Passende und weiterführende Artikel:

System-Konzepte, -Architekturen und -Fähigkeiten

13. August 201911. Mai 2020 Oliver Schönfeld

Systemkonzepte beschreiben mögliche Lösungen für System- bzw. Produktvarianten (Applikationen = Feature-Sets) und deren Anforderungen. Systemkonzepte realisieren dabei die System-Anforderungen innerhalb der Einschränkungen (Contraints) und balancieren die Qualitätsanforderungen (Quality Attributes) aus. Das P4-Framework sieht im System-Backlog explizit mehrere Systemkonzepte als Lösungsoptionen für die Umsetzung von Systemanforderungen vor. Dies bedeutet, dass möglicherweise mehrere Lösungen für ein Problem identifiziert und weiterentwickelt werden (Divergenz im Lösungsraum). Ziel der Produktentwicklung ist es, nur so viele unterschiedliche Systemkonzepte zu entwickeln (parallel oder nacheinander), bis einige Konzepte disqualifiziert und sich idealerweise ein klarer Favorit herausstellt. Je nach Innovationsgrad der Entwicklung können dies anfangs sehr viele Konzepte sein, oder es ergeben sich sogar neue Konzepte während der Produktentwicklung.

In der heutigen Produktentwicklung hat sich das Konzept der Wiederverwendung und das Denken in Baukästen, Produktlinien und Plattformen stark durchgesetzt. Dies wird im P4-Framework durch den Architekturaspekt dieser Ebene abgebildet. Die Anforderungen an die Plattform sind in den „Quality Attributes & Constraints“ enthalten (z.B. Modularität, Wiederverwendbarkeit, Märkte und Anwendungen).

Die Verantwortung des Cluster-System-Engineers ist auch die Aufteilung von sogenannten Fähigkeiten (Capabilities) auf Module, die in komplexeren Systemen als Dienste (Services) beschrieben werden. Der Grundgedanke dabei ist, dass bestimmte Module Fähigkeiten zur Verfügung stellen, die von anderen Modulen genutzt werden können.

\r\n

Passende und weiterführende Artikel:

System-Anforderungen & Funktionen

13. August 201916. Mai 2020 Oliver Schönfeld

Systeme werden auf der obersten Ebene durch System-Anforderungen und Funktionen (Features) beschrieben. Anforderungen beschreiben dabei ausschließlich Fähigkeiten oder Eigenschaften im „Problemraum“, sind also noch losgelöst von konkreten System-Lösungen. Der Lösungsraum wird aber bereits durch die Quality Attributes & Constraints eingeschränkt.

Schnittstellen zu Nachbarsystemen im Umfeld sowie deren Eigenschaften werden hier ebenfalls spezifiziert. Hierfür wird ein sogn. Kontext-Diagramm erstellt und verwendet.

Funktionale Systemanforderungen der Stakeholder werden häufig in Form von User Stories* geschrieben und später durch „Use Cases“ tiefer spezifiziert.

*) P4 führt in diesem Zusammenhang den Begriff „Stakeholder Stories“ ein, da sie für die Spezifikation von Anforderungen aller Stakeholder, nicht nur der Benutzer, geeignet sind.

**) Nicht-funktionale Anforderungen (NFR) werden in P4 nicht direkt in das System-Backlog geschrieben (siehe Quality Attributes & Constraints)

\r\n

Passende und weiterführende Artikel:

Cluster-Sync (Scrum-of-Scrums)

25. Juli 201911. Mai 2020 Oliver Schönfeld

Cluster-Sync (Scrum-of-Scrums)

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

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

Das Cluster-Sync findet (meist im Halbkreis) vor dem Kanban-Board des Clusters statt, da die Mitglieder im Cluster-Sync die Cluster-Backlog-Items bewegen.

Die drei Fragen im Cluster-Sync lauten:

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

Die Struktur des Cluster-Sync kann von auch für den Austausch bestimmter Rollen oder Expertisen genutzt werden, z.B. ein Cluster-Sync der Team-Scrum-Master, der Team-Product-Owner, der Tester, der Konstrukteure, Designer, etc..

Durch die Kürze von maximal 15 Minuten ist das Cluster-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 Cluster-Sync nutzen, während die nicht benötigten Mitglieder weiterarbeiten können.

Besucher im Cluster-Sync

Besucher, die das Cluster-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:

- Der Cluster-Product-Owner
Mitglieder anderer Cluster
Stakeholder

Extended-Cluster-Sync

Ein oder mehrmals pro Woche kommen auch die Mitglieder von Teams, die für mehrere Cluster arbeiten in das Extended-Cluster-Sync (ähnlich dem Extended-Team-Sync auf Team-Ebene). Sie beantworten ihre drei Fragen entsprechend …

Was hat mein Team seit dem letzten Extended-Cluster-Sync für diesen Cluster gemacht und erreicht?
Was wird mein Team voraussichtlich bis zum nächsten Extended-Cluster-Sync für diesen Cluster tun?
An welchen Stellen ist mein Team blockiert und benötigt Unterstützung?

Für die Teams, die für mehrere Cluster arbeiten, ist darauf zu achten, dass die Extended-Cluster-Syncs der Cluster zu unterschiedlichen Zeitpunkten stattfinden, so dass die Mitglieder solcher Teams auch die Gelegenheit haben daran teilzunehmen. Innerhalb der Organisation, ermöglicht eine aufeinander abgestimmte Kadenz (Cadence) von Events eine minimale Überlappung und einen optimalen Workflow.

Joint-Cluster-Sync

Arbeiten zwei Cluster sehr eng zusammen, ist es ggf. sinnvoll, dass sie ein oder mehrmals pro Woche ein gemeinsames (Joint-) Cluster-Sync durchführen. Dabei hören die Vertreter des einen Clusters zu, während die Vertreter des anderen Clusters ihr Cluster-Sync durchführt und danach passiert dies umgekehrt.

\r\n

Passende und weiterführende Artikel:

Events

Rollen

Gruppen

Artefakte

Team-Sync

Cluster-Planning

Organisations-Sync

Nutzbares-Wissen & System-Inkrement

Cluster-Backlog