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!