Budowa Produktu i organizacja pracy nad jego wytworzeniem to zadanie dla całej organizacji. Zbudowanie koncepcji nie jest pracą wyłącznie dla Scrum Mastera, Product Ownera czy kogokolwiek innego. Skąd się więc wzięło założenie, że jeden Produkt to jeden Product Backlog i jakie ma to znaczenie w kontekście zwinnej pracy?
Jeden Produkt
Zaczynając ten wpis powinniśmy na wstępie odpowiedzieć sobie na pytanie „Czym jest Produkt?”. Odpowiedź ta nie zmieści się jednak w jednym akapicie tego wpisu, dlatego rozprawkę na ten temat zostawimy sobie na któryś z kolejnych razów. Na dziś musi nam wystarczyć wyobrażenie, że Produkt to ta wartościowa rzecz, z której będzie chciał korzystać nasz klient. A tak naprawdę to wszyscy będziemy mogli czerpać korzyści z jego wytwarzania i dostarczania.
Patrząc na tę skróconą definicję Produktu widać już, że jest to cel działania Scrum Team lub wielu Scrum Teamów. Finalnym efektem ich pracy będzie „coś”. Słowo „coś” oddaje kolejną cechę Produktu, a mianowicie jego namacalność, pragmatyczne ujęcie i rozwój. Patrząc z punktu widzenia Scrum Team wytwarzanie Produktu to jedno, a dbanie o to, aby był najmniejszą częścią i odpowiadał na bieżące potrzeby to zupełnie coś innego.
Dbanie o Produkt
I właśnie w tym miejscu, na dbaniu o Produkcie, chciałem się na chwilę zatrzymać. O rozwój Produkt i jego wartość, jak każdy doskonale wie, dba dokładnie jedna osoba. Ta, która jest umocowana w organizacji do podejmowania decyzji. Czasami bywa ona nazywana Product Ownerem. Chcąc pomóc tej osobie potrzebujemy odpowiedniej organizacji naszej listy wymagań, czasami nazywanej backlogiem. W zakres dbania o nią wchodzić będą między innymi właściwy opis wymagań (np. w postaci User Stories) czy ustalenie ich kolejności i priorytetów. Istotną rzeczą będzie również zapewnienie kompletności przygotowanego rozwiązania.
Tutaj dochodzimy wspólnie do pierwszego wniosku. Właściwe dbanie o Produkt będzie utrudnione albo wręcz niemożliwe bez ujęcia go w jednym miejscu. Rozproszenie Produktu, np. podejście silosowe, wykrajanie poszczególnych jego aspektów i oddawanie do różnych departamentów czy działów, spowoduje rozmycie wizji rozwiązania. To z kolei będzie miało bardzo negatywny wpływ na efekt finalny.
W tym miejscu muszę napisać, że istnieją metodyki, które w lepszy bądź gorszy sposób radzą sobie z powyższym. Skalowanie zwinnego podejścia, według tych właśnie metodyk, dodaje nowe role, np. Proxy Product Ownera czy Business Ownerów, jednak koniec końców ktoś jest odpowiedzialny za spójność. Dodajmy, że w tym przypadku będzie to spójność rozmyta.
Co mamy począć?
Spojrzeliśmy na sprawę z punktu widzenia zarządzania Produktem. Spójrzmy zatem na Produkt z punktu widzenia osób odpowiedzialnych za wykonanie. Deweloperzy lubią wiedzieć, co mają robić. Oczywiście Ci, którzy wiedzą, że można mieć w jednej chwili jedną najważniejszą rzecz do zrobienia, a nie dwie czy trzy. Sprawa jest prosta w sytuacji, gdy Produkt nie jest duży, a zespołów nad nim pracujących – dokładnie jeden. Mamy jeden backlog, jeden zespół, mały produkt… czysty Scrum.
Sprawa się komplikuje w sytuacji, w której liczba zespołów rośnie, a Produkt składa się z wielu modułów lub podsystemów. Często pojawia się pokusa, aby wydzielić kilka backlogów, np. per moduł czy jeszcze gorzej – per zespół. Do tego dorzućmy jeszcze osobnego PO każdego z nich i zaczyna się problem. Często jest tak, że każdy z PO będzie wydzierał będzie z Backlogu „głównego” swoje księstwo i nim zarządzał. Często będzie ono związane z odpowiednią domeną wiedzy, ale czy przy okazji będzie dbał o spójność całości? Nasze doświadczenie pokazuje, że bardzo często nie.
Kolejnym etapem w tym łańcuszku zdarzeń jest powołanie osoby „nadzorującej i spinającej” Product Ownerów, która rzekomo ma scalać wszystkie backlogi, dbać o spójność Produktu i… I jesteśmy już strasznie daleko o lekkiego, zwinnego podejścia. Na tyle daleko, że odpowiedzialność za Produkt się rozmywa, a powstające Przyrosty często w ogóle nie są zintegrowane. Ba, nijak nie można ich nawet nazwać jednym Produktem.
Jeden Produkt, jeden Product Backlog
Oto najważniejsze argumenty za podejściem jeden Produkt, jeden Product Backlog. Działanie w ten sposób spowoduje, że będziemy mieli jedną listę wszystkich wymagań identyfikującą najważniejsze w danej chwili rzeczy do zaadresowania w Produkcie. Dodatkowo dzięki ujęciu wszystkich wymagań w jednej liście dbamy o pragmatyczność Produktu jak również jego spójność. Ułatwia to pracę zarówno osobie odpowiedzialnej za Backlog Produktu jak i osobom tworzącym przyrosty w poszczególnych iteracjach.
Inne podejścia, możliwe do zastosowania i często skuteczne, muszą być stosowane „z głową”. Zawsze powtarzamy, nie idźmy w żadną metodykę „bo jest na nią moda”, postarajmy się ją zrozumieć i odpowiedzieć na pytanie, czy tego potrzebujemy. Bardzo często, po dziesięciu czy dwudziestu Sprintach odejdziemy od założeń wybranej, „modnej” metodyki. Dlaczego? Bo nie będziemy mieli żadnych benefitów z jej wykorzystania.
