Was macht ein Teamleiter in Scrum? Was wird aus einem Projektleiter? Wie verhalten sich diese Rollen zu den Rollen in Scrum? Früher oder später tauchen in jeder größer angelegten Scrum-Implementierung diese Fragen auf. In den meisten Fällen wird die Rollenduplizität eine ganze Weile erhalten: Der Teamleiter ist dann beispielsweise Product Owner. Und der Projektleiter macht (mehr oder weniger nebenbei) den ScrumMaster. Und umgekehrt. Oder es gibt eine Rollenparallelität: ScrumMaster und Product Owner führen und entwickeln nach Scrum, während Projektleiter und Teamleiter klassisches Projektmanagement machen (oftmals sogar für das gleiche Projekt). Dass das auf Dauer nicht optimal ist, sollte keine Überraschung sein. Umso dringender stellt sich die Frage nach einer besseren Rollenverteilung.

Scrum ist keine Rollenevolution

Die Antwort dazu muss zwangsläufig ernüchternd ausfallen. Scrum wurde nicht erfunden, um das klassischen Projektmanagement weiter zu entwickeln. Scrum versucht daher erst gar nicht, eine Kontinuität oder eine Evolution herzustellen. Von Anfang an ist Scrum als Alternative angetreten, die nicht ein UND oder ein ZUDEM, sondern ein ODER im Angebot hat. Folglich gibt es in Scrum keine natürlichen Zuordnungsmöglichkeiten: Wer behauptet, dass ein Projektleiter “am ehesten” Product Owner wird, der unterschätzt die Radikalität der Scrum-Rollen.

Manche pendeln dann direkt ins andere Extrem und behaupten, für die klassischen Rollen gäbe es in Scrum gar keine Verwendung mehr. Wer so denkt, der ist noch nicht in der Wirklichkeit angekommen: In jedem Projekt geht es doch darum, Scrum unter den jeweils aktuellen Bedingungen zu implementieren. Und diese Bedingungen sind nur im Lehrbuch die einer grünen Wiese.

EIn Beispiel

Ich habe vor kurzem mit einem Projektleiter zusammengearbeitet, der Scrum für sein Projekt einführte. Nach einigen Sprints übernahm er die Rolle des ScrumMasters. Der Product Owner kam wiederum aus dem Fachbereich. Beide Scrum-Rollen haben nie ganz richtig gesessen: Der Product Owner hatte zu wenig Produktkenntnis und konnte daher mit dem Team nicht auf der Ebene eines zweiwöchigen Sprints planen. Er hat sich mit der Zeit in die Rolle des Kunden zurückgezogen – und fühlt sich nun dort besser aufgehoben. Der ScrumMaster war anfangs sehr ungeduldig und versuchte in seiner Projektleiterrolle zunächst, das Team mit Vorschriften und Arbeitszuweisungen zu führen.

Wir haben solche Momente kritisch reflektiert. Über die Sprints gelang es dem ScrumMaster, in die Rolle des Teamsponsors zu wechseln, der nicht nur das Team beschützt (das tat er schon immer), sondern auch Freiräume ermöglicht und Entscheidungen respektiert. Als klar wurde, dass der Product Owner seine Rolle nicht ausüben konnte, spielte der ScrumMaster mit dem Gedanken, dorthin zu wechseln. Wir empfahlen ihm, ScrumMaster zu bleiben. Er hatte genügend Produktkenntnisse und wäre vermutlich ein guter Product Owner geworden. Aber sein Interesse um das Wohl und Gedeihen des Teams war bei ihm so stark ausgeprägt, dass er letztendlich selber entschied, ScrumMaster zu bleiben.

Wichtig: Perspektiven

Das oben genannte Fallbeispiel soll eines zeigen: Ob jemand für eine Scrum-Rolle geeignet ist, hängt einerseits davon ab, wie klassische Rollen gelebt werden. Ein Fachbereich mit wenig Produktkenntnis wird es schwer haben, in die Rolle des Product Owners zu kommen (was nicht heißen muss, dass man ihn nicht dorthin entwickeln kann). Und ein Projektleiter mit viel besserer Produktkenntnis ist nicht unbedingt der bessere Product Owner – entscheidend sind dann nämlich auch die Persönlichkeit und die sonstigen Fähigkeiten der einzelnen Person.

Zu Beginn spricht auch in der Tat nichts dagegen, Rollenfragen – wie hier beschrieben – pragmatisch zu lösen.  Entscheidet sich das Unternehmen jedoch, Scrum auszurollen, dann brauchen wir bessere Antworten auf die Rollenfrage. Denn die Mitarbeiter werden sich in jedem Fall die Frage stellen, wie es mit ihnen weitergeht und manche werden sich in Scrum nicht wiederfinden. Aber auch ein ScrumMaster braucht eine Perspektive: Was bedeutet meine Rolle im Unternehmen, welche Entwicklungs- und Aufstiegsmöglichkeiten habe ich? Auch formelle Strukturen wie Rollenbeschreibungen, Einstufungen und Karrierepfade sind wichtig für die Mitarbeiter, bevor sie sich langfristig für eine solche Rolle entscheiden.

Sind die Perspektiven erstmal da, kann man mit den Mitarbeitern gemeinsam herausfinden, wo sie sich am ehesten sehen und ihnen auch klar machen, wo die Organisation sie am ehesten sieht. Scrum hat enormes Begeisterungspotenzial, weil es für viele Unternehmen einen frischen, unverkrampften und oftmals subversiven Neuanfang bedeutet. Gerade in größeren Unternehmen kann Karriere jedoch nur über formale Pfade gemacht werden. Damit die Begeisterung für Scrum anhält und auch über die Pioniere hinaus wirken kann, braucht es die Anerkennung und Ausgestaltung der Scrum-Rollen im Unternehmen.

Danke an Kristina Klessmann, die mich beim Verfassen dieses Artikels unterstützt hat!

Mit der „Rechtfertigung von politischer Autorität“ hat sich Bernd Krehoff in seiner Dissertation an der Universität Oxford auseinander gesetzt. Und das, obwohl er noch nicht wusste, dass er mit diesem Thema der praktischen Philosophie auch die alltäglichen Fragen der Führung in Scrum berühren würde.
  • http://www.facebook.com/hp.korn Hp Korn

    Danke für diese die Unternehmensrealität und eine evolutionär-”systemische” Entwicklung anerkennende Sichtweise:
    “Entscheidet sich das Unternehmen jedoch, Scrum auszurollen, dann brauchen wir bessere Antworten auf die Rollenfrage. Denn die Mitarbeiter werden sich in jedem Fall die Frage stellen, wie es mit ihnen weitergeht und manche werden sich in Scrum nicht wiederfinden. …. Auch formelle Strukturen wie Rollenbeschreibungen, Einstufungen und Karrierepfade sind wichtig für die Mitarbeiter, bevor sie sich langfristig für eine solche Rolle entscheiden.”
    Genau das Gegenteil habe ich leider vor eineinhalb Jahren in einem recht grossen Unternehmen im Rahmen einer recht visionären “big bang”-Einführung von Scrum erlebt … mit in der Folge sehr vielen Unschönheiten u.a. auch bei den ehemaligen “entmachteten” Führungskräften….

  • Stavros Kourtidis

    Hi Bernd,

    Apropos Rollen…

    kann man ein Verhältnis zwischen den Rollen vom TMS und den
    von Scrum herstellen? Das zum Beispiel der ScrumMaster ein „Unterstüzender
    Stablisator“ sein sollte, der Product Owner eher zum „Zielstrebigen Organisator“
    und im Entwicklungsteam die weitren Rollen verteilt sind. Oder ist diese Art
    ein Team zusammen zu stellen, für Scrum nicht relevant?

    lg

    Stavros

    • Bernd Krehoff

      Hallo Stavros,

      danke für die Frage! Ich kenne mich mit dem Team Management System nicht gut aus. Auf den ersten Blick aber lautet meine Antwort “nein”. Zumindest dann nicht, wenn man ein 1:1 Verhältnis herzustellen versucht. So mögen die Eigenschaften des Unterstützenden Stabilisators sehr wohl für ScrumMaster wichtig sein, aber sie beschreiben ihn keinesfalls erschöpfend (zumindest dann nicht, wenn man den ScrumMaster als einen für die Produktivität des Teams verantwortliche Führungsrolle sieht).

      Hinzu kommt die Schwierigkeit, Rollen mit persönlichen Eigenschaften festzuschreiben. Es gibt nicht den einen “guten” ScrumMaster, sondern sehr viele, und zum Teil sehr unterschiedliche. Ihr Erfolg hängt nicht nur (vielleicht nicht einmal primär) von ihren Charaktereigenschaften und persönlichen Stärken ab, sondern vom System, in dem sie sich bewegen. Ein ScrumMaster, der hier gute Arbeit leistet, mag in einer anderen Umgebung gnadenlos scheitern.

      • Stavros Kourtidis

        Hallo Bernd,

        danke für die Antwort.

        Nun ja, wir hatten das TMS im Projektleiter Seminar bei der IHK und da wurde angesprochen dass es sich als Wichtig erwiesen hat, die 8 Rollen im TMS Rad so gut wie Möglich zu besetzten. Denke es ist auch in Scrum wichtig, im Team diese Eigenschaften verteilt zu haben. Worauf ich hinaus war ist, dass ich nicht weiß, ob die 8 Rollen im Entwicklungsteam vorhanden sein sollen, oder ob die organisatorischen Angelegenheiten nicht ins Team gehören.

        Vielleicht ist es ja besser, man besetzt die TMS Rollen, sowie in den Scrmmuster/Productowner Rollen, als auch im Entwicklungsteam.
        Ich denke nämlich schon dass auch in Scrum, ein perfekt besetztes Team und Führung mehr als wichtig ist.

        Es ist vielleicht die Zeit Wert, die man sich nehmen soll, um solche Fragen zu beantworten.

        Wie sieht ein perfektes Team aus? Hier sollte man experimentieren und auch im
        agilen Management, das Wissen und den Stand weiterentwickeln.

        Vergessen wir nicht, es öffnen sich immer neue Märkte(z.B. Onlinemarketing – was ich ja mache ;-) ) und wie in der Wissenschaft, so auch in Management Techniken, werden alte Sachen immer weiter hinterfragt und neue, innovative Ideen, zeigen den Weg in die Zukunft.

        Ich mache mir da schon Gedanken!

        lg

        Stavros