Bei einem der Posts zum 69er Projekt habe ich einen Kommentar bekommen, der auf die Pitfalls von Scrum eingeht. Es geht im wesentlichen um die Frage, ob man ohne ScrumMaster ein Scrum Projekt führen kann und was unsere Erfahrungen sind.
"In addition to the disengaged ScrumMaster, there is the team where a worker bee also tries to be ScrumMaster. This works fine as long as the team does not encounter too many impediments. If the team does encounter impediments, however, either the impediments will not be resolved (because the worker bee role is consuming too much time) or the work will not be completed (because the worker bee is now running around trying to eliminate impediments). For this reason, I no longer have team members perform the ScrumMaster role while actually doing work on a sprint (unless it is a very small amount of work)." Boris Gloger, Pitfalls in ScrumNun ja, genau diese Erfahrungen kann ich bestätigen. Kleine Hindernisse kann das Team selbst lösen. Werden diese zu Blocking oder mengenmässig grösseren Hindernissen, leidet das Team und damit das Ergebnis.
Beim 69er Projekt wurde das offen in der Retrospective Sprint 2 diskutiert. Das Team bat um einen ScrumMaster. Da man sich allerdings bereits im 3. von 4. Sprints befindet und eine Einarbeitung Zeit und Aufwand bedeutet, hat das Team davon abgesehen.
Die Erkenntis:
Im nächsten Scrum Projekt nur noch mit ScrumMaster.
1 Kommentar:
Meine Erfahrungen zeigen, dass ein ScrumMaster extrem wichtig ist. Wenn alles gut läuft, hat der SM sehr wenig zu tun und kann sich anderen Dingen widmen.
Falls es jedoch Probleme gibt, dann muss der SM verfügbar sein und aktiv an der Beseitigung der Probleme arbeiten.
Selbst wenn der SM nicht komplett eingearbeitet ist, kann er vieles bewirken. Fachliches/technisches Know-how kann er vom PO/Team erfragen. Entscheidend ist, dass er ZEIT hat die Impediments anzugehen.
Also: Nie ein Projekt ohne SM, falls es Probleme gibt, muss der SM die Möglichkeit haben sich Zeit zu verschaffen.
Kommentar veröffentlichen