Die Teams aller Cluster der Organisation, die Cluster-System-Engineer-Gruppe, die Cluster-Product-Owner-Gruppe und die Stakeholder müssen verstehen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als „Done“ bezeichnet wird. Obwohl sich die Cluster-DoDs erheblich von Cluster zu Cluster unterscheiden können, gibt es nur eine DoD auf Portfolio-Ebene für die gesamte Organisation.
Schlagwort: erledigt (done)
Cluster-DoD
Die Teams des Clusters, die Team-System-Engineer-Gruppe, die Team-Product-Owner-Gruppe und die Stakeholder müssen sich darauf einigen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als erledigt („Done“) bezeichnet wird. Obwohl sich dies erheblich von Cluster zu Cluster unterscheiden kann, müssen alle ein gemeinsames Verständnis davon haben, wann Arbeit erledigt ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition-of-Done des jeweiligen Clusters.
Die Cluster-DoD ist das Qualitätsversprechen des Clusters
Die DoD leitet die Team-System-Engineer-Gruppe auch bei der Entscheidung, wie viele Cluster-Backlog-Einträge es während des Cluster-Plannings in das Cycle-Backlog ziehen kann. Der Zweck jedes Zyklus ist es, inspizierbare Ergebnisse, verwendbares Wissen oder potenziell auslieferbare Funktionalität innerhalb eines System-Inkrements zu liefern, die der aktuellen Definition-of-Done entsprechen. Cluster liefern in jedem Zyklus ein Inkrement an Ergebnissen, Wissen und/oder Systemfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Cluster-Product-Owner sich jederzeit dazu entscheiden kann, es zu freizugeben.
Wenn die Definition-of-Done für ein Produkt Teil von Konventionen, Standards oder Richtlinien der Organisation ist, müssen alle Cluster diese als Minimalziel befolgen. Wenn „Done“ für ein Produkt nicht Teil der Konvention der Organisation ist, muss der Cluster (d.h. die TSEG) eine für das Produkt geeignete Definition-of-Done formulieren. Wenn es mehrere Cluster gibt, die am selben System arbeiten, müssen alle Cluster 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 Clustern wird erwartet, dass sie ihre jeweilige Definition-of-Done geeignet erweitern, 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 (auch als „technische Schulden“ bekannt).
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 |
| Cluster-Planning | Cluster-Product-Owner | Team-Product-Owner-Gruppe | Team-DoD
. Nutzbares-Wissen & System-Inkrement . |
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-Product-Owner | Working-Team | Inspizierbare-Ergebnisse
. . |
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-Product-Owner | Working-Team | Team-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-Product-Owner | Working-Team | Team-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-Product-Owner | Working-Team | Team-Backlog |