W trakcie jednego z ostatnich szkoleń dla Product Ownerów usłyszałam od uczestnika pytanie: “Po co Product Ownerowi Kanban?”. To nie pierwszy raz, kiedy spotykam się z pytaniem o to, po co podczas wykonywania zadań związanych z produktem jest potrzebna znajomość różnych podejść do wytwarzania wartości. Mimo tego, za każdym razem zaskakuje mnie, jakie zdziwienie u osób początkujących budzi odpowiedź. A przecież chodzi po prostu o to, żeby Product Owner wiedział, jak pracuje jego zespół.
Jak pracuje Twój zespół?
No właśnie. Zdanie “Product Owner powinien znać zasady Kanbanu” brzmi inaczej niż “Product Owner powinien wiedzieć, jak pracuje jego zespół”, prawda? O ile pierwsze stwierdzenie budzi pytania, to drugie jest już bardziej oczywiste. Będąc osobą odpowiedzialną za produkt, nie możesz być oderwany od procesów i zasad, którymi kieruje się zespół. Dzięki temu wiesz, jak interpretować wyniki jego pracy, metryki i jak wyciągać z tego informacje istotne np. dla interesariuszy.
Kanban wspiera proces, w ramach którego zespół wytwarza wartość. Pozwala odkrywać wąskie gardła, eliminować straty, optymalizować przepływ pracy i mierzyć to, co się dzieje w całym otoczeniu. Czy to właśnie nie te aspekty powinny być istotne dla Product Ownera?
Jak maksymalizujesz wartość, którą dostarczasz w produkcie?
Product Owner, niezależnie od tego, czy pracuje w Scrum Teamie czy wykorzystuje inne zwinnym podejście,będzie odpowiedzialny za maksymalizację wartości produktu. Zasady określone w Kanbanie to świetne narzędzie, by to działanie wspierać.
Weźmy na przykład limit WIP (Work In Progress) – właściwie określony pomaga wyeliminować wąskie gardła i skrócić czas dostarczenia funkcjonalności do użytkowników. W wielu eksperymentach prowadzonych z limitem WIP widać jasno, że jego odpowiednie dopasowanie pozwala zespołowi być nawet dwukrotnie bardziej efektywnym niż w przypadku, gdy limitów nie ma. Dodatkowo, dzięki takiemu opanowaniu kolejnych etapów prac, unikamy zbędnego chaosu, a praca wydaje się mniej obarczona presją. A jak dobrze wiemy – to mocno wspiera skupienie i wyklucza potencjalne błędy wynikające z pośpiechu czy stresu.
Znajomość metryk pozwala Product Ownerom opierać decyzje na danych, a nie na domysłach i przypuszczeniach. Takie podejście zaś prowadzi do bardziej trafionych decyzji i w efekcie dostarczania tego, czego naprawdę chcą użytkownicy. Oczywiście, pamiętaj, że Kanban to nie tylko metryki!
Czy to nie Scrum Master albo Project Manager powinni znać Kanban?
Tak, oczywiście! Powinni, jeśli go wykorzystują. Będą też ogromnym wsparciem dla zespołu i Product Ownera w tym zakresie. Ale nie wyręczą Product Ownera w roli jaką pełni w całym procesie. Każda osoba pracująca nad rozwojem produktu powinna wiedzieć, jak efektywnie osiągać cele postawione jej w danym momencie. Poszukiwanie różnych możliwości, sposobów pracy i eksperymentowanie z nimi jest jednym z najlepszych podejść. Scrum Master czy Project Manager, z natury ich ról, mogą mieć szersze kwalifikacje i większe doświadczenie w procesach, ale ich know-how i praca nie wystarczą do tego, by Product Owner wykorzystywał np. Kanban prawidłowo i ze zrozumieniem. Obie wspomniane role będą wspierać Product Ownera, podsuwać rozwiązania, ale bez jego zaangażowania i chęci, nic nie wskórają.
Czyli po co Product Ownerowi Kanban?
Po to, by lepiej wykonywał swoją pracę. Jeśli działasz w Kanbanie, nie musisz być ekspertem, ale zadbaj o jego zrozumienie, byś był w stanie wesprzeć zespół, kiedy będzie tego potrzebował.
I pamiętaj, nie tylko o Kanban tu chodzi – to samo dotyczy innych podejść. Bo gdy Twój zespół szuka najlepszej metody pracy albo usprawnia swoje procesy, jako Product Owner też masz na to wpływ.
Polecamy podcast Radka Orszewskiego o Kanban Guide:
Sprawdź nasze poprzednie wpisy:
