IT-Tage 2023, Frankfurt am Main (Patrick Albert) Die Rollen und insbesondere deren Zuständigkeiten sind in Scrum recht klar geregelt: Der Product Owner sorgt für das "Was", der Scrum Master für das "Wie" und die Developer für die eigentliche Umsetzung. Solange es sich dabei um ein internes Projekt mit einem komplett internen Team handelt, sind damit bereits die zentralen Fragen beantwortet. Ein wenig differenzierter zu betrachten sind allerdings Teams mit mehreren Parteien wie etwa beim Einsatz von Dienstleistern. Muss etwa zwingend der Kunde den Product Owner stellen oder kann dieser auch auf der Seite des Dienstleisters stehen? Falls alle Developer vom gleichen Dienstleister bereitgestellt werden, würde diese Konstellation sicherlich einige Kommunikationswege verkürzen. Allerdings hat ein Product Owner auf der Seite eines Dienstleisters sicher nicht die gleichen Verbindungen zu den Stakeholdern (Nutzer, Geldgeber, ...) des Produkts wie ein interner Product Owner – wie also könnte er ihre Anforderungen dann gut vor dem Team vertreten? Ähnliche Fragen stellen sich auch für den Scrum Master und das Development-Team. In den meisten Fällen gibt es für verschiedene Konstellationen jeweils Vor- und Nachteile – und zwar sowohl für den Kunden als auch für den Dienstleister. Wichtig bei der Entscheidung für eine dieser Konstellationen ist außerdem die Art des Projekts, der Kreis der Stakeholder, das zur Verfügung stehende Budget, der Zeitrahmen und noch einiges mehr. Dieser Vortrag beleuchtet verschiedene dieser Varianten und zeigt Vorteile, Nachteile und Risiken auf.

1. qaware.de
Effektive Projektarbeit trotz
(oder aufgrund von?)
"mixed Teams"
Patrick Albert
patrick.albert@qaware.de
14.06.2023
Effektive Projektarbeit trotz
(oder aufgrund von?)
"mixed Teams"
Patrick Albert

2. Patrick Albert
Senior IT Project Manager
#mainz #qaware #agile
#cloudnative

3. Papier ist war geduldig -
und die Projekte starr und unbeweglich
■ Monatelange Pflichtenheft-Phase
■ Oft sogar eigenes Angebot zur Pflichtenheft-Erstellung
■ Erst nach der Abnahme startete die Umsetzung
■ Umsetzung zu 100% auf Seiten des Dienstleisters
Pixabay

4. The Agile Way
Es gibt keinen Plan und neue Wünsche sind
(spätestens) morgen umgesetzt
■ Viel Zusammenarbeit und Interaktion mit dem Kunden
■ Start der Umsetzung bereits kurz nach Projektstart
■ Reaktionen auf geänderte Anforderungen immer möglich
■ Meist unerlässlich: Mixed Teams zur effektiven Zusammenarbeit
Pixabay

5. Mixed Teams haben es nicht leicht…
5 große Challenges für “Mixed Teams”:
■ Kommunikation: Wer redet wann wie mit wem?
■ Working Styles & Kultur: Für dich immer noch “Sie”, bitte!
■ Priorisierung: Das ist wichtiger, das sieht man doch!
■ Koordinierung: Wie, du hast morgen frei?
Warum weiß ich das nicht?!
■ Ownership: Mir doch egal - ist doch nur ein Projekt
wie andere auch.
Pixabay

6. …aber auch durchaus Vorteile
5 Vorteile von “Mixed Teams”:
■ Wissen: Lasst uns voneinander lernen und profitieren!
■ Nähe zum Anwender: Du kennst die Nutzer doch am besten…
■ Verantwortlichkeit: Alle sitzen im gleichen Boot.
■ Flexibilität: Kurze Wege fördern flexible Arbeitsmethoden
■ Risikomanagement: Aus zwei Perspektiven sieht man besser.

7. Variante 1: Komplettes Team beim Dienstleister
Pixabay

8. Variante 1: Komplettes Team beim Dienstleister
■ Ziel: Besonders enge Zusammenarbeit
Pixabay
■ Top:
○ Schnelle und effektive Kommunikation
○ Gleiche Kultur, gleiche Tools, viel
persönlicher Kontakt
■ Risk:
○ Das Ziel nicht gut genug kennen
○ Kunde kann nicht genügend steuern
■ Wann?
○ Klarer Scope
○ Wenige Änderungen
○ Nicht allzu komplexe Fachlichkeit

9. Variante 2: Nur Product Owner beim Kunden
Pixabay

10. Variante 2: Nur Product Owner beim Kunden
■ Ziel: “Was” beim Kunden, “wie” beim Dienstleister.
Pixabay
■ Top:
○ Guter Kontakt zu den wichtigen Stakeholdern
○ Gute Kenntnis des Projekt-Kontext
■ Risk:
○ Mangelnde Verfügbarkeit des POs
○ Eingeschränkter Blick auf den Kunden
(nur durch PO)
■ Wann?
○ Der “Klassiker”
○ Durchführungsverantwortung beim Dienstleister
○ Komplexe Anforderungen

11. Variante 2a: PO beim Kunden + Proxy-PO
■ Ziel: Schlechte PO-Verfügbarkeit puffern
Pixabay
■ Top:
○ Puffert PO-Verfügbarkeit gegenüber dem Team
○ Mandat für kleinere Entscheidungen
■ Risk:
○ Fehlendes Mandat → mehr statt weniger Aufwand
○ Missverständnisse, falls Rollen nicht klar kommuniziert
■ Wann?
○ PO nicht ausreichend verfügbar
○ Großes Team auf Seite des Dienstleisters
○ Möglichkeiten zur “Entscheidungs-Teilung”

