Rollentrennung und Fähigkeiten

Auslöser für den Blog-Artikel ist eine Diskussion die ich im Rahmen von Lean DUS ,  einem lokalen Community Event in Düsseldorf, über folgendes Thema geführt habe: Was sollte ein Scrum Master alles können und was sollte er besser nicht können?

Dabei drehte sich die Diskussion darum, in wie fern es notwendig, hilfreich oder hinderlich ist, dass ein Scrum Master die Fähigkeiten besitzt, die für die anderen Rollen notwendig sind. Dabei habe ich eine unterschiedliche Auffassung darüber wahrgenommen, wie stark die Trennung der Rollen in der Praxis gelebt werden sollte. Inwieweit sollte sich der Scrum Master z. B. in die Arbeitsweise des Teams (oder des Product Owners) einmischen? Sollte er technische Qualität beurteilen können und seine Beurteilung dem Team spiegeln? In Rahmen dieses Artikels werd ich versuchen, die Frage „Wie stark sollte die Trennung der Rollen in der Praxis gelebt werden?“ zu betrachten.

Aus meiner Erfahrung heraus ist solch eine Frage nicht einfach und allgemeingültig zu beantworten, sondern sollte je nach Rollenmodell und Situation unterschiedlich gehandhabt werden. Deshalb werde ich hier auf das Rollenmodell von Scrum in Entwicklungsprojekten, bzw. Produktentwicklungen eingehen. Auf vergleichbare Vorgehensmodelle lassen sich die Überlegungen übertragen.

Zunächst ist es notwendig, den Begriff “Rolle” etwas genauer zu beleuchten. Im hier betrachteten Zusammenhang geht es nicht um den Begriff “soziale Rolle” aus der Soziologie, sondern um „Rollen in einem Arbeitsprozess“. Eine leicht modifizierte Definition von www.projektmagazin.de  lautet:

“Rolle bezeichnet eine temporäre Funktion einer Person oder Gruppe innerhalb der Arbeitsorganisation. Eine Rolle wird beschrieben durch Aufgaben, Befugnisse und Verantwortungen. Zur vollständigen Definition einer Rolle gehört die Angabe, ob sie teilbar und kombinierbar ist.”

Zusammengefasst definiert sich eine Rolle danach aus

• den Aufgaben, die eine Rolle übernimmt,
• den Befugnissen, die eine Rolle hat und
• den Entscheidungen, die eine Rolle verantwortet.

Dabei unterstützen Rollendefinitionen die Arbeitsteilung innerhalb der Arbeitsorganisation.

Beispiel: Product Owner in Scrum

Die Rolle ist nicht teilbar und immer kombiniert mit der Rolle “Scrum Teammitglied”.

Aufgaben:

• Verwaltung des Product Backlogs
• Stakeholdermanagement
• Zeitlich und inhaltliche Planung der Produktentwicklung
• Fachliches Feedback einholen und berücksichtigen

Befugnisse:

• Inhalt des Product Backlog festlegen (inkl. Reihenfolge)
• Mit den Stakeholdern reden
• Mit dem (Entwicklungs-)Team reden
• Anteil der Zeit des Teams für Product Backlog Refinement nutzen
• Aktuellen Sprint abbrechen

Verantwortete Entscheidungen:

• Welche Anforderungen sind umgesetzt und welche nicht?
• Wie ist die Umsetzung einer Anforderung im Detail ausgestaltet?
• Wie wird mit den Stakeholdern kommuniziert? Und welche Informationen werden kommuniziert?
• Welche Anforderungen werden als nächstes umgesetzt?

Aber warum helfen solche Rollendefinitionen bei der Arbeitsteilung?

Offensichtlich können sie zur Aufgabenverteilung innerhalb der Arbeitsorganisation genutzt werden. Da die Ausformulierung einer User Story durch einen Product Owner erfolgt und die technische Beurteilung durch Teammitglieder, kümmert sich kein Teammitglied, sondern der Product Owner um die neue fachliche Ideen der Stakeholder. Hat der Product Owner die Ideen ausformuliert, wird sich nicht der ScrumMaster (oder der Product Owner) um die technische Beurteilung (Machbarkeit, Aufwand) kümmern, sondern Mitglieder des Entwicklungsteams.

Weiterhin gibt es Erwartungen an eine Rolle, z. B. bezüglich der Auskunftsfähigkeit von Rolleninhabern. So erwarte ich z. B., dass mir ein Product Owner Aussagen über geplanten Umfang und Fertigstellungszeitpunkt geben kann, das Team die technische Architektur und Lösungsansätze erklären kann und der ScrumMaster die aktuellen Schwierigkeiten, die momentan besonders stören, benennen kann.

Rollen dienen auch dazu, festzulegen, wer den Kopf hinhält, wenn etwas nicht so läuft wie es sein sollte. Das klingt erstmal etwas böse. Aber es geht eigentlich darum, an wen und in welcher Intensität Feedback adressiert wird. So sollten Schwierigkeiten von Benutzern mit dem Produkt möglichst schnell und klar an den Product Owner berichtet werden, die Ergebnisse von Code-Analysen oder technische Probleme an das Entwicklerteam und Dinge, die Entwicklungsarbeit blockieren an den ScrumMaster.

Das zeigt, dass die Beschreibung einer Rolle als eine Schnittstellendefinition zwischen den unterschiedlichen Teilen einer Arbeitsorganisation fungiert. Dabei gilt, je enger diese Teile miteinander zusammen arbeiten, um so unschärfer kann diese Schnittstelle ausformuliert sein.

