Team

Spezielle Arten:Application/Feature-Team, Module-Team, Service-Team
besteht ausTeam-Product-Owner, Team-Scrum-Master, Working-Team
Mehrere sind Teile vonCluster
erstelltInspizierbares Ergebnis
arbeitet inIteration

Das Team ist das Basiselement einer agil arbeitenden Organisation und bildet die Heimat von Mitarbeitern. Bis zu neun zusammenarbeitende Teams organisieren sich in einem Cluster.

Die meisten Arbeiten finden in stabilen und langlebigen Teams statt. Durch die Stabilität bzw. „Langlebigkeit“ sind die Teams bei Produktproblemen auch dann verfügbar, wenn momentan gerade nicht an einer Überarbeitung der Applikation/Systemvariante gearbeitet wird (also, wenn klassisch aufgestellte Projekt-Teams nicht mehr bestehen).

P4 übernimmt die Grundstruktur eines Teams aus Scrum. Es besteht aus Team-Product-Owner, Team-Scrum-Master und dem Working-Team, die zusammen für die Stakeholder arbeiten. Durch das Prinzip der Gewaltenteilung ergeben sich klar umrissene Verantwortungsbereiche, die sich im Team ergänzen.

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

Das Working-Team  besteht aus drei bis neun Mitgliedern und dem System-Engineer, die in jeder Iteration fertige und inspizierbare Ergebnisse erarbeiten und am Ende der Iteration im Team-Review vorstellen, idealerweise ein potenziell auslieferbares System oder Teilsystem.

Der Team-Scrum-Master ist ein „Servant-Manager“ und ist dafür verantwortlich, die Team-Arbeit entsprechend den Scrum- und P4-Regeln zu fördern und zu unterstützen, indem er allen Beteiligten hilft, die Werte und  Praktiken zu verstehen.

Im Gegensatz zu Teams sind Gruppen hauptsächlich dazu da, über verschiedene Ebenen und Teams hinweg zu kommunizieren und Entscheidungen zu treffen. Es gilt der einfache Grundsatz: „Teams arbeiten, Gruppen reden“.

Das Working-Team

Das Working-Team besteht, neben dem Team-System-Engineer, aus dem sogenannten Nucleus: das sind Personen, die zum deutlich überwiegenden Anteil ihrer Arbeitszeit in diesem Teams arbeiten (>80%), und dem Extended-Team: dies sind Personen, die in einigen wenigen Teams arbeiten (zwischen 20% und 80%).

Nucleus-Team-Mitglieder sitzen und arbeiten zusammen, koordinieren sich täglich im Team-Sync und haben als Team gemeinsame Verantwortlichkeiten.

Extended-Team-Mitglieder nehmen am Extended-Team-Sync teil (z. B. zwei mal wöchentlich) und sitzen bei Bedarf mit dem Nucleus-Team zusammen. Dies erfordert "Spielräume" in Bezug auf zusätzliche Sitz- und Arbeitsplätze im Teambereich. Erweiterte Team-Mitglieder können mit einigen wenigen Nucleus-Teams zusammenarbeiten. Die Kapazität, die sie für jedes Team erbringen können, wird auf zyklus- oder iterationsebene im Team-Kalender geplant. Die Summe der Kapazität jedes Teammitglieds darf 100% nie überschreiten, d.h. wird ein Extended-Team-Mitglied in einem Team mehr benötigt, muss sich die Kapazität für die anderen Teams verringern.

Die Mitglieder des Nucleus und Extended-Teams machen ihre Arbeit auf dem Team-Board des Teams sichtbar (manchmal auch Kanban-, Task- oder Scrum-Board).

Die folgenden Rollen gehören nicht zum Working-Team:

Supporter  arbeiten in ihrem Service-Team (Team-Flovor "gelb"), werden von Teams besucht oder besuchen Teams auf Anfrage. Supporter werden in der Regel vom Team-Product-Owner des Service-Teams (auch Service-Owner) geplant und haben ihre Auftragskarten normalerweise an ihrem eignen Team-Board.

