Im Scrum-Rahmenwerk gibt es keinen Projektleiter im herkömmlichen Sinne mehr. Einige seiner Aufgaben übernimmt der Product Owner (andere Aufgaben gehen auf den Scrum Master oder das Team über, einige fallen ganz fort). Und er bekommt Kompetenzen und Aufgaben zusätzlich, die für eine öffentliche Verwaltung oft in Richtung „Amtsanmaßung“ deuten. Mit einem Wort: der „PO“ hat es nicht leicht. Und er ist – ganz unabhängig von Scrum – ein Beispiel für die Änderungen der Organisationskultur, die agile Arbeitsweisen für die Verwaltung bedeuten.
Die Rolle des Product Owners
Die folgenden Erklärungen und Beispiele beziehen sich auf Digitalisierungsprojekte („Einführung der eAkte“) in Verwaltungen. Aber ich glaube, auch in anderen Projekten der Organisationsentwicklung dürften Verantwortliche ähnliche Erfahrungen machen.
In unseren Seminaren beschreiben wir die Rolle des Product Owners als eine Art „Mini-CEO“ für das Projekt:
- Er ist verantwortlich für die Erreichung der Projektziele und die Einhaltung des Projektbudgets (in Euro und in internem Personalaufwand).
- Er hat die Hoheit über die Anforderungsliste des Projekts (das sog. „Product Backlog“). Er sorgt dafür, dass neue Anforderungen, die im Laufe des Projekts aufkommen, in die Anforderungsliste aufgenommen werden.
- Er definiert Umfang und Qualität, mit denen Anforderungen umgesetzt werden (nur „Pareto-Niveau“? Oder inclusive „Sahnehäubchen“?)
- Er entscheidet über das „Was“ im Projekt: Er wählt die Aufgaben aus, die im nächsten Sprint erledigt werden sollen.
- Er nimmt die Sprintergebnisse im sog. Review ab.
- Er bestimmt nicht, wie das Team die Arbeit erledigt.
- Er greift nicht in die Selbstorganisation des Teams ein.
Der Product Owner (PO) ist der Nutzenmaximierer (Nutzen für die Anwender und Nutzen für die Organisation). Er muss deshalb ein gutes Verständnis für Verwaltungsprozesse haben und dafür, was die künftigen Anwender der eAkte brauchen. Dann kann er sie gut unterstützen beim Formulieren von Anforderungen. Er muss nicht sehr IT-affin sein oder die internen Datenstrukturen von DMS-Produkten kennen.
Der große Unterschied zu herkömmlichen Projekten: auch kein Auftraggeber und kein Lenkungsausschuss kann dem PO in seine Entscheidungen hineinreden. Das ist für hierarchische Organisationen (egal ob Öffentlicher Dienst oder Privatwirtschaft) eine extreme Umstellung. Immer wollen Führungskräfte entscheiden dürfen, ob sie mit einem Projektergebnis zufrieden sind oder nicht. Bei Scrum liegt das Recht der Ergebnisbeurteilung allein beim Product Owner. Alles andere würde zu dauernden unnötigen Verbesserungsschleifen führen und das Projekt unabsehbar in die Länge ziehen.
Herausforderung: Delegation von Entscheidungen nach unten
Ich bringe zwei Beispiele, um zu zeigen, wie die Kompetenzzuschreibungen zur Rolle des PO’s zu Konflikten mit herkömmlichen „Zuständigkeiten“ führen können.
Beispiel 1:
In agilen Projekten wird in Sprints gearbeitet. Im Umsetzungsteam für das DMS ist immer auch ein Programmierer des Software-Lieferanten dabei (zumindest solange, bis die DMS-Administratoren in der Verwaltung so fit sind, dass sie die Software eigenständig, ohne Rückgriff auf den Hersteller, customizen können). Diesem Programmierer wird in der Regel am Ende des Sprint-Planungsmeetings ein Auftrag zur Realisierung bestimmter Customizing-Anforderungen im System erteilt. Dieser Auftrag stellt rechtlich einen Werkvertrag dar. Wenn es um zwei, drei Programmierertage geht, kann der Aufwand schon eine vierstellige Summe ausmachen. Agile Philosophie bedeutet: der PO darf diesen Werkvertrag abschließen. In vielen Verwaltungen übersteigt das aber die Wertgrenzen, für die er Zeichnungskompetenz hat. Also meldet sich die Beschaffungssstelle: „Lieber Kollege PO, du musst einen Beschaffungsantrag bei uns stellen.“
Das sprengt natürlich die ganze agile Logik des Arbeitens in kurzen Zyklen. Zum Beispiel ist die Sprintlänge im DMS-Projekt zwei Wochen, und die Beschaffung braucht mindestens eine Woche, bis sie den Beschaffungsantrag durch ihren Prozess („best practice! KGSt-geeicht!“) durchgeschleust hat. Der Antrag wird genehmigt zu einem Zeitpunkt, an dem die Leistung schon erbracht sein müsste.
Beispiel 2
Der Product Owner ist zuständig für die Abnahme des Produkts. Der oder die Auftraggeber („Lenkungsausschuss“) erhalten keine Projektstatusberichte mehr. Sie haben stattdessen die Möglichkeit, am Ende des Sprints zum sog. „Review“ zu kommen und sich den Zwischenstand der Projektarbeit praktisch vorführen zu lassen.
In einem meiner Projekte nahm der Hauptamtsleiter, Herr Büttenküfer, diese Möglichkeit ab und zu wahr. Immer wenn er zur Tür reinkam, meist zehn Minuten nach Meetingbeginn, schnaufte er ein bisschen. Weniger wegen der Treppen zum Sitzungszimmer unter dem Dach, als um auszudrücken: „Jetzt muss ich mich zu meinen Untergebenen bewegen. Früher war das aber anders!“
Ein Ereignis ist mir noch im Gedächtnis, obwohl es bestimmt vier Jahre her ist. Das Ergebnis des Sprint-Reviews war „ein Standard für Dokumentennamen“. Zur Erklärung: in einem modernen DMS gibt es keine Dokumentennamen mehr. Es gibt nur noch Metadaten zu Dokumenten, ähnlich wie schon bei E-Mails: die zugehörige Vorgangs-ID, ein Erstellungsdatum, der Verfasser, evtl. ein Betreff oder ein Stichwort usw. Namen für Dokumente und Dateien treten nur wieder beim Export auf, wenn ich eine Datei als Anhang mit einer E-Mail an einen externen Empfänger versenden will oder auf einen USB-Stick kopiere.
Das Team erläuterte, welche Metadaten künftig in die Bildung von Dokumentennamen einfließen werden und welche Bedarfe verschiedener Anwendergruppen man berücksichtigt habe. Auf einmal hielt es Herrn Büttenküfer nicht mehr. „In unserer aktuellen Dienstanweisung, die wir schon zur Einführung der ersten PC’s ganz aktuell verfasst hatten, steht ganz eindeutig, dass das Datum am Anfang jedes Dateinamens zu stehen hat. Und das haben wir uns damals ganz genau überlegt und aus guten Gründen so beschlossen. Jetzt haben wir endlich ein DMS und wir können dafür sorgen, dass die DA auch endlich eingehalten wird, und was machen wir?? Wir werfen alles über den Haufen! Damit bin ich überhaupt nicht einverstanden. Das müssen Sie bitte noch einmal überarbeiten!“ Sprach’s und verabschiedete sich wieder aus dem Meeting.
Was Herr Büttenküfer nicht verstand oder nicht respektieren wollte: Er hatte massiv seine Rolle verletzt. Die Frage, wie ein bestimmtes Detail im DMS zu customizen ist, ist nicht Sache der Führungskraft als Auftraggeber (in diesem Falle ist er Anwender wie jeder Sachbearbeiter). Sondern es ist Sache des Teams, das eigenständig Lösungen erarbeitet auf Grundlage bestimmter Qualitätskriterien . Und es ist Sache des Product Owners, der diese Lösungen abnimmt und dies auch nicht willkürlich, sondern eben auf der Basis der vereinbarten Anforderungen und ihrer Qualitätsstandards.
Im Ergebnis hatte der Hauptamtsleiter das Umsetzungsteam demotiviert und den PO herabgesetzt.
In beiden Beispielen geht es darum, dass Entscheidungen „nach unten“ – an den (in herkömmlichen Begriffen:) Projektleiter = Product Owner delegiert werden. Das erste Beispiel verweist zusätzlich darauf, dass Prozesse in den Verwaltungen oft lokal optimiert werden (der Prozess „des Einkaufs“) und nicht global (als End-to-end-Prozesse). Prozesse werden in den Silos optimiert, auch wenn das global einen Rückschritt darstellt.
Im zweiten Beispiel entpuppt sich Herr Büttenküfer als Mikromanager, der sich als besserer „Fachexperte“ in Sachen Dokumentennamensregel-festlegungsfertigkeit beweisen will und darüber seine Rolle als Führungskraft aus den Augen verliert.
Agile Verwaltung 
Nach meinem Verständnis nimmt der PO die Dinge nicht im Review ab, sondern wenn sie fertig entwickelt sind. Außer natürlich „vom PO abgenommen“ ist nicht Teil der DOD. Dafür habe ich aber, egal welches Team in welcher Behörde ich betreut habe, bis jetzt noch keinen guten Anwendungsfall gefunden und würde mich über Beispiele freuen. Meistens ist es, wieder meiner Erfahrung nach, nämlich ein Anzeichen dafür, dass der PO nicht genug Entscheidungsgewalt über das Produkt hat.
Dazu das Zitat aus dem Scrum Guide zum Review: „Der Product Owner erklärt, welche Product-Backlog-Einträge fertig [„Done“] sind, und welche nicht.“
LikeLike
Lieber Andreas, ich weiß nicht, ob ich Deinen Kommentar richtig verstanden habe. Suchst Du ein Beispiel für ein Produkt in einer Behörde, das von einem starken PO betreut wurde oder ein Beispiel für eine DoD? Ich stimme Dir zu, dass der PO selten die nötige Entscheidungsgewalt hat, die ein gutes Produkt bräuchte. Da haben die entsprechenden Stakeholder nicht die Spielregeln gelesen, bevor das Scrum-Team beauftragt haben. LG, Jan
LikeLike