Rollenklärung im Team

In der agilen Welt ist das ideale Team divers und egalitär – unterschiedliche Charaktere mit verschiedenen Fähigkeiten, die als Gruppe gleichwertiger und gleichberechtigter Individuen miteinander arbeiten und sich selbst organisieren. Folgen Organisationen dem Scrum Guide, der lediglich drei Verantwortlichkeiten definiert, so agieren Teams ohne interne Strukturen, Rollen oder Spezialisten. Entsprechend gilt es Forderungen nach der Benennung von Zuständigkeiten, die von außen an Teams herangetragen werden, immer wieder abzuwehren.

Für klassisches, auf Kontrolle ausgerichtetes Management sind ungeklärte Rollen und Zuständigkeiten hingegen ein Graus, ein Risiko, das beseitigt werden muss. Für jede erdenkliche Fragestellung wird nicht nur eine Lösung gesucht, sondern auch eine Antwort auf die Frage, wer ähnliche Fragestellungen in der Zukunft bearbeiten wird. “Erst wenn für jedes Thema, jede Frage, jede Entscheidung die Verantwortlichkeiten klar geregelt sind, kann die Organisation effizient laufen”, lautet der Gedanke dahinter. Okay, vielleicht sind Organisationen dann nicht mehr fähig, bei Überraschungen die Richtung zu wechseln, dafür laufen sie wenigstens ohne nennenswerte Reibungsverluste geradeaus.

Beide Ansätze haben nachvollziehbare Hintergründe. Wenn wichtige Themen liegenbleiben oder durch das Raster fallen, ist das eine sehr unangenehme Erfahrung für die, die am Ende dafür verantwortlich gemacht werden. Auf der anderen Seite schaffen klassische funktionale Rollen (z.B. Entwicklung, Test, Design) innerhalb eines agilen Teams mehr Probleme, als sie lösen. Beide Paradigmen begründen ihre Grundsätze jedoch nicht wirklich zufriedenstellend, Diskussionen dazu laufen deshalb erfahrungsgemäß oft dogmatisch ab, anstatt sich darum zu drehen, welche Konsequenzen eine Entscheidung für oder gegen Formalisierung im Einzelnen hat.

Das Bedürfnis, Rollen zu definieren

In meiner Arbeit mit stark selbstorganisierten Teams, wie etwa bei DB Systel oder jetzt bei Chili and Change, habe ich an dieser Stelle eine interessante Beobachtung gemacht:

Selbst wenn es von außen überhaupt keinen Druck gibt, Rollen und Zuständigkeiten einzuführen, entsteht das Bedürfnis dazu innerhalb des Teams trotzdem.

Im krassen Widerspruch zum Scrum Guide steht also die Erfahrung aus der Praxis: Menschen wollen in ihrer Zusammenarbeit Rollen definieren. Das fängt an bei Fragen wie “wer macht eigentlich die Meetings mit dem Kunden”, geht über schleichende Routinen bei der Aufgabenzuweisung (“Überlass das Kundenmeeting dem Klaus, der hat das die letzten Male auch super gemacht!”) bis hin zu harter Formalisierung (“Kundenkontakt läuft immer über Martin, unseren Customer Engagement Manager!”).

Aus diesem Widerspruch zwischen Theorie und Praxis kann man unterschiedliche Schlüsse ziehen. Manche psychologisieren, den Menschen würde einfach die “Reife” fehlen, um sich “schon” vollständig von ihren hierarchisch konditionierten Reflexen zu lösen. Andere trennen nach Hierarchieebene: wenn das Management eine Rolle definieren will, ist das schlecht, weil fremdbestimmt; wenn das Team genau die gleiche Rolle einführen will, ist das ein Beispiel gelungener Selbstorganisation.

Mir ist beides zu flach. Ich arbeite gerne mit Menschen, so wie sie sind, anstatt ihnen grundsätzlich Entwicklungsbedarf zu unterstellen. Und Selbstorganisation ist ein Mittel, nicht ein Selbstzweck – eine vom Team definierte Rolle kann genauso nützlich oder unsinnig sein wie eine, die vom Management beschlossen wird. Stattdessen frage ich nach der systemischen Funktion:

• Warum ist Rollendefinition für Menschen in Organisationen nützlich?
• Welche Faktoren tragen dazu bei, und liegen sie in unserem Einflussbereich?
• Und: entsteht durch Rollendefinition auch für die Organisation ein Nutzen, oder führt lokale Optimierung im Team am Ende zu globalen Problemen in der Organisation?

Wir sollten aber weiter vorne anfangen.

Was ist eine Rolle?

Eine Rolle ist eine Zusammenstellung von Verhaltenserwartungen und Entscheidungsbefugnissen. Als Rolleninhaber darf ich also bestimmte Entscheidungen treffen, die andere nicht einfach so treffen dürfen. Im Gegenzug werden von mir bestimmte Dinge erwartet, die ich kraft meiner Rolle regelmäßig tun soll. Ich kann auch nicht einfach irgendwas entscheiden, denn das wird als “Überschreiten des Kompetenzbereichs” ausgelegt und verworfen. Ein Beispiel für eine Rolle ist der Ausguck auf einem Segelschiff – erwartet wird, dass er/sie auf interessante Ereignisse und Probleme im größeren Umkreis des Schiffs hinweist, und Entscheidungsbefugnisse sind etwa Fragen wie “was melde ich und was nicht?” und “wie mache ich auf ein Ereignis aufmerksam?”, aber nicht “wohin fährt das Schiff?” oder “wie lange werden unsere Frühstückseier gekocht?”.

Zu jeder Entscheidungsbefugnis gehört auch die Kehrseite, nämlich Verantwortung für die getroffenen Entscheidungen. Verbindliche Entscheidungen treffen zu dürfen, bedeutet gleichzeitig, dass die Organisation sämtliche Probleme, die in dem Kontext auftreten, ebenfalls dem Rolleninhaber (dem Inhaber, nicht der Rolle!) zuordnen wird. Wenn das Segelschiff vermeidbar gegen ein Hindernis stößt oder auf eine Sandbank aufläuft, wird sich der Ausguck etwas anhören müssen. Das hat für die Organisation eine kapselnde Wirkung: wenn etwas richtig schiefgeht, wird im Zweifelsfall der Rolleninhaber aus der Rolle oder sogar der Organisation entlassen, und damit kann das Problem für gelöst erklärt werden. Rollen sind also für die Organisation nützlich, um Problemanalysen abkürzen zu können. Der Ausguck hätte das Hindernis rechtzeitig melden müssen, hat er aber nicht, also kann er nicht länger Ausguck sein, Ende der Geschichte.

Aber auch für das Team selbst kann das Definieren von Zuständigkeiten eine augenscheinlich attraktive Lösung sein. Für mich war es eine Überraschung, dass selbstorganisierte Teams, frei von jeglichem Management-Einfluss, einfach selbst all diejenigen Rollen wieder einführen wollten, die ich vorher jahrelang mit Management-Erwartungen begründet und abgelehnt hatte. Auch ohne jeglichen Druck von außen gibt es offenbar Situationen, in denen die Einführung einer Rolle für alle Teammitglieder einen Vorteil bedeutet.

Der Grund dafür ist, dass in einem komplexen Umfeld Rollendefinition gleich mehrere individuelle Lösungsstrategien bedient. Einerseits kann ich, wenn ich es schaffe, eine einflussreiche Rolle zu übernehmen, innerhalb dieser Rolle einigermaßen frei schalten und walten, gewinne also an Gestaltungsmöglichkeiten und Reaktionsfähigkeit hinzu. Andererseits reduziert jede Rolle, die jemand anderes übernimmt, meinen persönlichen Verantwortungsbereich, macht also meinen Arbeitsalltag überschaubarer. Das Wissen, dass jemand anderes sich um ein Thema kümmert, macht es mir möglich, mich besser auf meine verbleibende Arbeit zu konzentrieren. Und in vielen Situationen ist auch wichtig, dass nur einer von uns aktiv an etwas arbeitet, weil es sonst zu Kollisionen kommt. Bspw. haben wir einmal in einem Team versucht, gemeinsam das Team-Postfach zu betreuen, und sehr schnell gemerkt, dass wir besser einen einzigen “Hüter des Postfachs” ernennen, der monatlich wechselt.

Eine Rolle einzuführen, kann also sowohl für den Rolleninhaber als auch für den Rest des Teams gleichzeitig Vorteile bedeuten. Beides sind individuell funktionale und nachvollziehbare Strategien. Leider bedeutet das immer noch nicht, dass diese Rolle dann auch für die Wertschöpfung und damit die Organisation eine gute Idee sein muss.

Nebeneffekte von Rollendefinitionen

