Organisatorische Ebenen

Cluster-Scrum-Master-Gruppe (CSMG)

Die Cluster-Scrum-Master-Gruppe, bestehend aus den Cluster-Scrum-Mastern der verschiedenen Cluster, hat zusammen mit dem Organisation-Scrum-Master (OSM) die Verantwortung für die Prozesse, Infrastruktur und die kulturelle Seite des Produktentstehungsprozesses auf der Organisationsebene. Zur Planung und Durchführung von Verbesserungsvorhaben führt die CSMG das Organisations-Improvement-Backlog. Die Rolle des Organisation-Scrum-Masters (OSM) bildet die höchste Managementrolle im Unternehmen. Sie trägt die…

Cluster-Sync (Scrum-of-Scrums)

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). Je nach Kontext kann es unterschiedliche Arten von Cluster-Syncs geben, z.B. eine tägliche Abstimmung aller Tester der…

Cluster-System-Engineer (CSE)

Der Cluster-System-Engineer hat mit der Team-System-Engineer-Gruppe auf der Cluster/System-Ebene die Verantwortung für die Technologie und Architektur innerhalb des Produktentstehungsprozesses.   Der Cluster-System-Engineer bildet mit dem Cluster-Product-Owner und dem Cluster-Scrum-Master das Managementkreis des Clusters. Zusammen mit der Team-System-Engineer-Gruppe hat der System-Achitekt folgende Aufgaben: Erstellung und Pflege der Architekturen des System-Portfolios innerhalb des Clusters Erstellen der Architecture-Roadmap des Clusters…

Cluster-System-Engineer-Gruppe (CSEG)

Die Cluster-System-Engineer-Gruppe (CSEG) besteht aus den Cluster-System-Engineers aller Cluster der Organisation. Sie entspricht auf der Organisationsebene der Rolle des Working-Teams auf Team-Ebene. Die Cluster-System-Engineer-Gruppe hat mit dem Portfolio Architect auf der Organisations- bzw. der Portfolio-Ebene die Verantwortung für die Technologie- und Architekturseite des Produktentstehungsprozesses.   Zusammen mit dem Portfolio-Architekt hat die Cluster-System-Engineer-Gruppe folgende Aufgaben: Erstellung…

Cluster

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…

Communities-of-Practice

Communities-of-Practice (CoP) sind Gruppen, die sich um spezielle Wissens- und Erfahrungsthemen kümmern. Alle Mitarbeiter haben die Möglichkeit, innerhalb ihrer „Practice-Zeit“ bzw. Ausbidungszeit in den selbstorganiserten CoPs zu arbeiten. Das P4-Framework sieht hierfür ca. 10% der Arbeitszeit vor. In den Communities-of-Practices geht es um: Erfahrungsaustausch Ausbildung und persönliche Weiterentwicklung Tools und Werkzeuge Typische Communities-of-Practice sind z.B.…

Fertigkeiten und Ausbildung

Fertigkeiten und Ausbildung (Skills & Education) stellen, neben den drei Hauptbereichen Markt & Business, Prozessen & Infrastruktur, Technologie & Architektur, einen vierten orthogonalen Bereich im P4-Framework dar, in denen es  um Erfahrungsaustausch, Lernen sowie Methoden und Werkzeuge spezieller Wissens- und Erfahrungspraktiken geht. Für jede dieser Praktiken kann es eine eigene Community-of-Practice (CoP) geben. In den interdisziplinären…

Inspizierbares Ergebnis

Jedes Team das sich innerhalb des P4-Frameworks organisiert ist erstellt inspizierbare Ergebnisse, d.h. dass alle Team-Ergebnisse gemäß ihrer Akzeptanzkriterien und der Definition-of-Done auf Vollständigkeit und Qualität geprüft werden können. Die Art der inspizierbaren Ergebnisse kann je nach Art und Verantwortungsbereich des Teams sehr stark variieren. Wichtig ist, dass die Wertschöpfung des Teams klar nachvollziehbar ist.…

Integrated System Sample (System-Inkremente)

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…

Interne Dienstleistungen (Services)

Interne Dienstleistungen sind die Ergebnisse von Service-Teams.   Allgemeine Attribute von Teams Die minimale Voraussetzung für ein Team-Ergebnis ist, dass es inspizierbar ist, d.h. es muss in einer Form vorlegen, die es für die Stakeholder (z.B. Nutzer des Ergebnisses) bewertbar macht. Die Definition-of-Done für die jeweiligen Ergebnisse und Artefakte müssen dies berücksichtigen. Inspectable Results sind…