Team-Kalender

Der Team-Kalender stellt die Verfügbarkeit der Nucleus- und Extended-Team-Mitglieder für eine Iteration tabellarisch dar. Jedes Team-Mitglied trägt geplante Abwesenheiten ein, um vor (oder spätestens in) der Iterationsplanung die Brutto-Kapazität des Teams zu ermitteln. Dieser Wert wird zur Anpassung des Team-Forecasts genutzt, in dem er ins Verhältnis zur Velocity des Teams gesetzt wird, wodurch sich wird die Vorhersagbarkeit des Teams deutlich verbessert.

Beispiel eines ausgefüllten Team-Kalenders

Das Konzept lässt sich auch für Cluster und Cycles anwenden, am Best auf Basis der Feiertage im Cycle und der längerfristigen Urlaubsplanung der Team-Mitglieder.

Arbeitet das Team nicht mit Iterationen, sondern kontinuierlich mittels Kanban, wird der Team-Kalender für mehrere Wochen im voraus wochenweise geführt.

Team-Backlog, Iteration-Backlog und Team-Kanban

Team-Backlog

Jedes Team hat für seinen Verantwortungsbereich und seine Aufgaben genau ein Backlog. Es besteht in der feinsten Granularitätsstufe aus Team-Zielen für das Team. Das Team-Backlog wird vom Team-Product-Owner verantwortet und priorisiert. Ein großer Teil des Team-Backlogs wird durch die Team-Product-Owner-Gruppe und die Team-System-Engineer-Gruppe aus dem Cluster-Backlog, bzw. den System-Backlogs durch Verfeinerung (Refinement) der Einträge abgeleitet.

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

  • Qualitätsmaßnahmen und Verbesserung des Team-Prozesses aus dem Improvement-Backlog des Teams
  • Pflege der vom Team verantworteten Produkte, Systeme und Module
  • Wartung und Instandhaltung von Werkzeugen und Tools.

Um die Arbeitsgeschwindigkeit des Teams vorhersagbarer zu machen, sollte der Anteil an Backlog-Einträgen, die aus dem Cluster-Backlog abgeleitet werden, über die Zeit relativ stabil sein (z.B. 80% der Kapazität des Teams).

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

Im Team-Backlog-Refinement werden die Team-Backlog-Items vom Team-Product-Owner vorgestellt und vom Working-Team geschätzt.

In der Iterationsplanung zieht das Working-Team so viele Team-Backlog-Einträge, wie es das Team sich durch seine bisherige Arbeitsgeschwindigkeit zutraut. Dies ist dann das Iteration-Backlog, das den Plan für die nächste Iteration darstellt.

Arbeit in Iterationen oder im kontinuierlichen Kanban-Modus

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

In der Regel arbeiten Teams, die ein Dienstleistung für andere Teams erbringen (Service-Teams) mit Kanban, da hier jederzeit neue Arbeiten geplant und begonnen werden können, sowie jederzeit fertiggestellte Arbeit ausgeliefert werden kann.

Iteration-Backlog

Das Iteration-Backlog reflektiert die Arbeit eines Teams für eine gerade laufende Iteration. Die geplanten Arbeiten, reflektiert durch Backlog-Elemente, werden dabei zu Beginn der Iteration vom Working-Team in das Iteration-Backlog gezogen, was als Pull bezeichnet wird.

Team-Kanban

Arbeitet das Team im Kanban-Modus verwendet es statt des Iteration-Backlogs ein Team-Kanban-Board. Hierbei entspricht die erste Spalte dem Team-Backlog und die letzte Spalte dem Zustand „Erledigt“ oder „Done“. Alle anderen Spalten werden vom Team definiert, entsprechend des team-internen Arbeitsprozesses.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

.

Cluster-Backlog

.

Portfolio-Backlog

Team-Improvement-Backlog

Das Improvement-Backlog ist das Planungs- und Strukturierungswerkzeug des Scrum-Masters. Improvement-Backlogs gibt es auf allen drei Ebenen des P4-Frameworks (Team, Cluster, Organisation).

Jedes Team, das mehr Verbesserungen identifiziert, als momentan umsetzbar sind, legt diese Verbesserungen in ihrem Team-Improvement-Backlog ab, das der Team-Scrum-Master mit dem Team priorisiert.

Die Summe der Verbesserungen eines Clusters befindet sich im Cluster-Improvement-Backlog, das der Cluster-Scrum-Master mit der Team-Scrum-Master-Gruppe priorisiert. Das Cluster-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Teams gespeist.

Die Summe der Verbesserungen einer Organisation befindet sich im Organisation-Improvement-Backlog, das der Organisation-Scrum-Master mit der Cluster-Scrum-Master-Gruppe priorisiert. Das Organisations-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Cluster gespeist.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Retrospektive

Team-Scrum-Master Working-Team Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Improvement-Backlog

.

Organisations-Improvement-Backlog

Team-Product-Owner

Der Team-Product-Owner priorisiert das Team-Backlog und nimmt die Ergebnisse des Working-Teams ab. Im Team-Backlog können mehrere Produktentwicklungen oder Teile davon enthalten sein. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)

Je nach Art und Verantwortungsbereich des Teams (Team-Flavor) sind die Ergebnisse bzw. „Produkte“ der Teams sehr unterschiedlich. Daher können die Team-Product-Owner in P4 verschiedene Bezeichnungen haben:

Service-Owner

Service-Owner sind die fachlichen Leiter von Teams, die eine Expertise oder Kompetenz verantworten. Oft sind Mitglieder solcher Service-Teams zu speziell oder zu wenige, dass sie ständig in interdisziplinären Teams mitarbeiten könnten. Ein anderer Grund für ein Service-Team ist, das es eine spezielle Infrastruktur betreibt, z.B. ein Labor. Diese Teams sind häufig eine Art interner Dienstleiter innerhalb der Organisation (Service-Provider) und werden meist von anderen Teams aufgesucht oder zu ihnen eingeladen.

Der Service-Owner ist dafür verantwortlich, die Dienstleistungsaufträge seines Teams zu priorisieren. Im einfachsten Fall wendet er und sein Team ein Kanban-Board mit einem First-come-first-serve-Prinzip an (FIFO). Der Service-Owner kann aber auch das Dienstleistungsangebot seines Teams in Klassen einteilen, z.B. mittels unterschiedlichen Service-Level-Agreements zu unterschiedlichen Kosten.

Um einen optimalen Fluss der Systementwicklung zu erreichen, übernimmt der Service-Owner im einfachsten Fall die Prioritäten aus dem Portfolio-Backlog bzw. dem Cluster-Backlog. Zusätzlich stimmt er sich regelmäßig mit den anderen Team-Product-Ownern innerhalb der Team-Product-Owner-Gruppe (TPOG) ab.

Module-Owner

Bei der Entwicklung komplexer Systeme wird es häufig Subsysteme oder Module geben, um die Komplexität beherrschbarer zu machen (Module kapseln Komplexität) oder um mittels eines Plattform- bzw. Baukastenkonzepts die Wiederverwendung von Modulen und Komponenten zu ermöglichen.

Ein Modul-Owner ist daher der fachliche Manager, der dafür sorgt, dass die passenden Module für die Applikations- und Systementwicklung zur Verfügung stehen. Andererseits ist er dafür verantwortlich, dass die Module wiederverwendbar sind. Dabei kommt es im besonderen Maße auf stabile Schnittstellen für ein Plattform- bzw. Baukastensystem an.

Feature-Owner und Application-Owner

Feature-Owner sind die Team-Product-Owner von interdisziplinären Teams, die ein oder mehrere Funktionen (Features) einer Systemvarianten (=Applikationen) entwickeln und verantworten, sowie diese für Anwender zur Verfügung stellen. Der Feature-Owner ist dabei mit den anderen Feature-Ownern und dem Application-Owner für die Verbesserung des Kundennutzens des Produkts seines Application-Teams verantwortlich. Der Application-Owner stellt die direkte Schnittstelle zu den Anwendern der Applikation dar, um über Anforderungen und Änderungen der Applikation zu entscheiden.

Application-Owner sind die Team-Product-Owner der interdisziplinären Teams, die komplette Systemvarianten (=Applikationen) entwickeln und verantworten, sowie diese für Anwender zur Verfügung stellen. Der Application-Owner ist dabei für die Verbesserung des Kundennutzens des Produkts seines Application-Teams verantwortlich. Der Application-Owner stellt die direkte Schnittstelle zu den Anwendern der Applikation dar, um über Anforderungen und Änderungen der Applikation zu entscheiden. Je nach Organisation gibt es noch einen getrennten Liefer- und Betriebsbereich (Operations. Siehe p4-ops.com). Für manche Organisationen macht es Sinn, die Bereiche Entwicklung und Betrieb zusammenzulegen (DevOps), um Synergien durch direkteres und schnelleres Feedback zu erzielen.