Stakeholder sind Personen, die ein Interesse an den Teamergebnissen haben, aber nicht innerhalb dieses Teams arbeiten. Mitglieder anderer Teams können aus diesem Grund ebenfalls Stakeholder sein. Stakeholder nehmen am Iteration-Review eines Teams teil und geben ein offenes und transparentes Feedback.

Beschreibungen der Team-Arten („Team Flavors“)

Team-Arten beschreiben verschieden Aufstellungen von Teams innerhalb der Organisation, sowie deren Verantwortungsbereich.

Service-Team

Service-Teams erbringen eine Dienstleistung oder stellen Kompetenzen zur Verfügung.

Es gibt zwei Arten der Zusammenarbeit mit den anderen Teams:

  1. Dienstleistung: Teams beauftragen das Service-Team, das seine Arbeit auf einem Kanban-Board sichtbar macht und verwaltet
  2. Ressourcen-Provider: Einzelne Mitglieder des Service-Teams arbeiten als Extended Team Member zeitweilig in den Modul-Teams oder Applikations-Teams mit.

Anmerkung: Klassische Organisationen teilen ihre Abteilungen ebenfalls häufig nach Kompetenzen auf. Im P4-Framework sollen allerdings nur die Teams als Kompetenzteams arbeiten, die wirklich eine interne Dienstleistung erbringen. Alle anderen Mitarbeiter sollten in Modul- oder Applikation-Teams organisiert sein.

Module-Team und Plattform-Team

Modul-Teams haben die Verantwortung für versionierte Module oder Komponenten. Komplexe Systeme sind meist in Systemekemente oder Module als Untereinheiten aufgeteilt. Häufig kommen auch Plattformen oder Baukastenansätze zum Einsatz, bei denen die Module die Grundbausteine zur Kombination und zur Erstellung von Systemvarianten und Applikationen bilden. Häufig findet man in Modul-Teams spezifische Kompetenzen wieder, die nur für ein bestimmtes Modul benötigt werden.

Bei der Nutzung und Entwicklung von Modulen ist die Definition von Systemschnittstellen und deren langfristige Stabilität sowie Kompatibilität ein wichtiges Kriterium. Dafür arbeiten die Systemingenieure (Team-System-Engineer) der Modul-Teams in der Team-System-Engineer-Gruppe zusammen an den System-Architekturen.

Applikations-Team und Feature-Team

Applikations-Teams bauen aus den Modulen konkrete Applikationen, d.h. System-Varianten, die ggf. für bestimmte Märkte konfiguriert sind. Diese Teams können auch als "Produkt-Teams" bezeichnet werden, wenn das Produkt auf Entwicklungsebene nicht konfiguriert wird. Die Anforderungserhebung, Definition, Konfiguration, Integration und der Test der Anwendungen obliegt den interdisziplinären Applikation-Teams, die dabei die Verantwortung der Applikation über den kompletten Produkt-/ bzw. Systemlebenszyklus übernehmen.

Unterschiedliche System-Varianten können von unterschiedlichen Applikation-Teams betreut und verantwortet werden. Sind System-Varianten für ein Applikation-Team zu komplex, werden die Funktionen auf mehrere Feature-Teams verteilt. Wichtig ist die Festlegung, welches Team die Integration vornimmt. Meistens ist es dabei sinnvoll, ein Applikation-Team und mehreren Feature-Teams zu formieren.

Weitere Teams

In manchen Organisationen gibt es für die bessere Trennung von Entwicklungsthemen und Support- sowie Wartungsthemen  spezielle Support-Teams, die ungeplante Anfragen und Arbeiten annehmen, vorklären und einfachere Themen selbst lösen. Dadurch schirmen sie die Entwicklungsteams von ungeplanten Tätigkeiten ab und ermöglichen eine bessere Planbarkeit und Vorhersagbarkeit der Entwicklungsteams.

.


Passende und weiterführende Artikel: Team-Flavors und Team-Topologies

Events Rollen Gruppen Artefakte
Team-Planung

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-DoD

Team-Improvement-Backlog