Ilu Właścicieli Produktu potrzebujesz?

Zdarzyło mi się kiedyś usłyszeć takie słowa „No to mamy tego Scruma, ale mamy mały problem z Właścicielem Produktu…”. „Hm, a co to znaczy: mały problem?” – zapytałem. „W zasadzie to problem polega na tym, że go nie ma…”.

Scrum Guide mówi jasno: żeby nazywać swoją pracę Scrumem, musisz mieć wszystkie elementy opisane w tym przewodniku. Jednym z najważniejszych elementów Scruma jest rola Właściciela Produktu – jeżeli go nie ma (albo jeżeli z jakiegoś powodu nie pełni swojej roli, albo jest więcej niż jedna osoba zarządzająca backlogiem), to po prostu nasza metoda pracy nie jest Scrumem, tylko czymś innym.

I tutaj często pojawia się kolejne zastrzeżenie: „Ale nasz produkt jest tak skomplikowany, że nie ma żadnej osoby, która potrafiłaby go zrozumieć i pełnić taką rolę!”. Przyjrzyjmy się zatem, w jaki sposób różne metody i frameworki radzą sobie z problemem zarządzania złożonym backlogiem.

Scrum Standard Edition

Scrum Guide zasadniczo opisuje sytuację, w której mamy jeden produkt, jednego Właściciela Produktu, jeden Backlog Produktu oraz jeden zespół. „One ring to rule them all…”.

Co prawda w przewodniku znajdziemy kilka wzmianek o tym, że nad jednym produktem może pracować kilka zespołów, np. taką:

Często nad jednym produktem pracuje wspólnie kilka Zespołów Scrumowych. Do opisywania przyszłej pracy nad produktem używany jest jeden Backlog Produktu.

…ale nie znajdziemy tam zbyt wiele wskazówek, w jaki sposób te zespoły powinny ze sobą współpracować.

Skoro standardowy Scrum nie daje nam odpowiedzi, spójrzmy na to co proponują nam inne frameworki, na przykład…

Nexus i LeSS

Oba frameworki proponują współpracę wielu zespołów deweloperskich z jednym Właścicielem Produktu:

Twórcy LeSS-a twierdzą, że taki układ działa dla 2-8 zespołów. Twórcy Nexusa powiedzieli „przebijam!” i rekomendują takie rozwiązanie dla 3-9 zespołów.

8-9 zespołów po 8-9 osób daje nam około 60-80 osób – czyli dość sporo… Tutaj często pojawia się wątpliwość, czy jeden człowiek jest w stanie ogarnąć zadania dla takiej ilości osób. Z moich doświadczeń wynika, że jest to możliwe, o ile spełnionych jest kilka warunków:

  1. elementy w Backlogu są dość generyczne – muszą być to elementy o wartości biznesowej, a nie zadania techniczne;
  2. zespoły są w stanie szacować i wykonywać takie elementy;
  3. zespoły są w stanie w jakimś stopniu wymieniać się pracą (tzn. nie są wąsko specjalizowane).

Praca Właściciela Produktu sprowadza się wówczas głównie do przekazywania wizji rozwoju produktu, dekompozycji tej wizji na elementy Backlogu oraz priorytetyzowania tych elementów.

LeSS Huge

A co jeżeli mamy więcej niż 8-9 zespołów? Framework Nexus w tym momencie zdaje klucze i nie oferuje nam żadnego wsparcia w takiej sytuacji. Natomiast twórcy LeSS-a proponują nam rozwiązanie nazwane przez nich LeSS Huge. Z grubsza polega ono na tym, że zachowujemy nasz wspólny Backlog – ale dzielimy go na obszary. Do każdego z obszarów przypisujemy osobę nazwaną Area Product Owner, która staje się właścicielem tego wydzielonego Backlogu. Czyli wygląda to mniej więcej tak:

Ważne jest to, że obszary nadal powinny pozostać dość duże, czyli nadal jest to od 2 do 8 zespołów. Do każdego z obszarów stosujemy reguły LeSS-a – natomiast „nad nimi” jest jeszcze wspólny Backlog oraz osoba, która ustala priorytety na wysokim poziomie.

SAFe

Scaled Agile Framework proponuje inne rozwiązanie z nieco zmienioną konwencją nazewnictwa. Podstawową jednostką organizacyjną w SAFe jest Agile Release Train, który skupia od 5 do 12 zespołów. Prace wykonywane przez te osoby są zapisane przez Product Manager’a w Program Backlog’u. A elementy tego Program Backlogu są rozpisywane na elementy Backlogów Zespołów – i do każdego z backlogów jest przypisywany odpowiedni właściciel:

Ważnym elementem powyższego rysunku są cyferki. SAFe proponuje podział Program Backlogu na 2-4 backlogi dla zespołów. A każdy z Team Backlogów powinien być źródłem pracy dla 1 lub 2 zespołów.

Widać z tego, że dla tej samej wielkości zespołu będziemy mieli więcej backlogów oraz ich właścicieli niż we framework’u LeSS. I najprawdopodobniej backlogi zespołów będą mniejsze niż backlog produktu w LeSS-ie.

Czego nie robić?

Mimo wszystkich różnic, jest jedna rzecz co do której wszystkie rozwiązania są zgodne. Jeżeli mamy jeden Backlog (Product Backlog, Area Backlog, Team Backlog, Program Backlog, …), to zawsze musi być jedna i tylko jedna osoba, która nim zarządza. Nie mamy zatem nigdy takiej sytuacji:

