Team-Tasks

Team-Tasks sind Aufgaben und Aktionen, die ein Working-Team plant und durchführt, um Team-Ziele zu erreichen. Team-Tasks sind Teil des Iteration-Backlog und werden in der Regel erst im Team-Planning erfasst und geplant.

.

\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

Working-Team

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-Retrospektive

Die Team-Retrospektive bietet dem Team die Gelegenheit, sich selbst zu überprüfen und Verbesserungen der Arbeitsweise für die kommende Iteration zu identifizieren und zu einzuplanen. Sie findet zwischen dem Team-Review und der nächsten Team-Planning statt. Für eine vierwöchige Iteration wird hierfür eine Obergrenze von drei Stunden angesetzt. Bei kürzeren Iterationen ist das Meeting in der Regel kürzer. Der Scrum-Master sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen. Der Scrum-Master sorgt dafür, dass das Meeting konstruktiv und produktiv ist. Der Scrum-Master lehrt alle, den Zeitrahmen einzuhalten (Time-box). Aufgrund seiner Verantwortung für den P4-Prozess nimmt der Scrum-Master als gleichberechtigtes Mitglied an der Team-Retrospektive teil. Die Team-Retrospektive wird durchgeführt, um …

  • zu überprüfen wie die vergangene Iteration in Bezug auf die beteiligten Personen, Beziehungen, Prozesse, Infrastruktur und Werkzeuge verlief;
  • die wichtigsten und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und
  • einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Teams zu erstellen.

Der Scrum-Master bestärkt das Team darin, seine Entwicklungsprozesse und -praktiken innerhalb des P4-Frameworks zu verbessern, um in der kommenden Iteration effektiver und befriedigender arbeiten zu können. In jeder Team-Retrospektive erarbeitet das Team Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Prozesse oder der Definition-of-Done, sofern diese Änderungen angemessen sind und nicht im Widerspruch mit Produkt- oder Unternehmensstandards stehen. Zum Ende der Team-Retrospektive sollte das Team Verbesserungen für die kommende Iteration identifiziert haben. Die Umsetzung dieser Verbesserungen in der nächsten Iteration ist die Anpassungsleistung zur Selbstüberprüfung des Teams.

Für den Ablauf der Team-Retrospektive gibt inzwischen sehr viele methodische Ansätze und Fragestellungen, z.B.

  • Glad, Sad, Mad
  • Keep, Change, Puzzled
  • Good, Problems, Questions
  • Start, Stop, Keep, More, Less

Unter Fun-Retrospectives oder dem Retromat findet man viele weitere Ideen und Anregungen.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

.

Cluster-Retrospective

.

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-Review

Am Ende jeder Iteration wird ein Team-Review abgehalten, in dem das Team den Stakeholdern die Ergebnisse vorstellt, wobei das Team Feedback von den Stakeholdern zu diesen bekommt, um dann gemeinsam bei Bedarf das Team-Backlog anzupassen. Zusammen mit eventuellen Änderungen am Team-Backlog, die während der Iteration eingeflossen sind (z.B. in den Team-Backlog-Refinements), bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Team-Produkts steigernden Einträgen. Beim Team-Review handelt es sich um ein informelles Meeting, keinen Statusreport im klassischen Sinn. Die Vorführung der Ergebnisse ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht. Am Ende des Team-Reviews kann der Team-Product-Owner ein Update zu Kosten und geplanten Terminen bzw. Meilensteinen geben.

Für eine vierwöchige Iteration wird für dieses Meeting eine Obergrenze von vier Stunden als Zeitrahmen angesetzt. Für kürzere Iterationen wird ein entsprechender kürzerer Zeitrahmen veranschlagt. Der Team-Scrum-Master stellt sicher, dass das Event stattfindet und die Teilnehmer seinen Zweck verstehen. Der Team-Scrum-Master bringt allen Beteiligten bei, das Event innerhalb des vorgegebenen Zeitrahmens durchzuführen.

Das Team-Review beinhaltet die folgenden Elemente:

  • Die Teilnehmer, bestehend aus dem Team und wichtigen Stakeholdern, die vom Team-Product-Owner eingeladen werden.
  • Der Team-Product-Owner erklärt, welche Team-Backlog-Einträge (TBI) erledigt sind.
  • Das Working-Team stellt dar, was während der Iteration gut lief, welche Probleme aufgetaucht sind, und wie es diese Probleme gelöst hat. Das Team erfragt dabei ggf. Unterstützung durch die Stakeholder.
  • Das Working-Team führt die erledigten Arbeitsergebnisse vor, und beantwortet Fragen dazu. Arbeitsergebnisse können sein:
    • inspizier- und bewertbare Ergebnisse,
    • nutzbares Wissen,
    • eine integrierte Version des Systems, Plattform oder Applikation
  • Der Team-Product-Owner stellt den aktuellen Stand des Team-Backlogs vor. Er gibt bei Bedarf eine aktualisierte Prognose von wahrscheinlichen Ziel- und Lieferterminen auf der Basis des Entwicklungsfortschritts, z.B. durch Nutzung eines Burn-up-Charts auf Basis der Arbeitsgeschwindigkeit des Teams (Velocity)
  • Alle Teilnehmer erarbeiten gemeinsam, was als nächstes zu tun ist, so dass der Team-Product-Owner wertvollen Input für das kommende Team-Planning bekommt.
  • Anschließend werden Zeitplan, Budget, sowie die potentiellen Eigenschaften und Markterwartungen für die nächste Version der Applikation (Release) überprüft.

