Do we need a Product Owner in Kanban?

(Eine Deutsche Version dieses Posts findet sich hier)

The question of the necessary / appropriate roles in Kanban is certainly among the most frequently asked. Since Kanban is neither a development process nor a project management methodology, but a change method, there is no role model specified. So the simple answer to the question above is: "Start with what you have and retain the existing roles until you find out that you should do something about it."

Kanban has, however, the "unpleasant" property to uncover existing problems in an organization very quickly. And in my experience the most virulent problems can often be found upstream in product management. As soon as it becomes clear that an insufficient or missing product management is the root cause of your problems, you have to seriously think about the proper role for this - even in Kanban.

Let us first have a look at product development, for example an organization that publishes an online newspaper or delivers an accounting software to their customers. If there is no working product management, this leads directly to chaos (no matter if you do or do not use Kanban). Once that developers or testers start to prioritize requirements on their own, focus will be lost very soon and and the product starts to "fray". Moreover, in such a situation, there´s a strong tendency for all kind of stakeholders (customers, salespeople, marketing, etc.) to submit "their" requirements directly to the team - and of course they always have the priority "A ***". This leads to high pressure on those implementing the requirements. In this situation they will most likely try to satisfy those first who shout the loudest. But of course this does not mean that their requirements are also the most important ones! Moreover, it can often be observed that more and more new tasks are started to satisfy the "squallers", but this does not mean that these tasks will be completed quie sonn as well (in a reasonable quality) - exactly the opposite of which we want to achieve with Kanban! And finally, it is extremely unlikely in a situation like this that tasks that are important but not urgent (in Kanban they are called Intangibles) will ever get a high priority. Sooner or later this leads to certain destruction.

So we need someone who takes care of the following:

●     Collect tasks from various people, teams and departments and prioritize them;

●      Stay in contact with the stakeholders, understand their needs and keep them up to date;

●      Shield the implementation team;

●      Create a product vision (in collaboration with the team) that should be as clear and simple as possible;

●      Ensure that new product increments are built as often as possible in order to get feedback from customers and other stakeholders. This in turn has certain effects on the slicing of the requirements .

This sounds somehow familiar, right? Yes, it is exactly what the Product Owner is supposed to do in Scrum! So if you have problems regarding the product management, it is quite useful to implement the role of the Scrum Product Owner as a starting point - even in Kanban.

Now there are not only product houses, but also service organizations such as maintenance teams, web agencies and other service providers. They do not develop a product continuously, but have to deal with multi-project management (even if the projects might be very small). They carry out projects for several external or internal "customers". In precisely such contexts Kanban has eveolved (maintenance teams at Microsoft and Corbis, see Anderson 2011, Chapter 4 and 5). Again, I think it is important that the prioritization is not done by the developers, testers etc., but by "someone else". This could be a Product Owner, in which case the name no longer fits properly (some organizations speak of the "Request Manager" or "Service Owner"). As David Anderson describes, this role could also be divided and performed by several different managers (whereas a distribution of the Product Owner role in Scrum is not recommended). In this context it is necessary to have an accepted and transparent process to prioritize the tasks (for example, in a round-robin procedure, see Anderson 2011, Chapter 9.6). And because service organization have to deal with intangibles as well, it must be ensured that these tasks won´t be ignored constantly. The use of Gold Cards could be a way to deal with intangibles here, so for instance developers are allowed to pull tasks like improving their infrastructure into the system from time to time.

The function of shielding is particularly important in service organizations because here we are dealing with many small tasks that occur very irregularly.

Since service organizations usually do not develop a certain product, it is not necessary to craft and maintain a product vision. At the same time, however, I have learned from experience that it can be extremely helpful for service teams to have a team vision. Such a vision will give guidance for prioritization, might improve the teamwork and can help other teams within the organization to better understand what kind of work the service team is dealing with. Therefore, the role of the Service Owner must not be underestimated.

References

David Anderson (2010): Kanban. Successful Evolutionary Change for Your Technology Business. Blue Hole Press.

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.