Das Application-Team mit dem Application-Owner stellt den Auftraggeber der Modul- und Dienstleistungs-Teams dar. Applikation-Teams integrieren die von den Modul-Teams zur Verfügung gestellten Module mit Hilfe der Dienste der Service-Teams.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

.

Portfolio-Owner

Working-Team

.

Team-Product-Owner-Gruppe

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-System-Engineer (TSE)

Der Team-System-Engineer vertritt die technische Expertise und Verantwortung seines Teams in der Team-System-Engineer-Gruppe des Clusters. Wenn das Team keine andere Regelung vereinbart, vertritt er das Team auch in den Cluster-Syncs (Scrum-of-Scrums). Hierfür sollte er oder sie ein möglichst breites Wissen über die Themen innerhalb seines Teams haben. Je nach Art und Verantwortungsbereich kann dies deutlich unterschiedlich sein.

Vertritt ein Service-Team eine bestimmte Expertise (z.B. EMV oder Akustik), ist der Team-System-Engineer meist der erfahrenste des Teams.

Innerhalb eines Modulteams kennt der Team-System-Engineer die Module seines Teams, ihre Stärken und Schwächen, sowie ihre Anwendungsbereiche.

Innerhalb eines Applikationsteams kennt der Team-System-Engineer die technischen Möglichkeiten zu Realisierung der von seinem Team verantworteten Applikationen am besten.

Innerhalb des Working-Teams hat der Team-System-Engineer die Rolle, technische Entscheidungen zu moderieren und zu treiben und, im Zweifelsfall, diese zu treffen. Er steht dabei nicht über dem Working-Team, sondern ist der „Erste unter Gleichen“ (Primus inter paris).

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-Product-Owner

Team-Scrum-Master

.

Cluster-System-Engineer

.

Portfolio-Architekt

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-DoD (Definition-of-Done)

Das Team, der Team-Product-Owner und die Stakeholder müssen sich darauf einigen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als „Done“ bezeichnet wird. Obwohl sich dies erheblich von Team zu Team unterscheiden kann, müssen alle Team-Mitglieder ein gemeinsames Verständnis davon haben, wann Arbeit erledigt ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition-of-Done des jeweiligen Teams, Clusters bzw. der Organisation.

Die DoD ist das Qualitätsversprechen des Teams

Die DoD leitet das Working-Team auch bei der Entscheidung, wie viele Team-Backlog-Einträge es während des Team-Planning in das Iteration-Backlog ziehen kann. Der Zweck jeder Iteration ist es, inspizierbare Ergebnisse, verwendbares Wissen oder potenziell auslieferbare Funktionalität innerhalb eines System-Inkrements zu liefern, die der aktuellen Definition-of-Done entsprechen. Working-Teams liefern in jeder Iteration ein Inkrement an Ergebnissen, Wissen und/oder Systemfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Team-Product-Owner sich jederzeit dazu entscheiden kann, es zu freizugeben.

Wenn die Definition-of-Done für ein Team Teil von Konventionen, Standards oder Richtlinien des Clusters oder der Organisation ist, müssen alle Teams diese Cluster-DoD als Minimalziel befolgen. Wenn „Done“ für ein Team nicht Teil der Konvention des Clusters oder der Organisation ist, muss das Team eine für die Team-Ergebnisse geeignete Definition-of-Done formulieren. Wenn es mehrere Teams gibt, die am selben System arbeiten, müssen alle Teams gemeinsam eine Definition-of-Done erstellen. Jedes System-Inkrement ist additiv zu allen früheren Inkrementen und gründlich getestet, um sicherzustellen, dass alle Inkremente gemeinsam funktionieren. Von reiferen Teams wird erwartet, dass sie ihre jeweilige Definition-of-Done geeignet anpassen, um strengere Kriterien für eine höhere Qualität sicherzustellen. Neue Einträge in der Definition-of-Done können dazu führen, dass noch zu erledigende Arbeit in früheren „Done“ System-Inkrementen aufgedeckt wird.

Jedes einzelne Ergebnis, Produkt oder System sollte eine Definition-of-Done haben, die den Standard für jegliche daran durchgeführte Arbeit darstellt.

Die Definition-of-Done entspricht daher in ihrem Wesen, den Prozessbeschreibungen und „Standard-Operation-Procedures“ einer klassischen Organisation, allerdings in einer starkt kondensierten Form.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-Improvement-Backlog

.

Cluster-DoD

.

Organisations-DoD