Als Erstes sollten wir uns von der naiven Vorstellung lösen, dass das Einführen einer Rolle “zusätzliche Klarheit” in das Team bringt, ohne dabei irgendwelche Nebeneffekte zu haben. In erster Linie konzentrieren neue Rollen nur vorhandene Erwartungen. Unerwünschte Nebenwirkungen sind zum Beispiel, dass

• ein Thema bei Abwesenheit des Rolleninhabers liegenbleibt (“sorry, dafür ist der Kollege zuständig, und der ist diese Woche krank”),
• sich niemand für ein Thema  verantwortlich fühlt (“das macht Klaus, da rede ich ihm nicht rein”),
• das Definieren, Überprüfen und Nachschärfen der Rolle zusätzliche Arbeit macht.

Unterschätzt wird auch, wie viel zusätzliche Arbeit allein dadurch notwendig wird, dass es nun einen “single wringable neck” gibt, also eine einzelne Person, die im Fehlerfall verantwortlich gemacht werden kann. Ob der Fehler jemals auftritt oder sich die Person dann dafür rechtfertigen muss, spielt überhaupt keine Rolle. Es reicht schon die Erwartung des Rolleninhabers, dass es passieren könnte, um zusätzliche Arbeit ins System zu bringen. Schauen wir uns dazu ein Beispiel an:

In einem selbstorganisierten Startup-Team wurde das Thema Arbeitssicherheit bisher mit Optimismus und Eigenverantwortung behandelt. Das Büro ist in gutem Zustand, man hat alles im Blick. Als durch die Corona-Pandemie bedingt alle Teammitglieder ins Homeoffice wechseln, wünscht sich das Team, dass sich ein einzelnes Teammitglied doch bitte um das Thema kümmern sollte “damit es nicht liegenbleibt”.

Eine Kollegin – nennen wir sie Anna – findet das Thema wichtig und bietet sich gerne an. Sie merkt, dass sie sich bei den Vorschriften nicht gut auskennt, und beginnt sich einzulesen; es könnte ja sein, dass die anderen Fragen an sie haben werden, jetzt wo sie Arbeitssicherheits-Verantwortliche ist. Zusätzlich besucht sie eine kostenpflichtige Weiterbildung, um wirklich sattelfest im Thema zu sein. Im Anschluss an die Weiterbildung fährt sie ins Büro, um es vor Ort gegen die neu erlernten Richtlinien zu prüfen. Gehen wir mal optimistisch davon aus, dass es im Büro nur ein paar Kleinigkeiten zu tun gibt. Die Zeit für all diese Dinge nimmt sie sich von ihrer normalen wertschöpfenden Arbeit.

Das Büro ist nach Annas Einschätzung zwar sicherheitstechnisch in einem guten Zustand, aber dort arbeitet ja nun niemand mehr. Sie beginnt also damit, den Stand bei den Teamkollegen, die im Homeoffice tätig sind, systematisch zu erheben, und setzt dafür Einzelmeetings an. Bei einigen stellt sie fest, dass zusätzliche Anschaffungen notwendig sind, um einen ergonomischen Arbeitsplatz zu Hause möglich zu machen. Andere arbeiten zu Annas Erschrecken einfach auf der Couch, mit dem Laptop auf dem Schoß! Stets bekommt sie zu hören, dass es in engen Stadtwohnungen keinen Platz für einen Schreibtisch gibt. Weil die sich andeutenden Kosten langsam erheblich werden, wird ein Teammeeting zur Besprechung der Arbeitsplatzsituation einberufen. Dort stellt Anna klar, dass sie zwar die Richtlinien kennt, aber sich eine rechtlich solide Bewertung nicht zutraut. Es wird beschlossen, einen Juristen hinzuzuziehen…

Mir geht es nicht darum, Annas Handeln oder die Notwendigkeit nach einem ordentlichen Arbeitsplatz im Homeoffice infrage zu stellen. Es wird aber hoffentlich klar, dass für das Team als Folge der neuen Rollendefinition jede Menge neue Arbeit entsteht. Gleichzeitig baut Anna zusehends einen Wissensvorsprung gegenüber ihren Kollegen auf, der es ihr in Zukunft erschweren wird, bei Überlast Aufgaben an ihre Kollegen abzugeben. Nichts anderes passiert, wenn Softwareentwicklungsteams streng nach Frontend- und Backend-Entwicklern unterscheiden. Oder wenn es dedizierte Designer und Tester im Team gibt. Oder wenn bestimmte Aufgaben einfach immer und immer wieder von derselben Person erledigt werden. Das Wissen, allein für ein Thema verantwortlich zu sein, erzeugt zusätzliche Arbeit und früher oder später einen Flaschenhals. Schlecht, wenn dieser Flaschenhals genau im Wertschöpfungsprozess liegt.

