Lorem ipsum dolor sit amet
Das Team ist das Basiselement einer agil arbeitenden Organisation und bildet die Heimat von Mitarbeitern.
Die meisten Arbeiten finden in stabilen und langlebigen Teams statt. Durch die Stabilität bzw. „Langlebigkeit“ sind die Teams bei Problemen 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 sie allen Beteiligten helfen, die Werte und Praktiken zu verstehen.
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).
Supporter arbeiten in ihrem Service-Team (Team-Flovor "gelb", siehe unten), werden von Teams besucht oder besuchen Teams auf Anfrage. Supporter werden in der Regel vom Service-Owner des "Expertenteams" geplant und haben ihre Auftragskarten normalerweise an ihrem eignen Team-Board.
Stakeholder sind Personen, die ein Interesse an den Teamergebnissen haben, aber nicht im Kontext 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 stellen Kompetenzen zur Verfügung oder erbringen eine Dienstleistung.
Es gibt zwei Arten der Zusammenarbeit mit den anderen Teams:
- Dienstleistung: Teams beauftragen das Service-Team, das seine Arbeit auf einem Kanban-Board sichtbar macht und verwaltet
- Ressourcen-Provider: Einzelne Mitglieder des Expertise-Teams arbeiten als Extended Team Member zeitweilig in den Module Teams oder Application Teams mit.
Anmerkung: Klassische Organisationen teilen ihre Abteilungen ebenfalls 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 Applikationsteams organisiert sein.
Module-Team
Modulteams haben die Verantwortung für Module oder Komponenten. Komplexe Systeme sind meist in Module als Einheiten 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 Modulteams 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 (System-Engineer) der Module in der Team-System-Engineer-Gruppe zusammen an der Architektur der Systeme
Applikations-Team und Feature-Team
Applikations-Teams bauen aus den Modulen konkrete Anwendungen, d.h. Systemvarianten, die ggf. für spezielle Märkte konfiguriert werden. Die Anforderungserhebung, Definition, Konfiguration, Integration und der Test der Anwendungen obliegt komplett diesen interdisziplinären Applikation-Teams, die dabei auch die Systemverantwortung über den kompletten Produkt-/ bzw. Systemlebenszyklus übernehmen.
Unterschiedliche Systemvarianten können von unterschiedlichen Applikation-Teams betreut und verantwortet werden. Sind einzelne Systemvarianten für ein Applikation-Team zu komplex, werden die Funktionen auf mehrere Feature-Teams verteilt. Wichtig ist die Festlegung, welches Team, in welcher Form die Integration vornimmt. Meistens ist es dann sinnvoll, sich in einem Applikation-Team und mehreren Feature-Teams zu organisieren.
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.
.
Ende
