Team-Collaboration-Poker

Team-Collaboration-Poker dient der gruppenbasierten Diskussion und der Verhandlung der Zusammenarbeit zweier Teams.

Anmerkung: Zurzeit sind die Team-Collaboration-Poker-Karten nur in Englisch verfügbar.

Die Zusammenarbeit zweier Teams kann sehr unterschiedlich und vielfältig sein. Das Kartenspiel geht von einer typischen Situation eines Applikations-Teams und eines Service- oder Konponenten-Teams aus, wobei die Dienstleistung oder die zu entwicklende (oder zu erweiternde) Komponente in die Applikation integriert werden soll. Bei der Festlegung der Zusammenarbeit geht nun darum, welches Team welche Arbeiten und Verantwortlichkeiten übernimmt. Dazu werden folgende Optionen angeboten:

1. Order: Team A bestellt nur den Service-/Komponentenwechsel und die Anwendungsintegration bei Team C. Alle Arbeiten werden im Backlog von Team C erfasst. Team C führt alle Arbeiten aus.
2. Partialy Integrate: Team A beauftragt Team C mit der Durchführung der Service-/Komponentenänderung. Die Anwendungsintegration wird teilweise von Team C und A durchgeführt. Die Arbeit wird in beiden Backlogs widergespiegelt.
3. Integration by temporary C Supporter: Team A beauftragt Team C mit der Durchführung der Service-/Komponentenänderung. Ein Mitglied von Team C wechselt vorübergehend zu Team A, um die Integration durchzuführen. Die Kapazität beider Teams ändert sich vorübergehend!
4. Integration by permanent Extended C Team: Team A beauftragt Team C mit der Durchführung der Service-/Komponentenänderung. Ein Mitglied des erweiterten Teams von A&C integriert die Komponente in den Kontext von Team C. Alle Arbeiten werden im Backlog von Team C erfasst.
5. Integration by permanent Extended A Team: Team A beauftragt Team C mit der Durchführung der Service-/Komponentenänderung. Ein Mitglied des erweiterten Teams von A&C integriert die Komponente in den Kontext von Team A. Die Integrationsarbeit wird in den Backlogs von Team A berücksichtigt.
6. Integration by planned C support activity: Team A beauftragt Team C mit der Durchführung der Service-/Komponentenänderung. Team C unterstützt Team A bei der Integration gemeinsam mit Team A. Die Integrationsunterstützung spiegelt sich im Backlog von Team C wider.
7. Delivery only: Team A beauftragt Team C mit der Änderung des Dienstes/der Komponente. Team A führt alle Integrationsarbeiten selbst durch. Die Integrationsarbeiten sind nur in den Backlogs von Team A enthalten.
8. Partially Independent: Team A führt den Service/die Komponentenänderung alleine durch. Team C unterstützt Team A lediglich bei der Durchführung der Arbeit. Die Arbeit wird im Backlog von Team A erfasst, mit Ausnahme der Unterstützung im Backlog von Team C.
9. Fully Independent: Team A führt den Service-/Komponentenwechsel und die Integration alleine durch. Team C ist nicht beteiligt. Alle Arbeiten werden im Backlog von Team A erfasst.

Warum gruppenbasiert?

• Es vermeidet einseitige Sichtweisen durch den Blick aus vielen Blickrichtungen.
• Es fördert die strukturierte Diskussion in der Gruppe. Auch stille Team-Mitglieder werden angeregt, ihre Meinung zu äußern.
• Allen in der Gruppe wird klarer, um was es sich genau handelt (was gehört dazu, was nicht). Diese Erkenntnisse werden in Form von Akzeptanzkriterien, Randbedingungen und Umsetzungsideen notiert.

Bei der Einschätzung in Gruppen gibt es allerdings das Ankerproblem, wobei der erste, der seine Einschätzung nennt, bei allen anderen eine unbewusste Anpassung ihrer persönlichen Schätzung an diese Referenz (den „Anker“) auslöst. Dies lässt sich durch eine vorherige geheime Festlegung der persönlichen Einschätzung beseitigen. Genau hierfür gibt es die Delegation-Poker-Karten.