Rollentrennung und Fähigkeiten

3 Kommentare

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

3KreisePOSMTeam

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.

Marc Clemens

Marc Clemens ist Senior Agile Consultant und Coach in der Agilen Software Factory (ASF) und seit 1998 Mitarbeiter der MBG bzw. – nach Fusion der beiden Unternehmen – der codecentric AG. In kleineren und größerern Projekten, auch mit Teams, die sich über entfernte Standorte verteilen, agiert er in der Rolle des Product Owners. Weiterhin gibt er seine gewonnen Erfahrungen und Wissen beim Agilen Coaching an Kunden weiter.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentare

  • John Behrens

    Wenn ich das wort „Rollentrennung“ schon Lese deutet das immer so wein wenig auf Trennungskultur hin. Zwar gibt es im agilen kontext eine Verantwortungsverteilung allerdings führt eine Trennung oft dazu Mauern aufzubauen wo sie schädlich sind,
    gerade im punkt Team „Build the thing right“ und Product Owner „Build the right thing“ kann hier eine zu starke rollentrennung dazu führen das, das Team trotz optimaler leistung ein absolut nutzloses „Thing“ baut.
    Um wirklich effektiv zu sein halt ich statt Trennung eher für Notwendig das die „Rollen“ sich gegenseitig „befruchten“

  • Marc Clemens

    13. Januar 2015 von Marc Clemens

    Hallo John,

    danke für Deinen Kommentar. Ich glaube das die „Trennungskultur“ aus den Einführungsphasen von Scrum kommt. Ähnlich wie mir mein Fussballtrainer in der f-Jungend als Verteidiger verboten hat die Mittellinien zu überqueren um das Rollenkonzept von Angriff, Mittelfeld und Verteidigung einzuführen, legt man ein der Einführung einen viel stärkeren Fokus in der Abgrenzung der Rollen als zu einen späteren Zeitpunkt sinnvoll ist.

  • Fin Stomberg

    19. Juni 2015 von Fin Stomberg

    Hi Marc,
    aus 6 Jahren Erfahrung in 4 verschieden Projekten mit 9 Teams weiß ich, dass die Trennung der Rollen im Kern sehr individuell sein kann, was die Aufgaben, Befugnisse und verantworteten Entscheidungen im Detail betrifft. Ich habe aber festgestellt – und stelle es grad wieder in Projekt 5 fest, dass es essentiell ist, in jeder Projektphase eine klare, praktische und verständliche Trennung der Rollen zu haben. In der Regel wird sich diese Definiton im Projektverlauf ändern. Inspect & adapt. Den Wert, dass jedes Teammitglied zu jeder Zeit weiß, was die Aufgaben, Befugnisse und verantworteten Entscheidungen der jeweiligen Rolle sind ist riesig!
    Mich würde interessieren, wie du ergänzend zum Beispiel des Product Owners, jeweils am Beispiel „Scrum Master“ und „Entwicklungsteam“ die Aufgaben, Befugnisse und verantworteten Entscheidungen als Ideal definieren würdest.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.