Podcast: Was aus Product Ownern und ScrumMastern wurde

Ursprünglich als "Konkurrenz" zu Scrum positioniert, hat Kanban einige der Konzepte mitgenommen, darunter den ScrumMaster und den Product Owner. Sie sind aber nicht nur in ihren ursprünglichen Formen da, sondern in viel verallgemeinerter Form: Service Delivery Manager und Service Request Manager. Was die so machen, hörst du in der zehnten Folge des Podcasts!

Hast du auch eine Frage? Dann melde dich bei mir!

Den Scrum-Guide findest du unter: https://www.scrumguides.org

IDie Kanban-Methode wurde anfänglich in der Nähe zur agilen Softwareentwicklung platziert. Das wurde unter anderem mit einigen Fallstudien geschafft und hat sich dann in diversen Scrum-Ban-Implementierungen manifestiert. Schlussendlich kam es zu einer Dichotomie zwischen Scrum und Kanban, in der entweder das eine oder das andere oder eben Scrum-Ban angewendet werden konnte. Dass das eine falsche Zwei- bzw. Dreiteilung ist, werde ich demnächst mal in einer Folge besprechen.

Lieber zuhören? Hier ist der Podcast:

Eines der Konzepte, das in diesem Übergang mitgekommen ist, und mit dem ich immer wieder konfrontiert werde, sind Product Owner und ScrumMaster. Über die möchte ich heute sprechen.

Nur kurz: Die Rolle des Product Owners ist im Original für die Maximierung des Werts des Produktes verantwortlich und rechenschaftspflichtig, wie es so schön im Scrum-Guide heißt. Der Scrum-Master soll Scrum im Sinne des Scrum-Guides fördern und unterstützen. Das geschieht dadurch, dass er beim Verständnis des Rahmenwerks hilft, Meetings moderiert und so weiter. Ich will da nicht zu tief einsteigen. Aber es geht auf jeden Fall darum, die Zusammenarbeit so zu optimieren, dass das Scrum-Team einen maximalen Wert generiert.

Im Wechsel zur Kanban-Methode ist dieser ScrumMaster dann häufig in Flow-Master oder Flow-Manager umbenannt worden. Wir haben in der Methode keine spezielle Vorschrift darüber, wie Rollen benannt werden sollen, insofern ist das, was kulturell angemessen ist, erstmal hilfreich und okay. Nichtsdestotrotz sprechen wir als verallgemeinerte Form von einer Service Delivery Managerin oder einem Manager. Er oder sie ist also für die Leistung der Dienstleistung verantwortlich. 

Wenn wir uns die Aufgaben angucken, die so ein ScrumMaster erledigt, dann könnten da in der Kanban-Methode noch ein paar Sachen hinzukommen. Da wir kein festes Rahmenwerk mit definierten Regeln haben, ist die Anforderung an die Rolle deutlich höher. Das merken wir in der Implementierung immer wieder. Wenn wir also eine Service Delivery Managerin haben, dann kümmert sie sich wahrscheinlich zum einen darum, den Betrieb der Dienstleistung aufrecht zu halten. Das bedeutet die Moderation der Meetings, Adressierung von Problemen, Führung übernehmen beim aktiven Risikomanagement und so weiter und so fort. Sie hat also ein Primärinteresse, dass die Repräsentation des Arbeitssystems, beispielsweise das Kanban-Board, aktuell ist und die vereinbarten Regeln eingehalten werden.

Zum anderen kümmert sie sich auch um den Verbesserungsteil der Kanban-Methode. Mir fällt gerade auf, dass ich diese Zweispaltung auch noch in einer kommenden Folge behandeln sollte. Sie ist also auch gefordert, wenn wir uns über die Leistung des Systems austauschen. Manchmal wird die Verantwortung für die Verbesserung auch alleine der Service Delivery Managerin übertragen. Das ist in modernen Arbeitsumgebungen nicht mehr so richtig zu erwarten, aber man wird ja immer wieder überrascht.

Die Service Delivery Managerin, oder Flow Managerin oder der Flow-Master sind also erst einmal dafür verantwortlich, dass die Dienstleistung aus systemischer Sicht die beste Leistung erbringt, die sie im Stande ist. Ganz schöner Knaller, aber machbar.

Wenn wir uns vom Scrum-Master mal zum Product Owner wenden, dann können wir auch diese Rolle übertragen und auch ein bisschen verallgemeinern. Die allgemeinere Rolle hat den Namen Service Request Manager. Es ist ziemlich doof, dass die sich so ähnlich sind: Service Delivery Manager und Service Request Manager. Aber sie beschreiben leider im Englischen ziemlich gut ihre Aufgabenbereiche.

Den Service Request Manager kann man in Kanban deutlich weiter fassen als einen Product Owner. Klar, es geht auch, dass wir genau die gleichen Verantwortlichkeiten und Entscheidungsbefugnisse übertragen, aber es geht eben auch anders. Die wichtigste Aufgabe dieser Rolle ist: Sie soll dafür sorgen, dass am Eingang der Dienstleistung, dem Commitment-Punkt die zu diesem Zeitpunkt richtigen Service-Requests, also Aufträge, ausgewählt werden.

Wie das passiert, wurde auch wieder offen gelassen, wie so häufig in Kanban. Es gibt aber so zwei extreme Formen. Das eine Extrem ist, dass die Entscheidung von einer einzigen Person getroffen wird, also beispielsweise genau diesem Service Request Manager. Der oder die guckt sich also die verschiedenen Optionen an und sagt dann: "Das, das und das!" Und das gilt dann auch. 

Das andere Extrem ist ein Service Request Manager, der nichts entscheidet außer den Prozess zu gestalten. Das bedeutet, er oder sie sorgt dafür, dass die Auftraggeber sich auf eine Reihenfolge und Zusammensetzung der Aufträge einigen, die sie mitbringen. Diese Auswahl kann er oder sie natürlich auch noch durch Beitragen von Modellen wie Weighted Shortest Job first oder CD3 oder ähnlichem unterstützen.

Es gibt natürlich Mischformen und die sind auch gut. Den einen Product Owner, der als einziger das Product Backlog verwalten kann, den gibt es bei Kanban nicht explizit vorgeschrieben. Wenn es angemessen ist, kann es sein, dass es so modelliert wird, aber in den meisten Fällen ist es einfach nicht angemessen.

Um das Ganze einmal zusammen zu fassen: Die Rollen ScrumMaster und ProductOwner sind zum Teil auch in der Kanban-Methode beziehungsweise in einzelnen Implementierungen präsent. Die Rollen sind nicht fortgeschrieben, häufig aber einer abstrahierten Form da. Wir sehen häufig in etwas reiferen Implementierungen, dass da jemand ist, die sich um den Eingang von Aufträgen und jemand, die sich um die optimale Abarbeitung kümmert. Das alles beschneidet die Möglichkeiten des Einbeziehen oder Gestaltens von Seiten der einzelnen Beitragenden nicht. Die beiden Rollen heißen im Allgemeinen Service Delivery Manager – zuständig für die schneller Dienstleistung – und Service Request Manager – zuständig für die Selektion der richtigen Aufträge.