Brauchen wir in Kanban einen Product Owner?

(You can find an English version of this blog post post here) 

Die Frage nach den nötigen/richtigen Rollen in Kanban gehört sicherlich zu den am häufigsten gestellten. Da Kanban keinen Entwicklungsprozess und auch keine Projektmanagement-Methode darstellt, sondern eine Change-Methode, ist hier kein Rollenmodell vorgegeben. Die einfache Antwort lautet daher: "Startet mit dem, was ihr habt und behaltet die existierenden Rollen so lange bei, bis ihr herausfindet, dass ihr sie ändern solltet."
Kanban hat allerdings die "unangenehme" Eigenschaft, existierende Probleme in einer Organisation schnell aufzudecken. Und meiner Erfahrung nach liegen die größten Probleme häufig upstream im Produktmanagement. Wenn sich aber herausstellt, dass ein unzureichendes oder gar fehlendes Produktmanagement die Ursache von Problemen ist, dann muss man sich ernsthaft Gedanken über die passende Rolle hierfür machen - auch in Kanban.
Betrachten wir zunächst Produktentwicklung, beispielsweise eine Organisation, die eine Online-Zeitung herausgibt oder eine Buchhaltungs-Software an ihre Kunden ausliefert. Wenn es hier kein funktionierendes Produktmanagement gibt, führt dies direkt ins Chaos. Sobald nämlich Entwickler oder Tester anfangen, Anforderungen selbstständig zu priorisieren, geht bald jeglicher Fokus verloren und das Produkt "franst aus". Darüber hinaus besteht in so einer Situation die Tendenz, dass alle möglichen Stakeholder (Kunden, Vertriebler,  Marketing usw.) "ihre" Anforderungen direkt an das Team herantragen - und natürlich haben sie immer die Prio "A***". Hierdurch entsteht zum einen ein hoher Druck auf diejenigen, die die Anforderungen umsetzen, so dass sie in der Regel zuerst zuerst den berücksichtigen, der am lautesten schreit. Das bedeutet aber noch lange nicht, dass dies auch die wichtigste Anforderung für das Produkt ist! Darüber hinaus lässt sich oft beobachten, dass immer wieder neue Aufgaben begonnen werden, um die "Schreihälse" zufrieden zu stellen, was aber noch lange nicht heißt, dass diese Aufgaben auch (in vernünftiger Qualität) abgeschlossen werden - genau das Gegenteil also von dem, was wir mit Kanban erreichen wollen. Und schließlich ist es in so einer Situation extrem unwahrscheinlich, dass Aufgaben, die wichtig aber nicht dringend sind (in Kanban heißen sie Intangibles) jemals nach oben priorisiert werden. Und dies führt früher oder später zum sicheren Untergang.

Wir brauchen also jemanden, der die folgenden Aufgaben wahrnimmt:

• Anforderungen von verschiedenen Seiten einsammeln und priorisieren;
• Mit den Stakeholdern in Kontakt bleiben, ihre Bedürfnisse abfragen und sie auf dem Laufenden halten;
• Das Realisierungsteam abschirmen;
• Zusammen mit dem Team eine möglichst klare Produktvision erstellen;
• Dafür sorgen, dass möglichst häufig neue Produktinkremente erstellt werden, zu denen Kunden und andere Stakeholder ihr Feedback geben können. Das wiederum hat bestimmte Auswirkungen auf den Zuschnitt von Anforderungen.

Das kommt uns doch irgendwie bekannt vor, oder? Richtig, dies sind genau die Aufgaben, wie sie der Product Owner in Scrum wahrnehmen sollte! Für Produkthäuser, die Probleme mit dem Produktmanagement haben, ist es deshalb durchaus sinnvoll, die Rolle des Product Owners nach Scrum zu besetzen - auch in Kanban.

Nun gibt es aber nicht nur Produkthäuser, sondern auch Service-Organisationen wie beispielsweise Wartungsteams, Webagenturen oder andere Dienstleister. Sie entwickeln nicht kontinuierlich an einem Produkt, sondern betreiben im weitesten Sinne Multiprojekt-Management (wobei die Projekte auch sehr klein sein können) für mehrere externe oder interne "Kunden". In genau solchen Kontexten ist Kanban ja entstanden (Wartungsteams bei Microsoft und Corbis, vgl. Anderson 2011, Kapitel 4 und 5). Auch hier halte ich es für wichtig, dass die Priorisierung nicht von den Entwicklern, Testern usw. durchgeführt wird, sondern von "jemand anders". Das kann ein Product Owner sein, wobei dann der Name nicht mehr richtig passt (einige Organisationen sprechen vom "Anforderungsmanager" oder "Service Owner"). Wie David Anderson beschreibt, kann diese Rolle jedoch auch aufgeteilt und z.B. von mehreren Managern gemeinsam wahrgenommen werden (wohingegen eine Aufteilung der Product-Owner-Rolle bei Scrum ja vermieden werden soll). Dafür ist es notwenig, dass es ein akzeptiertes und transparentes Verfahren gibt, wie diese Priorisierung vonstatten geht (beispielsweise in einem Round-Robin-Verfahren, vgl. Anderson 2011, Kap. 9.6). Und weil ja auch in Service-Organisation Intangibles anfallen, muss gewährleistet werden, dass diese nicht ständig hinten runterfallen. Denkbar sind hier beispielsweise Gold Cards, die die Entwickler in regelmäßigen Abständen in das System geben dürfen, um beispielsweise Verbesserungen an ihrer Infrastruktur vorzunehmen.
Die Funktion des Abschirmens halte ich in Service-Organisationen auch deshalb besonders wichtig, weil wir es hier häufig mit vielen kleinen Aufgaben zu tun haben, die sehr unregelmäßig anfallen.
Da Service-Organisationen in der Regel kein einheitliches Produkt entwickeln, fällt hier erst einmal die Erstellung und Pflege einer Produkt-Vision weg. Gleichzeitig habe ich jedoch die Erfahrung gemacht, dass es extrem hilfreich sein kann, dass sich das Team eine Vision gibt. So eine Team-Vision hilft dann bei der Priorisierung der Aufgaben, kann die Zusammenarbeit im Team verbessern und trägt dazu bei, dass andere Teams innerhalb der Organisation besser verstehen, was die Aufgaben des Service-Teams sind (und was nicht). Die Aufgabe des Service Owners sollte also keinesfalls unterschätzt werden.

Literatur
David Anderson (2011): Kanban. Evolutionäres Change Management für IT-Organisationen. dpunkt Verlag.