Das Ergebnis des Team-Reviews ist ein überarbeitetes Team-Backlog, das dem gemeinsamen Wissenstand der Teilnehmer entspricht und durch das das Team in der nächsten Iteration an den Team-Backlog-Einträgen mit dem höchsten Wert arbeiten kann. Das Team-Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Retrospektive

.

Cluster-Review

.

Portfolio-Review

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-Backlog-Refinement

Als Refinement (Verfeinerung) des Team-Backlogs wird der Vorgang angesehen, in dem Details zu Backlog-Einträgen hinzugefügt, Schätzungen erstellt, und die Reihenfolge der Team-Backlog-Einträge bestimmt werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Team-Product-Owner und das Working-Team gemeinsam die Team-Backlog-Einträge detaillieren. Bei der Verfeinerung des Team-Backlogs werden die Einträge begutachtet und revidiert. Es sollte normalerweise nicht mehr als 10% der Kapazität des Working-Teams beanspruchen. Der Team-Product-Owner kann jedoch jederzeit die Einträge im Team-Backlog aktualisieren oder aktualisieren lassen.

Das Team-Backlog-Refinement dient hauptsächlich der Vorbereitung des nächsten Team-Planning. Dabei stellt der Team-Product-Owner dem Working-Team neue Team-Backlog-Einträge vor und lässt diese vom Working-Team schätzen. Stehen Einträge kurz vor dem Beginn der Arbeiten, achtet das Team darauf, dass die Einträge klein genug sind, damit sie in eine Iteration gezogen werden können. (Dies ist eine Voraussetzung für das „Pull“ und wird oft auch als Teil der Definition-of-Ready (DoR) bezeichnet). Ist dies nicht der Fall, verfeinert das Team den entsprechenden Eintrag durch Zerteilen in mehrere Einträge (Splitting).

Arbeitet das Team nicht in Iterationen, sondern kontinuierlich mittels Kanban, vereinbart das Team ein Schätzlimit, ab dem das Zerteilen von Backlog-Items nötig wird.

Schätzung des Realisierungsaufwands von Backlog-Einträgen

Schätzungen durch das gesamte Team sind aus zwei Gründen wichtig

  1. Durch das gemeinsame Schätzen analysiert das komplette Team den jeweiligen Backlog-Eintrag aus verschiedenen Blickwinkeln und reichert diesen dabei mit Informationen an, wie Akzeptanzkriterien und Randbedingungen. Außerdem werden erste Ideen zur Umsetzung erzeugt.
  2. Das Ergebnis der Schätzung ist eine Zahl, mit der einzelne Backlog-Elemente bewertet werden können, z.B. zur Priorisierung. Außerdem lässt sich nun einfach errechnen, wie viele Elemente in eine Iteration gezogen werden können, nämlich durch Vergleich der in den letzten Iterationen fertiggestellten Backlog-Elementen (Velocity des Teams).

Zur Schätzung des Aufwands bedient sich das Team der Methodik des Planning-Poker®.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Review

Team-Retrospektive

.

Cluster-Backlog-Refinement

.

Portfolio-Refinement

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-Sync (Daily Scrum)

Das Team-Sync ist ein täglich wiederkehrendes Team-Event von nicht mehr als 15 Minuten, in dem sich die Mitglieder des Working-Teams „auf Augenhöhe“ synchronisieren, ohne an einen Vorgesetzten zu berichten. Der Team-Product-Owner nimmt hieran nur teil, wenn das Team ihn einlädt. Auch der Team-Scrum- Master muss nicht teilnehmen, wird aber insbesondere bei noch nicht reifen Teams als Unterstützung benötigt.

Das Team-Sync findet (meist im Halbkreis) vor dem Scrum/Kanban-Board des Teams statt. Dort bewegen die Team-Mitglieder auch die Aufgabenkarten und TBI-Karten.

Typischerweise beantwortet jedes Team-Mitglied drei Fragen:

  1. Was habe ich seit dem letzten Team-Sync gemacht und erreicht? (Das Team-Mitglied verschiebt dabei ggf. Karten nach „done“)
  2. Was werde ich bis zum nächsten Team-Sync tun? (Das Team-Mitglied zieht dabei ggf. eine Karte von „open“ nach „in progress“)
  3. An welchen Stellen bin in blockiert und benötige Hilfe anderer Team-Mitglieder?

Zur Unterstützung des Ablaufs benutzen viele Teams einen Gegenstand als „Sprecher-Token“, der von Team-Mitglied zu Team-Mitglied wandert und anzeigt, wer gerade an der Reihe ist.

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

Besucher im Team-Sync