Tymczasem jest to sytuacja, jaką często spotykamy w organizacjach projektowych. Może ona wyglądać na przykład tak:

Po lewej mamy listę projektów, nad którymi nadzór sprawuje Project Management Office. Każdy projekt ma przypisanego Project Managera, który dekomponuje (najczęściej z pomocą przedstawicieli zespołów, analityków lub architektów) swój projekt na zadania. Te zadania są rozdzielane między zespoły – a w rezultacie każdy z zespołów współpracuje z kilkoma PM-ami. Czyli backlog zespołu jest zarządzany przez grono osób, z których każda ma swoje priorytety.

Konsekwencją takiej sytuacji są najczęściej konflikty pomiędzy różnymi projektami. Popularnym rozwiązaniem jest przekazanie komuś prawo do rozstrzygania o priorytetach. Dzieli się czas zespołów („w marcu zespół pracuje nad projektem A, w kwietniu nad projektem B”) lub członków zespołu („Adam pracuje nad projektem A, Bartek nad projektem B”) albo też dzieli się obie rzeczy naraz. Konsekwencją takiej sytuacji jest brak przejrzystości w kwestii priorytetów zadań („dla zespołu A najważniejszy jest projekt Alfa, ale część tego projektu jest przypisana do zespołu B i czeka na projekt Beta”), co z kolei powoduje że dużo wysiłku wkłada się w komunikację między zespołami. Konsekwencją takiej sytuacji jest praktyczna trudność skupienia się na najważniejszych projektach. Konsekwencją takiej sytuacji jest ograniczenie możliwości wprowadzania zmian przez PM-a. Konsekwencją takiej sytuacji jest wreszcie brak budowania długoterminowej relacji między PM a zespołem.

Model ten zwiększa szanse sukcesu pojedyńczych projektów – ale jednocześnie drastycznie zmniejsza zdolność zmiany dla całego produktu.

A ty?

A jakie jest Twoje doświadczenie współpracy z Właścielami Produktu? Czy stosujesz jeden z pokazanych wyżej schematów czy jeszcze coś innego?

Będę wdzięczny za podzielenie się uwagami w komentarzach!

6 thoughts on “Ilu Właścicieli Produktu potrzebujesz?

  • 5 kwietnia 2017 at 18:12
    Permalink

    jesli Twój produkt jest tak duży i skomplikowany ze nie ma jednego PO który to potrafi ogarnąć.. to powinien być to znak ze robisz coś zle! czas zainwestować grube $$ im większy produkt tym większe $$ naturalnie i rozbić produkt tak by mogły nad jego rozwojem pracować niezależne (tak bardzo jak to możliwe) zespoły z w miarę niezależnymi PO. Jeden ważniejszy PO ma wtedy swój zespół PO i razem rozwijają zwinny produkt (np.:uzgadniając wspólne dostawy). jak zrobione dobrze to się nawet pięknie skaluje!

    Reply
    • 5 kwietnia 2017 at 22:47
      Permalink

      Pytanie, co masz na myśli mówiąc o rozbiciu na kompontenty. Jeżeli są to komponenty logiczne, a programiści pracują nadal na wspólnym kodzie – to jest dokładnie to, co proponuje LeSS Huge ze swoimi „Area”.

      Jeżeli natomiast chcesz rozbijać architekturę systemu, żeby programiści mogli pracować niezależnie od siebie, to często jest to niezmiernie trudne do wprowadzenia. Zdarza się tak, że zespół rozwija odziedziczony system-monolit i rozbicie tego monolitu na kompontenty to kwestia $$$$$, podczas gdy w budżecie mamy tylko $$. Oczywiście, można argumentować, że ta zmiana przyniesie korzyści w dłuższym okresie – ale firmy w danym momencie po prostu nie stać na to rozbicie…

      Reply
  • 13 kwietnia 2017 at 09:28
    Permalink

    Bardzo fajny artykuł, dzięki :)

    Przy trybie mieszanym – kiedy zespoły realizują projekty z różnych backlogów – dochodzi jeszcze jedna wada: zespoły dev dużo mniej identyfikują się z produktem. Co chwila robią coś innego i stają się mniej chętni do proponowania własnych zmian i wnoszeniu czegoś więcej niż tylko pisanie kodu.

    Reply
  • 30 kwietnia 2017 at 17:20
    Permalink

    Dzięki za art. W sumie dobrze napisane :) Chętnie dowiedziałbym się czegoś więcej o SAFe – jakieś podpowiedzi? :)

    Reply
    • 2 maja 2017 at 07:18
      Permalink

      Pełnym opisem SAFE’a jest strona http://www.scaledagileframework.com/. Twórcy framework’u umieścili wszystko na dużym rysunku i każdy element tego rysunku jest linkiem, który prowadzi do jego opisu.

      Natomiast trochę czasu zajmuje poukładanie sobie w głowie tego, jak wszystkie elementy i trybiki się łączą…

      Poleciłbym też filmik, na którym Henrik i Lars opowiadają o implementacji SAFE’a w LEGO: https://www.youtube.com/watch?v=TolNkqyvieE

      Reply
  • 2 maja 2017 at 08:20
    Permalink

    Ilustracja na stronie SAFe wygląda strasznie ;-) Dzięki za linki :) Staram się poszerzyć wiedzę w temacie skalowania Scruma, więc jeśli coś sprawdzonego Ci jeszcze przyjdzie do głowy to chętnie przytulę dobre linki albo tytuły ;-)

    Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *