Scrum-Rollen zu verschmelzen ist fatal

Agile Softwareentwicklung ist "hip". Wenn man sich umschaut, wird man feststellen, dass mittlerweile die meisten Teams ihren Prozess als agil empfinden. Es scheint ohnehin nur drei Gedankenmodelle zu geben:

• Nicht agil = Wasserfallmodell = aus dem letzten Jahrtausend!
• Scrum = agil = strukturiert = so sollte man es machen!
• XP = Extreme Programming = hyperagil = unstrukturiert!

Ich hätte daran nichts auszusetzen, wenn die Teams, die Scrumeinsetzen, es auch wirklich richtig machen würden.

Scrum für jeden

Die Wahrheit ist: die meisten passen "ihr Scrum" so an, dass es keins mehr ist, sondern nur noch Aspekte davon hat. Als Alibi muss dann die Agilität selbst herhalten. Man müsse ja den Prozess auch den eigenen Bedürfnissen anpassen.

Der meines Erachtens problematischste Aspekt an Scrum ist das Rollen-Dreigestirn:

• Scrum Master
• Product Owner
• Team

Die Scrum Einführung

In den meisten Unternehmen herrschte vor der Einführung von Scrum eine klassische hierarchische Struktur. Ein Team hatte einen Vorgesetzten und der hatte seinen. Während der Einführung von Scrum wird versucht die Scrum-Rollen in der bisherigen Unternehmenslandschaft wiederzufinden.

Wer wird der neue Product Owner? Der CEO als "der" Verantwortliche für alle Produkte? Wohl kaum! Vielleicht der Spartenleiter, der jetzt schon keine Zeit hat? Es wird in der Regel der direkte Vorgesetzte. Immerhin war es bisher auch seine Aufgabe auf die Qualität zu achten und die Kundenwünsche zu vertreten.

Und wer wird Scrum Master? Gleiches Spiel - gleiches Ergebnis: der Vorgesetzte wird es. Immerhin war er ja auch extra auf einer Scrum Schulung und ist durch seine Position am ehesten in der Lage Hindernisse für das Team zu beseitigen. Er hält das Team auf Kurs. Außerdem ist kein Geld, da um jemanden nur für diese Rolle einzustellen. Und außerdem kann man doch mehrere Rollen haben! Es heißt ja nicht umsonst "Rolle" und nicht "Person"!

Und das Team bleibt das Entwicklerteam.

Diese Vereinigung der Rollen im Vorgesetzten scheint auch (nachvollziehbarerweise) die wenigsten Entwickler oder Vorgesetzte zu stören. Es entspricht auch der bisher gelebten Gewohnheit. Es scheint, als habe sich Scrum gut in die Unternehmensstruktur eingegliedert und wird daher auch akzeptiert.

Die Konsequenzen

Eine Verschmelzung der Scrum-Rollen ist fatal!

Rollen werden meistens nur deswegen unterschieden, weil sie einen anderen Fokus, andere Ziele und andere Mittel haben. Ähnlich der Gewaltenteilung der Staatsgewalt (Legislative, Exekutive und Judikative) soll auch die Rollenteilung bei Scrum ein Macht-Gleichgewicht zwischen den Beteiligten herstellen. Man kann also davon ausgehen, dass es Rollenkonflikte gibt, welche durch Scrum Regeln und eine Art "Verhandlung" ins Gleichgewicht gerückt werden.

Dieser Rollenkonflikt sollte vom Product Owner und Scrum-Master aufgelöst werden:

• Der Product Owner will ein gutes Produkt haben und möglichst viele Features umgesetzt sehen. Und das ganze am besten gestern. Er übt Druck auf das Team aus und fordert Leistung ein.
• Das Team bietet zwar Leistung an, hat aber auch Belastungsgrenzen und braucht immer wieder Pausen und Freiraum, um kreativ sein zu können.
• Der Scrum Master sollte ein wenig den Schiedsrichter spielen und für eine geordnete Umsetzung der Scrum Regeln sorgen. Er sorgt dafür, dass der Product Owner das Team nicht übermäßig unter Druck setzt und verbrennt bzw. zerstört. Gleichzeitig sorgt er auch dafür, dass sich das Team in Sprints verpflichtet Leistungen zu bringen. Er stellt den Macht-Gegenpol zum Product Owner dar und beschützt das Team vor inneren und äußeren Problemen.

Fallen nun diese beiden Rollen im Vorgesetzten zusammen, so ist die Gewaltenteilung nicht gegeben. Je nach Charakter und Erfahrung des Vorgesetzten funktioniert dieses System entweder gut oder katastrophal.

Vor allem in Situationen, in denen der Druck auf den Vorgesetzten steigt, zeigen sich gute Führungsqualitäten. Hat er im Team den Rückhalt den er braucht, um hinter dem Team zu stehen oder steht er auf verlorenem Posten und wird den Druck bald ungefiltert weiterleiten?

Mit Scrum hat das dann herzlich wenig zu tun.