Fazit

Bedeutet dies nun, dass die Definition von Rollen eine schlechte Sache ist? Nein, sicher nicht. Meiner Meinung nach muss man menschliche Bedürfnisse nach Fokus und Erwartungsklärung sehr ernst nehmen. Wir sollten uns aber von der naiven Vorstellung lösen, dass “mehr Klärung” grundsätzlich die richtige Richtung vorgibt. Im Rollenklärungsworkshop selbst fühlt es sich toll an, die Zuständigkeiten bis ins Detail unmissverständlich festgelegt zu haben, wenn dann aber in der Folgewoche eine neue Aufgabe plötzlich quer zu unserem schönen neuen Rollenmodell liegt, ist der Ärger groß.

Es geht darum, die richtige Balance zwischen Formalisierung und spontaner Selbstorganisation zu finden und darüber immer wieder bewusste Entscheidungen zu treffen. Dinge undefiniert und unentschieden zu lassen, ist oft eine gute Sache! Insbesondere das Hinterfragen und Streichen bestehender Rollen wird meines Erachtens viel zu selten in Erwägung gezogen. Es gibt eine ganze Reihe von Indizien, die auf Probleme mit einem Rollenmodell im Team hinweisen:

• Ein Klassiker ist das “Fußballtrainer-Syndrom”, bei dem ein- und dieselbe Rolle alle paar Monate neu besetzt wird, nachdem die vorherigen Rolleninhaber in Ungnade gefallen sind.
• Für bestimmte Themen möchte kein Teammitglied Verantwortung übernehmen, da es bereits feste Rolleninhaber gibt (z.B. Tester im Team, also testet sonst niemand mehr).
• Die Arbeitslast tritt bei einzelnen Teammitgliedern in Wellen auf, d.h. Phasen der Langeweile wechseln sich mit Phasen der Überlast ab.
• Und bedingt durch Krankheit oder Urlaub droht ein kompletter Stillstand bei Themen, die von einzelnen Mitarbeitern verantwortet werden.

Wenn Sie solche Dinge bei sich im Team beobachten, ist es höchste Zeit, die Rollen und Verantwortlichkeiten gemeinsam unter die Lupe zu nehmen.

Ich beschäftige mich seit über 10 Jahren mit agilen Arbeitsweisen und glaube beim Thema Rollenklärung sollte das Team seine eigenen Strukturen, und vor allem die Konsequenzen seiner Entscheidungen, aufmerksam beobachten. Auch in meinen Teams gibt es Rollen. Vor der Klärung der Erwartungen und Entscheidungsbefugnisse stehen bei uns immer zwei Fragen:

1. Welche Vorteile und Nachteile bringt eine neue Rolle mit sich?
2. Und sind die Vorteile die Nachteile wert?

Wir achten darauf, dass die Rollen grundsätzlich allen zugänglich sind und bleiben – so kann Klaus für Projekt A verantwortlich sein und Anna arbeitet ihm zu, und danach ist Anna in Projekt B federführend und baut auf die Unterstützung von Klaus. Wo sinnvoll, rotieren wir Rollen monatlich, sodass sie sich nicht über längere Zeiträume einschleifen können. Dabei ist es normal, dass sich über die Zeit unterschiedliche Wissensstände bei einem Thema aufbauen, dies sollte Sie aber nicht dazu verleiten, ein Thema immer wieder der Person zu geben, die sich damit bereits am besten auskennt. Kurzfristig mag dies “effizienter” wirken, langfristig führt dies jedoch zu Spezialisierungen, Unsicherheiten und steifen Arbeitsroutinen.

Und last but not least ist es aus meiner Sicht sehr sinnvoll, an wichtigen Themen immer mindestens zu zweit zu arbeiten, denn dadurch lässt sich das Ausfallrisiko deutlich reduzieren, das Wissen breiter streuen und die Ergebnisse durch das Vier-Augen-Prinzip verbessern. Hier bewirkt die einfache Frage “Wollen wir uns zusammen darum kümmern?” häufig kleine Wunder.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Weitere Artikel von Kai-Marian Pukall sind u. a. bei Inspect&Adapt und auf LinkedIn zu finden.

Dies ist ein Best of Blog 2022 Beitrag. Hier können sie die besten Beiträge aus 2022 herunterladen.

Kai-Marian Pukall hat im t2informatik Blog weitere Beiträge veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.