Besucher, die das Team-Sync miterleben wollen, können mit Erlaubnis des Working-Teams teilnehmen. Dabei stehen die Besucher in der zweiten Reihe und hören nur zu (was im englischen gerne als Chicken bezeichnet wird), außer sie werden von einem Team-Mitglied angesprochen. Besucher können sein:

Extended-Team-Sync

Ein oder mehrmals pro Woche kommen auch die Mitglieder des Extended Teams zum Team-Sync, was dann als Extended Team-Sync bezeichnet wird. Sie beantworten ihre drei Fragen entsprechend …

  1. Was habe ich seit dem letzten Extended Team-Sync für dieses Team gemacht und erreicht?
  2. Was werde ich bin zum nächsten Extended Team-Sync für dieses Team tun?
  3. An welchen Stellen bin in blockiert und benötige Hilfe anderer Team-Mitglieder?

Da Mitglieder des Extended Teams per Definition mit mehreren Teams arbeiten, ist darauf zu achten, dass die Extended Team-Syncs dieser Teams zu unterschiedlichen Zeitpunkten stattfinden, so dass die Mitglieder des Extended Teams auch die Gelegenheit haben daran teilzunehmen. Innerhalb der Organisation, mindestens innerhalb des Clusters, ermöglicht eine aufeinander abgestimmte Kadenz (Cadence) von Events eine minimale Überlappung und einen optimalen Workflow.

Joint-Team-Sync

Arbeiten zwei Teams sehr eng zusammen, ist es ggf. sinnvoll, dass sie ein oder mehrmals pro Woche ein gemeinsames (Joint) Team-Sync durchführen. Dabei hört jeweils ein Team zu, während das andere sein Team-Sync durchführt und danach umgekehrt.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Sync

.

Organisations-Sync

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Iteration

Die Iteration ist eine Timebox von fester Länge für jedes der Teams innerhalb eines Clusters und entspricht einem ständigen Grundtakt. Normalerweise wählen alle Teams innerhalb des Clusters  die gleiche Iterationslänge, insbesondere dann, wenn sie Abhängigkeiten zueinander, oder Lieferbeziehungen miteinander haben.

Weiterlesen

Team-Planning

Iterationsplanung (Scrum)

Jede Iteration beginnt mit einem Team-Planning-Event. In diesem präsentiert der Team-Product-Owner dem Working-Team den aktuellen Stand des Team-Backlogs. Neue Einträge oder Änderungen, die dem Working-Team seit dem letzten Team-Backlog-Refinement noch nicht bekannt sind, werden geschätzt, ggf. durch Akzeptanzkriterien ergänzt und vom Product-Owner innerhalb des Team-Backlogs priorisiert.

Das Working-Team ermittelt die Kapazität für die nächste Iteration durch einen Blick auf die bisherige Arbeitsgeschwindigkeit des Teams (Team-Velocity) und durch Ausfüllen des Teamkalenders, der für jedes Team-Mitglied die Arbeitszeit anzeigt, die es für das Working-Team in der kommenden Iteration leisten kann.

Das Working-Team zieht die Anzahl von Team-Backlog-Items (TBI), die der Einschätzung des Teams über die Kapazität der nächsten Iteration entspricht, in das Iteration-Backlog (Pull) und verfeinert danach die TBIs, je nach Komplexität, durch Definition von Aufgaben (Tasks), die zur Fertigstellung des TBI nötig sind.

Danach startet das Working-Team die Iteration durch ziehen der ersten Aufgaben von „open“ nach „in progress“.

Kontinuierliches Team-Planning (Kanban)

Alternativ zum Planungsrhythmus in Iterationen, kann die Planung der Arbeiten für das Team auch kontinuierlich erfolgen. Hierfür werden die Team-Backlog-Refinements genutzt, wobei ein Team-Backlog-Items, direkt nach der Analyse und Schätzung, in Bearbeitung gehen kann.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Planning

.

Portfolio-Planung

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Team-Scrum-Master (TSM)

Team-Scrum-Master (TSM)

Der TSM sorgt dafür, dass die Mitglieder seines Teams optimal arbeiten können. Er sorgt für einen optimalen Arbeitsfluss zwischen den Team-Mitgliedern, durch Entdecken von Verbesserungen und Lösen von Behinderungen und Problemen (dargestellt im Team-Improvement-Backlog), die in der Zusammenarbeit der Teams auftreten. Dies betrifft insbesondere solche, die durch das selbstorganisierte Working-Team nicht eigenständig gelöst werden können.

Hierfür organisiert und moderiert der TSM die Team-Retrospektive, in der sich die Team-Mitglieder austauschen um ein Optimum der Arbeitsbedingungen und des Arbeitsflusses innerhalb des Teams anstreben.

Der Team-Scrum-Master arbeitet mit anderen TSMs innerhalb des Clusters in der Team-Scrum-Master-Gruppe (TSMG) zusammen, um lokale Optimierungen innerhalb des Teams zu verhindern und Probleme bei der Zusammenarbeit mehrere Teams zu beheben.

Hier geht es zur allgemeinen Beschreibung der Scrum Master Rolle.

.

\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

.

Cluster-Scrum-Master

.

Organisations-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Das Team und die Team-Ebene

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.

Weiterlesen