Wer hat in Scrum die Prozessverantwortung?

Bild: Pexels / Christina Morillo - Lizenz

Es ist eine häufige Diskussion in der Einführungsphase von Scrum: wenn wir beginnen so zu arbeiten, bei wem liegt dann eigentlich die Prozessverantwortung? Bei der Produktverantwortung ist es klar, die liegt beim Product Owner. Auch die Lieferverantwortung lässt sich schnell klären, für die ist das Umsetzungs- (bzw. Development-)Team da. Aber die Prozessverantwortung? Die könnte doch beim Scrum Master liegen, oder? Das scheint auf den ersten Blick naheliegend, ist es aber nicht unbedingt. Bei näherer Betrachtung zeigt sich nämlich, dass Prozessverantwortung ein erstaunlich vielschichtiger Begriff ist.

Beginnen wir mit dem Scrum Master. Wegen des Scrum Guide, der als offizielles Regelwerk scheinbar eine klare Richtung vorgibt, gibt es häufig die Auffassung, dass ganz klar er es ist der die Prozessverantwortung haben muss. Sowohl bei den Aufgaben der Rolle als auch an anderen Stellen könnte man es herauszulesen, dass er bei diesem Thema den Hut auf hat. Also, ist es so? Nun ja, Jein. In die umgebende Organisation wirkt der Scrum Master nur um zu verhindern, dass das Umsetzungsteam gehemmt wird. Und das was das Scrum-Regelwerk für seine Arbeit im Team vorgibt ist lediglich die Verantwortung für einen Prozess-Teilbereich, den des Scrum-Prozesses nämlich. Der ist zwar von zentraler Bedeutung, er gibt aber nur den groben Rahmen für den eigentlichen Arbeitsprozess vor.

Dieser eigentliche Arbeitsprozess ist losgelöst vom Scrum-Prozess (und der Scrum Master-Rolle) zu sehen. Wer macht was wann mit welchem Ziel und mit welchen Werkzeugen? Solange dabei am Sprintende ein funktionierendes Produktinkrement entsteht sollte der Scrum Master da für alles offen sein, genau gesagt muss er es sogar. Der Scrum Guide ist hier sehr eindeutig: Development Teams [...] are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. Da bleibt kein Platz für Missverständnisse, verantwortlich ist das Umsetzungsteam und sonst niemand.

Über die Scrum- und Arbeitsprozesse hinaus gibt es aber noch einen weiteren Prozessbereich, der üblicherweise mit Namen wie Compliance, Governance oder Betriebsorganisation überschrieben wird. Auf ihn bezogen ist die Natur der Prozessverantwortung wieder eine andere als in den beiden zuvor genannten Fällen. Wenn hier davon gesprochen wird, dass jemand für den Prozess verantwortlich ist, verbirgt sich dahinter in der Regel der feine aber wichtige Unterschied, dass es die Einhaltung der Prozesse ist, für die jemand die Verantwortung trägt. Gestaltet werden sie in der Regel von irgendeiner zentralen Abteilung.

An dieser Stelle dürfen wir uns nichts vormachen - in den meisten Unternehmen ist nur dieser Bereich gemeint wenn von Prozessverantwortung gesprochen wird. Das ist nicht per se schlecht, die meisten Vorschriften beruhen im Grundsatz auf irgendeinem Sinn oder gehen sogar auf Gesetze zurück, dass sie durch Willkür oder Unsinn entstehen ist ein klischeehafter aber seltener Fall. Auch für die Existenz der zentralen Abteilung kann es gute Gründe geben, etwa eine nötige juristische Qualifikation. Es gibt aber sehr oft eine unnötig bürokratische Umsetzung, und auf die gehen meistens die wahrnehmbaren Probleme zurück. Und hier kommen wir zurück zu Scrum, zuerst wieder zum Scrum Master.

Wenn die Prozessverantwortung im Sinne des Sicherstellens der Prozesseinhaltung dem Scrum Master übergeben wird, dann mag das auf den ersten Blick naheliegend erscheinen, es stürzt ihn aber in einen tiefen Intra-Rollen-Konflikt. Auf der einen Seite erwartet Scrum von ihm, dass er dem Umsetzungsteam dabei hilft stetig effektiver zu werden, auf der anderen Seite soll er auf die Einhaltung ineffektiver Arbeitsvorgaben dringen? Und wenn der von aussen vorgegebene, unnötig komplizierte Prozess ein Hindernis für die Arbeitsfähigkeit des Teams ist, soll er zeitgleich versuchen ihn abzuschaffen und für seine Einhaltung sorgen? Das kann nicht funktionieren.

Genau umgekehrt ist es mit dem Umsetzungsteam, bei dem es auf den ersten Blick sinnvoll erscheinen mag es vom Prozessmanagement zu entlasten, damit es "richtige Arbeit" machen kann. Weit gefehlt. Damit würde es nicht nur aufhören crossfunktional zu sein, es wäre auch nicht mehr in der Lage Prognosen oder Commitments für die Sprints abzugeben, da es diese aufgrund der Abhängigkeit zu den externen Prozessverantwortlichen nicht mehr selbst vervollständigen und beenden könnte. Eine der Grundvoraussetzungen von Scrum, die Lieferfähigkeit des Umsetzungsteams, wäre ausgehebelt.

Aus alldem ergibt sich in Scrum folgende Verteilung in der Prozessverantwortlichkeit: der Scrum Master ist verantwortlich für den Scrum-Prozess, das Umsetzungsteam für den Arbeitsprozess. Alle sonstigen Prozessvorgaben (sofern deren Einhaltung eine Voraussetzung für die Lieferfähigkeit des Umsetzungsteams ist) fallen ebenfalls in dessen Verantwortung, wobei es die Aufgabe des Scrum Masters ist so auf das Team und die umgebende Organisation einzuwirken, dass an dieser Stelle Bürokratie und Ineffizienz nicht entstehen können.

Glücklich schätzen kann sich dagegen der Product Owner, an dem die Prozesse weitgehend vorbeigehen. Die einzige grosse Ausnahme davon liegt vor wenn es einen vorgelagerten Anforderungsprozess gibt, was aber nochmal ein Thema für sich ist.