Wenn sich alle untereinander kennen und in dauernder Kommunikation stehen, dann sind formale und klare Rollendefinitionen nicht notwendig. Das ist der Grund warum Scrum innerhalb des Entwicklungsteams keine weiteren formalen Rollen definiert.Das bedeutet aber nicht, dass es keine impliziten Rollen gibt. Wenn es sich wirklich um ein „cross functional“ Team mit teilweise sehr unterschiedlichen Expertisen (Tester, Entwickler, Redakteure, Designer etc.) handelt, werden sich innerhalb des Teams auch Rollen herauskristallisieren. Welche solcher impliziten Rollen es gibt, wie klar sie abgegrenzt von einander sind und wie dauerhaft sie existieren, ist aber der Selbstorganisation innerhalb des Teams überlassen.

Wird aber eine Schnittstelle außerhalb einer so intensiv zusammenarbeitenden Gruppe benötigt, werden formalere Rollen benötigt. Dies tritt z. B. in vielen Scrum-Of-Scrum Implementierungen auf. Oft haben Teams dann für übergreifende Themen (Architektur, Configuration Management, Test) explizite Ansprechpartner aus ihrem Team benannt, die sich um dieses Thema kümmern.

Zusammengefasst ergeben sich hieraus zwei Punkte:

• Es gibt explizite (formale) und implizite Rollen.
• Rollen verhalten sich gegeneinander anders je nachdem ob sie “intern” oder “extern” (lose) zusammenarbeiten.

Wie stark sollte die Trennung der Rollen in der Praxis gelebt werden?

Es ist klar, das implizite Rollen nicht klar getrennt sind. Diese Rollen verschieben/verändern sich je nach Situation sehr schnell. Das kann sowohl aufgrund von veränderten Rahmenbedingungen passieren, als auch dadurch, dass unterschiedliche Rolleninhaber die impliziten Rollen anders interpretieren.

Bei den formalen Rollen, die „intern“ zusammenarbeiten ist es ebenfalls nicht notwendig, eine strikte Trennung vorzunehmen. Zwar sind diese Rollen in der Theorie klar und deutlich voneinander abgegrenzt und mit bewusst ins Rollenmodell eingeplanten Inter-Rollenkonflikten ausgestattet, aber in der praktischen Arbeit ist es durch die enge Zusammenarbeit möglich (und auch gewünscht), dass sich die Rolleninhaber untereinander unterstützen und aushelfen und damit die Rollengrenzen überschreiten. Obwohl eine Person eigentlich Teammitglied ist, agiert sie zeitweise als Product Owner oder als Scrum Master.

Nur in der externen Sicht auf die formalen Rollen kann eine eher striktere Trennung sinnvoll sein. Gerade bezüglich der Auskunftsfähigkeit und dem Adressieren von Feedback ist es effektiver, wenn es externen Beteiligten klar ist, welche Rolle sie ansprechen sollten.

Was bedeutet das jetzt für das Rollenmodell in Scrum?

Product Owner, Scrum Master und Team arbeiten sehr eng und intensiv zusammen, daher gilt meine Meinung nach untereinander die “interne” Sicht. Hier ist eine strenge Trennung der Rollen nicht zwingend notwendig (und auch meist nicht hilfreich). So kann es vorkommen, dass Teammitglieder am Product Backlog arbeiten oder Impediments aus dem Weg räumen.

Gerade wenn man die folgende einfache (und daher geniale) Verantwortungsbeschreibung der drei Rollen betrachtet:

• Product Owner – Build the right thing
• Team – Build the thing right
• Scrum Master – Build it fast

beeinflussen die wenigsten Entscheidungen, die im Rahmen der täglichen Arbeit getroffen werden, nur einen dieser drei Verantwortungsbereiche. Oft sind sogar alle drei Bereiche betroffen. Daher ist ein kooperativer Umgang mit der Verantwortung notwendig und ein “Einmischen” in den Verantwortungsbereich der anderen Rollen nicht eine Ausnahme, sondern eher die Regel. So hat z. B. eine technische Architekturentscheidung natürlich Auswirkungen auf die Geschwindigkeit (sowohl auf die aktuelle, da ja stattdessen echte „Features“ nicht gebaut werden, als auch (hoffentlich) auf die mittel- bis langfristige). Gleichzeitig schränkt sie die (faktisch) möglichen Anforderungen für den Product Owner ein.

Im Umgang mit den “externen” Rollen (zusammengefasst in den Stakeholdern) aber ist eine klare und deutliche Trennung der Rollen sinnvoll. So wenden sich die Stakeholder mit ihren Fragen und Wünschen an die richtige Rolle und ermöglichen damit den einzelnen Rolleninhabern, sich auf ihre Arbeit zu fokussieren.

Dabei möchte ich noch darauf hinweisen, dass in Umgebungen in denen ein Rollenmodell gerade erst eingeführt wird, und die Menschen noch unerfahren mit den Rollen sind, es oft hilfreich ist, die Rollen eine Zeit lang auch intern strikt zu trennen.

Was hat das für Auswirkungen auf die notwendigen Fähigkeiten für eine Rolle?

Innerhalb des Scrum Teams sind die Rollengrenzen nicht sonderlich streng getrennt. Deshalb sollten die Rolleninhaber in der Lage sein, auch in den anderen Rollen zu agieren. Dabei gelten die gleichen Überlegungen wie innerhalb jedes cross-funktionalen Teams. Mitglieder, die außerhalb ihrer Spezialbereiche agieren, müssen nicht perfekt sein, aber in den meisten Fällen Tätigkeiten gut genug ausführen können. Dabei gibt es einen gewisser Anteil an Aufgaben, die den Spezialisten für einen Bereich vorbehalten sind.