Multiple Persönlichkeiten in Scrum?
23. November 2009
Die agile Softwareentwicklung ist in aller Munde. So Erfolg versprechend Agilität sein mag, ihre Einführung gestaltet sich oftmals schwierig. Ein häufig auftretendes Problem sind Rollenkonflikte, die sich daraus ergeben, die Rollen „Product Owner“, „ScrumMaster“ und „Team“ geeignet zu besetzen. Der Einfachheit halber wird also unter Umständen ein und dieselbe Person zum Teammitglied, Product Owner und Scrum Master ernannt.
Kann Agilität mit dieser Rollenverteilung überhaupt funktionieren? Sehen wir uns die Aufgaben der Person an, die die drei Scrum-Rollen auf sich vereint: Als Product Owner ist sie für den Produkterfolg verantwortlich und muss sich um Sammlung und Priorisierung von Anforderungen kümmern. Als Scrum Master schützt sie das Team vor Störungen von außen und räumt dem Team Hindernisse beiseite. In ihrer Rolle als Teammitglied fühlt sie sich für die erfolgreiche Umsetzung der Anforderungen des aktuellen Sprints verantwortlich. Alles in allem also eine Menge von Aufgaben, die diese Person bewältigen muss. Noch schlimmer ist, dass sich die Wahrnehmung all dieser Aufgaben zumindest in Teilen gegenseitig ausschließt.
Wie soll es funktionieren, wenn man als Teammitglied fokussiert Anforderungen umsetzen soll und gleichzeitig das zeitaufwändige Anforderungsmanagement bewältigen soll? Die einzig denkbare Lösung wäre ein Timeboxing des Anforderungsmanagements, um trotz Doppelrolle ein Commitment für den aktuellen Sprint abgeben zu können. Ich kann mir allerdings nicht vorstellen, wie so etwas funktionieren soll. Das Anforderungsmanagement ist essentiell und sollte nicht mit niedriger Priorität behandelt werden. Gleichzeitig stellt sich die Frage, ob ein Product Owner als Teammitglied nicht dazu neigen wird, seine Vorstellung von der Realisierung der Anforderungen durchzusetzen. Damit wäre dann die Selbstorganisation des Teams behindert. Auch der Abnahmeprozess ist problematisch. Wie kann ein Product Owner die selbst implementierte Software abnehmen?
In seiner Rolle als Scrum Master muss dieses Super-Talent obendrein dafür sorgen, dass das Team vor Störungen von außen geschützt wird. Diese Schutzfunktion wird das Super-Talent nur bedingt ausüben können, da es als Product Owner die Verantwortung für den Produkterfolg trägt. Wenn es also eine dringende Aufgabe gibt, die für das Produkt mal eben erledigt werden muss, wird die Schutzfunktion im Zweifel zurückstehen müssen, um die Erledigung der Aufgabe im Team zu initiieren. Das Commitment des Teams für den aktuellen Sprint wäre gefährdet.
Ich kann demnach nicht empfehlen, die Rollen Scrum Master, Product Owner und Teammitglied in einer Person zu vereinen. Diese Person wäre nicht nur hoffnungslos überlastet, sondern würde auch den Erfolg des Produkts gefährden, da Commitments nicht eingehalten werden können oder das Anforderungsmanagement zu kurz kommt.
Eine andere nicht ganz so glückliche Konstellation ist die Vereinigung von Scrum Master und Teammitglied in einer Person. Zumindest in einer frühen Projektphase wird es Probleme geben, da die Scrum Master-Tätigkeit einen verhältnismäßig hohen Zeitaufwand in Anspruch nimmt. Für das Team ist es problematisch, ein Commitment für den aktuellen Sprint zu geben, wenn nicht prognostizierbar ist, in welchem Umfang der Scrum Master für die Umsetzung zur Verfügung stehen wird. Typischerweise jedoch nimmt der zeitliche Aufwand für die Scrum Master-Tätigkeit im Projektverlauf deutlich ab, so dass es durchaus funktionieren kann, beide Rollen miteinander zu kombinieren. Nichtsdestotrotz wird es immer wieder zu Konflikten kommen, wenn es um Hindernisse im Team geht. Der Scrum Master kann schließlich keine neutrale Position einnehmen, da er ja selbst ein Teammitglied mit eigenen Interessen ist.
Auf gar keinen Fall sollte eine Person alle drei Scrum-Rollen in sich vereinen. Genau so wenig sollte eine Person gleichzeitig Scrum Master und Product Owner sein. Ich halte es jedoch für vertretbar, wenn eine Person sowohl Teammitglied als auch Scrum Master ist. Ebenfalls denkbar ist die Kombination von Product Owner und Teammitglied. Man müsste sich in einem solchen Fall jedoch überlegen, wie die Abnahme der Implementierung gestaltet werden kann.
Optimal ist einzig die Verteilung von Scrum Master, Produkt Owner und Team auf unterschiedliche Personen.
Quelle Foto: © Andres Rodriguez – Fotolia.com
| Keine Kommentare