Monday, August 8, 2011

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.

3 comments:

  1. Danke für den interessanten Post, Arne! Ich bin auch der Meinung, dass unabhängig vom benutzen Prozess die Verantwortung für ein Produkt bzw. einen Service geklärt sein muss. Meine Zusammenfassung der Product-Ower-Rolle findet sich übrigens hier: http://www.romanpichler.com/blog/roles/one-page-product-owner/

    ReplyDelete
  2. sehr gute inputs in diesem post, vielen dank! "start where you are" ist definitiv ein starkes kanban-prinzip und eine gute & valide antwort auf das manchmal krampfhafte suchen nach einer rollenbesetzung, die in anderen frameworks ev. ein must-have ist. bin selbst seit 2,5a scrum mistress in einem service team (kanban) - priorisiere aber auch das backlog und handle die requestoren (+30 verscheidene requestoren). habe somit eine rollenaufteilung (SM/SO), die eigentlich schwer "illegal" ist.

    funktioniert allerdings like a charm.

    habe mich in letzter zeit viel damit beschäftig, wie dieser rollenmix sinnvoll - und den regeln wie sie in den büchern stehen entsprechend - aufzulösen wäre, aufgrund fehlender passender kandidaten für eine besetzung allerdings keine lösung in sicht. bis ich mir schließlich dachte: muss diese role-violation wirklich aufgelöst werden? welchen pain will ich damit eigentlich lösen? was würde das bringen - und wem? fakt ist: das team performt 1a, die stimmung ist bestens, wir arbeiten konstant an uns - einzig die regel "Your ScrumMaster has no duties outside of the ScrumMaster duties" ist gebrochen. vor einem scrum-gericht ... höchststrafe ;)

    real life breaks the rules. sometimes.

    hast du - oder ein leser hier - vielleicht ähnliche erfahrungen mit solchen role-violations gemacht? wie ist eure meinung dazu?

    ReplyDelete
    Replies
    1. Hallo,

      ich finde es wertvoll, sich näher damit zu beschäftigen, warum Scrum die Rollen so aufteilt, wie es in den Büchern steht. Dafür gibt es ja gute Gründe. Wenn man die verstanden hat und sich der Risiken bewusst ist, dann gibt es sicherlich viele Lösungen, die funktionieren, auch wenn sie so im Lehrbuch nicht vorkommen.

      Viele Grüße,
      Arne

      Delete