Grenzen der Selbstorganisation in Scrum
10. Januar 2013
Selbstorganisation bedeutet nicht, dass ein Team machen kann, was es will. Vielmehr findet die selbstorganisierte Arbeit innerhalb gewisser Grenzen statt. Alle Dinge außerhalb dieser Grenze sind Rahmenbedingungen, die nicht durch das Team beeinflusst werden können. I.d.R. sind die zu entwickelnden Produkte, aber auch so triviale Dinge wie die zu verwendenden Bürostühle von außen vorgegeben.
Woran kann man nun aber festmachen, was selbstorganisiert durch ein Scrum-Team festgelegt wird und was eine nicht veränderliche Rahmenbedingung darstellt? Eine Regel hat sich für mich in der Praxis bewährt: Sobald durch teaminviduelle Regelungen die Team- oder unternehmensweite Zusammenarbeit beeinträchtigt wird, müssen teamübergreifende, einheitliche Standards definiert werden.
Damit solche übergreifende Probleme auch von Personen außerhalb der Scrum-Organisation eingebracht werden können, sollten in dem „Retro of Retro-Meeting“ auch Gäste zugelassen werden. Auch können Linienvorgesetzte den Auftrag an die Scrum Master geben, eine übergreifende Lösung zu finden.
Hierzu kurz ein Beispiel: Die Behandlung von User Stories in einem Bugtracker, die in einem Sprint nicht fertig gestellt werden, wird von jedem Scrum-Team anders gehandhabt. Ein Team verschiebt die Story in den nächsten Sprint. Das andere Team schließt die ursprüngliche Story und legt eine neue im nächsten Sprint an. Dadurch geht sowohl in der Integrations-QA, als auch im Rest des Unternehmens der Überblick verloren, welche User Stories fertig gestellt sind.
Die Rolle des ScrumMasters trägt die Verantwortung für die Implementierung und die unternehmensweite Integration des Scrum-Prozesses. Das o. g. Problem stellt ein Beispiel für ein Impediment dar, das die Integration des Scrum-Prozesses in das Unternehmen behindert. Auch „externe“ Impediments, die nicht die Arbeit im Team, sondern die Zusammenarbeit im Unternehmen negativ beeinflussen, müssen beseitigt werden.
Der ScrumMaster ist dafür verantwortlich, das Impediment im Backlog zu erfassen und eine übergreifende Lösung zu konzipieren. Dazu kann er in Abstimmung mit den Product Ownern auch die Unterstützung der Teams wie auch externer Ressourcen nutzen.
Die Einführung der übergreifenden Lösung erfolgt möglichst mit Zustimmung aller Teams. Wird kein Konsens erzielt, kann die Einführung auch durch direkte Anweisung durch den ScrumMaster erfolgen. Damit mischt sich der ScrumMaster auch in die Art und Weise ein, wie das Scrum-Team seine Arbeit erledigt. Dies wird durch seine Verantwortung für den Scrum-Prozess legitimiert.
Zum Weiterlesen:
Quelle Foto: © celeste clochard – Fotolia.com
| Keine Kommentare