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.