12. Variante 3: PO + SM beim Kunden
Pixabay

13. Variante 3: PO + SM beim Kunden
■ Ziel: Möglichst viel Kontrolle durch den Kunden
Pixabay
■ Top:
○ Bessere PO-Verfügbarkeit durch “PO-nahen” SM
○ Kunde steuert auch prozessual
■ Risk:
○ SM nicht gut verfügbar für Developer → Velocity leidet
○ Koordination zwischen DL-Projekten ist schwierig
○ EWF-Thematik zu beachten
■ Wann?
○ Durchführungsverantwortung beim Kunden
○ Einbindung in komplexe Projektstruktur beim Kunden

14. Variante 4: “Sogar” Developer beim Kunden
Pixabay

15. Variante 4: “Sogar” Developer beim Kunden
■ Ziel: Kunde will eigene Teams unterstützen
Pixabay
■ Top:
○ Gegenseitiges Lernen unter Entwicklern
○ Kunde auf allen Ebenen vertreten
■ Risk:
○ Aufwandsschätzungen & Controlling schwieriger
→ Festpreis kaum machbar, stattdessen T&M
○ EWF-Thematik noch stärker zu beachten
■ Wann?
○ “punktuelle” Unterstützung statt ganzes Team benötigt

16. Verantwortung bedeutet auch Pflicht
Pexels

17. Verantwortung bedeutet auch Pflicht
Team komplett beim Dienstleister Team komplett beim Kunden
Verantwortung beim
Dienstleister
Verantwortung beim
Kunden
Verantwortung für die Durchführung:
■ Zeit- / Sprintplanung
■ Teamgefüge
■ Budget
Verantwortung für das Ergebnis:
■ Funktionalität
■ Qualität
■ Architektur
■ Dokumentation

18. Früher oder später kommt’s:
Lass uns über Geld reden
Pixabay

19. Faire agile transparente Abrechnung - ein Widerspruch?
Variante 1: Komplett festgelegt
Der Festpreis
■ Klare Themen - klarer Preis
■ Agilität durch “wir tauschen im Projekt Themen unter der Hand”
■ Vorteile
– Inhaltliche Klarheit auf beiden Seiten
– Gern gesehen beim Einkauf des Kunden
■ Nachteile
– Thementausch benötigt hohes Vertrauen - für beide!

20. Faire agile transparente Abrechnung - ein Widerspruch?
Variante 2: Komplett variabel
■ Keine genauen Themen im Angebot
Time and Material
■ Stundensatz x Aufwand = Endpreis
■ Gerade in agilen Projekten mit Dienstleistern oft genutzt
■ Vorteile
– Transparent und einfach.
– Schnelle Angebotserstellung.
■ Nachteile
– Diskussionen über Querschnittsaufwände oder Stundensätze
Einzel-Pakete “on demand”
■ Statt Stundensätze werden Komplexitätsklassen (T-Shirt-Größen, Storypoints, …) verkauft
■ Vorteile
– Sehr flexibel - und trotzdem nach Komplexität statt Zeit abgerechnet
■ Nachteile
– Beim Einkauf des Kunden nur ungern gesehen

21. Faire agile transparente Abrechnung - ein Widerspruch?
Variante 3: Der Mittelweg
Der agile Festpreis
■ Themen sind Teil des Angebots
■ Tausch gleich großer Themen explizit möglich
■ Vorteile
– Kein T+M - und trotzdem auf Angebots-Level flexibel
– Vertretbarer für den Einkauf als reines “on demand”

22. Der agile Festpreis
Basics
■ Beschreibung einzelner Themen wie beim Festpreis-Angebot
■ Größe für jedes Thema separat ausgewiesen
■ Einvernehmlicher Thementausch mit gleicher Größe explizit möglich
→ “Tausche 2x S gegen 2x S”
■ Abnahme: Geleistete Themen vs. angebotene Themen auflisten
Abrechnung
■ Abrechnung nach “T-Shirt-Größen”
– Nachteil: Leichte Unschärfe durch Gruppierung
→ Im Durchschnitt sollte es passen
■ Abrechnung nach “Story-Points”
– Nachteil: Exakter Tausch nur selten möglich
→ Angebotssumme nur näherungsweise erreicht
Pixabay

23. Lass es
gut
werden!
Pixabay

24. Lass es
gut
werden!
P
r
o
j
e
k
t
-
I
d
e
n
t
i
t
ä
t
Team
gedanke Gem
einsam
es
Toolset
Passendes
Setup
K
o
m
m
u
n
i
k
a
t
i
o
n
s
-
R
e
g
e
l
n
Passendes Setup
■ Welche Rolle auf welcher Seite?
■ Sinnvoll für beide Seiten
■ Klare Zuständigkeiten und Mandate
Kommunikationsregeln
■ Wer mit wem?
■ Zu welchem Thema?
■ Wann und wie?
Gemeinsames Toolset
■ Messaging
■ Collaboration
■ Development
■ Management
Teamgedanke
■ Vertrauen aufbauen
■ Für Transparenz sorgen
■ Regelmäßige Retrospektiven
Projektidentität
■ Kultur
■ Logo

25. Vielen Dank!
Habt Ihr Fragen?