Session zum Thema Selbstorganisation und Delegation in Projektteams
Kontext
Keine Delegation von Aufgaben/Entscheidungen ("Ich mache das!") vs. deren vollständige Delegation ("Macht ihr mal!") unter der Prämisse der maximalen Selbstorganisation als Extreme
Thesen
- Delegation erfordert Selbstorganisation, egal ob die Delegation ins Team oder innerhalb vom Team erfolgt.
- In selbstorganisierenden Projektteams gibt es graduelle Delegationsformen (analog zu Delegation Poker) mit den beiden Extremen als Rahmen.
- In selbstorganisierenden Projektteams erhöht sich der Delegationsgrad über die Projektlaufzeit in aller Regel unbewusst schrittweise.
- Es ist aber sehr wahrscheinlich, dass während der Projektlaufzeit teaminterne Konflikte (Verhalten einzelner Teammitglieder) eintreten, bei denen es angebracht ist, den Delegationsgrad für bestimmte Aufgaben/Entscheidungen und/oder für einzelne Teammitglieder (proaktiv) wieder "zurückzustufen".
Diskussion
- Delegation Poker ist kaum bekannt und/oder praktiziert.
- Selbstorganisation und Delegation (allein) über Werte und Rollen zu regeln, funktioniert nicht. Werte werden dem Team oftmals "von aussen aufgedrängt" und Rollen vorab zu definieren bringt kaum einen Mehrwert.
- Scrum:
- Konflikte im Kontext von Delegation sollten im Daily bzw. spätestens in der Retrospektive eskaliert bzw. proaktiv aufgespürt werden.
- Auch in Scrum-Teams kann (und sollte) es pro Task ein einziges verantwortliches Teammitglied geben (das diesen Task zwar nicht alleine bearbeitet, aber für die erfolgreiche Bearbeitung des Task sorgt). In der Praxis wird diese Verantwortlichkeit oftmals zugewiesen (Push) und nicht eigeninitiativ eingenommen (Pull). Es werden vom PO also vielmehr Verantwortlichkeiten delegiert und nicht Aufgaben.
- Der Scrum Master sollte dafür sorgen, dass Delegation von den Teammitgliedern untereinander als auch gegenüber dem PO eingefordert wird (Pull).
- Es gibt auch Teammitglieder, die sich für zu vieles (auf einmal) verantwortlich fühlen und sich zu viel delegieren lassen. In diesem Fall bieten sich Kanban bzw. WiP Limits an, um solche Teammitglieder "vor sich selbst" zu schützen.
- Ein Projektmanager sollte an erster Stelle "People Management" betreiben und erst an zweiter Stelle delegieren.
- Alternativen:
- Experten-Teams statt cross-funktionale Teams: Delegieren ist "einfacher" (sofern das Team diese Arbeitsweise gewohnt ist und bevorzugt). -> Warum sollen Projektteams eigentlich immer so selbstorganisierend wie nur möglich sein (selbst in Scrum)? Selbstorganisation soll kein Selbstzweck sein.
- Im Extremfall können "problematische" Teammitglieder auch als 1-Mann-Teams "ausgelagert" werden, falls das verbleibende Projektteam so besser arbeiten kann. -> Konflikte müssen nicht immer im Team gelöst werden.
Fazit
Delegation muss über die ganze Projektlaufzeit hinweg und mit dem gesamten Projektteam adaptiv gehandhabt werden (Wer delegiert wie zu welchem Grad an wen?). Selbstorganisation ist hilfreich für das Delegieren ins Team und innerhalb vom Team, aber sie ist weder die einzige Voraussetzung noch die einzige Möglichkeit hierfür.
