Wielozespołowy Product Backlog Refinement w praktyce

A zatem, najważniejszy temat w produkcie stoi. Siedem zespołów patrzy. Nikt z nich nie może przejąć tematu, bo nie uczestniczyli w jego refinemencie. Nikt nie rozumie kontekstu. Nikt nie zna ustaleń. Temat jest de facto zakładnikiem jednego zespołu.

Nie masz wyboru, temat musi poczekać, a 7 innych zespołów dowiezie coś jest mniej ważne. Z perspektywy lidera produktu jest to sytuacja niedopuszczalna. Nie ma nic gorszego niż efektywne wykonywanie niepriorytetowej pracy.

Brzmi znajomo? Bo to jest codzienność większości organizacji wielozespołowych. I to jest problem, który łatwo można rozwiązać, choć początkowo może się to wydawać mało intuicyjne.

Najpierw: o co tak naprawdę chodzi

Zanim przejdę do mechaniki, zatrzymajmy się na chwilę przy modelu mentalnym, bo to on jest prawdziwym bohaterem tej historii ;-)

W klasycznym podejściu każdy zespół ma „swój kawałek", lub "swoje tematy". To powoduje "swoje refinementy". Zespoły są zoptymalizowane pod efektywność zespołu, czyli to, że każdy zespół zna swoje tematy i dowozi je sprawnie. Managerowie są szczęśliwi. Wszystko wygląda produktywnie.

Tyle że organizacja nie potrzebuje, żeby każdy zespół był efektywny w dowożeniu swoich tematów. Organizacja potrzebuje, żeby jako całość dostarczać maksymalną wartość. A to (uwaga, spoiler) nie jest to samo.

Kiedy każdy zespół pilnuje „swoich tematów", tracisz adaptacyjność organizacyjną. Nie jesteś w stanie skierować sił zespołowych na to, co globalnie jest teraz najważniejsze. Bo jedyny zespół, który zna temat, jest akurat zajęty. A pozostałe, choć mają wolne moce, nie mogą pomóc, bo nic o tym temacie nie wiedzą. Stoją z założonymi rękami jak kibice na meczu. Widzą piłkę, ale nie mogą wejść na boisko. Więc zajmą się "efektywnym" dowożeniem własnych, mniej ważnych tematów... co za ironia.

Adaptacyjność organizacyjna to coś zupełnie innego. To sytuacja, w której grupa zespołów jest świadoma celów i działań oraz współpracuje, by je wspólnie osiągnąć. Nie zamyka się na „własny temat do dowiezienia" i jest gotowa na przełączenie się na dowolny temat, aby wszystkie zespoły zawsze pracowały na top priorytetach z perspektywy globalnej. Dzięki temu organizacja dowozi maksymalną globalnie wartość, a nie ficzery, nie lokalnie ważne rozwiązania.

I ta zmiana myślenia ma bezpośrednią konsekwencję w tym, jak robimy Product Backlog Refinement.

Skąd biorą się tematy do refinementu

W G2A pracujemy na Opportunity Solution Tree. Pierwszym elementem drzewa jest Product Outcome, czyli zachowanie użytkownika, jakie chcemy wygenerować. Zadajemy sobie pytanie: „Dlaczego użytkownicy się tak nie zachowują?" I w trakcie strategicznego researchu odkrywamy tzw. Opportunities, czyli problemy i szanse, jakimi chcemy, aby zajęły się zespoły.

Powstaje w ten sposób roadmapa szans. Nie roadmapa ficzerów. Roadmapa problemów do rozwiązania. To ważne rozróżnienie, bo zmienia charakter refinementu, na którym nie tylko rozmawiamy o tym „co zbudować", tylko o tym „jaki problem rozwiązać i jak najlepiej to zrobić".

No i teraz pojawia się kluczowe pytanie: jak te szanse refinować, gdy masz wiele zespołów współtworzących jeden duży produkt?

Problem z klasycznym refinementem

Gdy masz jeden zespół, to jest łatwo. Każda szansa jest omówiona w zespole, wypracowywane są rozwiązania i hipotezy do zweryfikowania. Klasyczny Refinement jak w Scrumie. Nic nowego.

Ale co, gdy masz wiele zespołów?

Gdyby refinement był robiony przez jeden konkretny zespół, to tylko ten zespół miałby wiedzę o temacie. Co naturalnie prowadziłoby do tego, że ten zespół na kolejnym Sprint Planningu chciałby wziąć ten temat do realizacji. Bo go zna. Bo włożył wysiłek w zrozumienie. Bo czuje się „właścicielem".

Brzmi logicznie, prawda? No to zobaczmy, dokąd ta logika prowadzi:

System wygląda efektywnie (każdy refinuje „swoje"), ale jest kruchy jak domek z kart. Wystarczy jedna przeszkoda w jednym zespole, żeby najważniejszy temat w całym produkcie stanął w miejscu. A 7 pozostałych zespołów? Dowozi swoje mniej ważne tematy. Bo te akurat znają.

Gratulacje - masz 8 efektywnych zespołów i nieefektywną organizację. Wszyscy sprawnie dowożą niewiele wartości.

"Ale Krzysiek, precież jak by zespoły tak się ciągle na coś innego przełączały, to byłyby nieefektywne. Dostarczyłyby mniej rozwiązań, bo context-switching, cognitive-load, ..."

Prawdziwe pytanie brzmi:

Czy lepiej dostarczyć jedną sztabkę złota, czy 100 sztabek miedzi?

W organizacjach produktowych dostarczamy wartość. Użytkownicy płacą nam za wartościowy produkt, a nie za to, że developerzy są utylizowani w 100%-ach... i dostarczają to co mogą, a nie to co powinni.

Efektywność w produktowym kontekście byłaby zdolnoscią wielu zespołów do łatwego, bezkosztowego przełączania się między tematami. To wymagałoby znalezienia praktyk obniżających cognitive-load, ale nie poprzez oddzielenie zespołów od wiedzy, ale wręcz odrwotnie - wypracowanie bardziej efektywnych technik przekazywania wiedzy.

Rozwiązanie: Refinement w grupach mieszanych

W G2A robimy refinement inaczej. Mieszamy ludzi z różnych zespołów (what?!). Co tydzień. ok. 70 osób w mieszanych grupach znajduje najlepsze możliwe rozwiązania. I zanim pomyślisz „to musi być totalny chaos", przeczytaj dalej, bo jest to zaskakująco prosty w przeprowadzeniu sposób.

Krok 1: Pusta tabela (przed spotkaniem)

Przygotowujemy prostą tabelę z kilkoma pokojami (kolumny) i dwoma slotami czasowymi (wiersze). Każdy slot trwa 1,5 godziny. Na starcie tabela jest pusta. Będziemy uzupełniać ją tematami do rafinacji w pierwszym etapie spotkania.

Krok 2: Pitch - 15-20 minut, wszyscy razem

Na początku spotykamy się wszyscy w jednym miejscu. Osoby, które mają tematy do refinementu, kolejno je „pitchują". Każdy pitch trwa 1–2 minuty. Mówisz:

• O jaki problem lub szansę chodzi.

• Czego potrzebujesz od grupy (analiza potrzeby? wymyślenie rozwiązania? kryteria akceptacji?).

• Jakiej wiedzy szukasz w pokoju („przyda się ktoś, kto zna nasz system płatności" albo „potrzebuję kogoś z frontendu").

Temat po pitchu trafia do konkretnego slotu i pokoju. Po 15–20 minutach tabela jest wypełniona i wszyscy wiedzą co, gdzie i kiedy.

Krok 3: Ludzie idą tam, gdzie uważają, że powinni

Ogłaszamy start i tu zaczyna się najlepsza część.

Ludzie (tak, developerzy to też ludzie) sami decydują, do którego pokoju idą. Nikt nie przydziela. Nikt nie wysyła zaproszeń w kalendarzu z podziałem na pokoje. Część osób idzie, bo ma wiedzę potrzebną do omówienia tematu. Część idzie, bo chce się czegoś nauczyć. Część idzie, bo widzi, że temat dotyczy obszaru, w którym ich zespół może niedługo pracować.

Efekt? W każdym pokoju siedzi mieszana grupa - ludzie z różnych zespołów, z różnymi kompetencjami i perspektywami. Dokładnie tak, jak chcemy.

Krok 4: Właściwy refinement - 2 × 1,5 godziny

Każda grupa pracuje wspólnie nad tematem. W zależności od jego dojrzałości mogą: wyciągnąć potrzeby od osoby pitchującej, spisać kryteria akceptacji, wymyślić rozwiązanie, zidentyfikować ryzyka, podzielić duży temat na mniejsze kawałki.

Efektem jest uszczegółowiona potrzeba wraz z listą rzeczy do zrobienia. Wszystko spisane: notatki, ustalenia, kryteria. Dokumentacja po-refinementowa. Nie literatura piękna, ale wystarczająca, żeby ktoś, kto nie był w pokoju, mógł zrozumieć o co chodzi i co trzeba zrobić.

Po 1,5 godziny - zmiana tematu zgodnie z tabelą (no chyba, że ktoś zajął jednym tematem oba sloty - co jest dopuszczalne). Ludzie przechodzą do pokojów z drugiego slotu. Nowa grupa, nowy temat.

Co się dzieje potem: Sprint Planning

I tu się dzieje to, po co to wszystko robimy.

Dzięki mieszaniu zespołów wiedza o każdym itemie jest rozproszona w wielu zespołach. Dokumentacja jest spisana. Na Sprint Planningu wiele zespołów może zgłosić się do realizacji danego itemu. Nie tylko ten jeden, który „zawsze robił ten obszar".

Gdy na Sprint Planningu jakiś zespół wybierze PBI (Product Backlog Item) do realizacji, osoba z tego zespołu, która była na refinemencie, wprowadza resztę w temat. Ponadto zespół będzie pracował bezpośrednio z osobą pitchującą - userem, SME, reprezentantem biznesu, więc wszelkie wątpliwości są w stanie do-ustalić na Planingu lub w trakcie realizacji.

I tu dzieje się magia: bardzo często dany temat jest realizowany przez kilka zespołów wspólnie. Przykładowo, 2–3 zespoły biorą PBI, robią wspólny Sprint Planning i wychodzą z niego z własnymi Sprint Backlogami (planem współpracy w Sprincie). W trakcie Sprintu silnie współpracują nad wspólnym sukcesem. Nie dlatego, że ktoś im kazał. Dlatego, że rozumieją temat i widzą sens tej współpracy.

To przyspiesza naukę, decentralizuje wiedzę, uwalnia kreatywność, uspójnia działania, eliminuje dodatkowe spotkania 'alignmentowe', wzmacnia współpracę itd.

Przed i po

„Ale to nieproduktywne, że ludzie chodzą i uczą się o tematach, których nie będą robić"

Wiem, wiem. To jest zawsze pierwszy komentarz. Słyszę go na każdym szkoleniu, na każdej konferencji, w każdej firmie.

50–70 osób na jednym spotkaniu? Ludzie chodzą po pokojach i słuchają o tematach, które nie są „ich"? Ile to kosztuje roboczogodzin? Manager gdzieś w tle już otwiera kalkulator.

Dobra, to ja też otworzę kalkulator. Ile kosztuje sytuacja, w której najważniejszy temat w produkcie stoi tydzień, dwa, trzy, bo jedyny zespół, który go zna, jest zajęty czymś innym? A pozostałe 7 zespołów w tym czasie dowozi tematy, które nie mają nawet połowy tego impaktu?

Mieszanie ludzi na refinemencie to inwestycja. Inwestycja w poszerzenie kontekstu. W to, żeby z programistów klepających kod wyrosli współtwórcy najlepszych możliwych rozwiązań dających maksymalny impakt biznesowy.

Bo gdy developer rozumie problem użytkownika, zna kontekst biznesowy i widział dyskusję o różnych opcjach rozwiązania, to proponuje lepsze rozwiązania techniczne. Nie implementuje to, co mu kazano. Współtworzy to, co ma największy sens.

To jest różnica między organizacją, która dowozi ficzery, a organizacją, która dowozi wartość. Tak właśnie mamy w G2A.

Jak zacząć - nie musisz mieć 8 zespołów

Jeśli chcesz to wypróbować, nie musisz od razu mieszać 50 osób. Serio. Zacznij na małą skalę.

1. Weź 2–3 zespoły. Wybierz takie, które pracują nad tym samym produktem, bliskimi obszarami, lub współdzielą technologię. Zaproponuj wspólny refinement 1-2 razy na Sprint.

2. Przygotuj tabelę z pokojami i slotami. Na start wystarczą 2-3 pokoje i 1 slot po 1,5 godziny. Plus 15 minut na pitchowanie. Razem niecałe 2 godziny.

3. Naucz ludzi pitchować. 1–2 minuty: jaki problem, czego potrzebuję od grupy, jakiej wiedzy szukam. Bez prezentacji. Bez slajdów. Bez „pozwólcie, że opowiem Wam historię tego epica od 2019 roku...".

4. Pozwól ludziom wybrać pokój. Nie przydzielaj. Powiedz: „Idźcie tam, gdzie uważacie, że powinniście być." Zaufaj, że dorośli ludzie podejmą dobrą decyzję. (Spoiler: podejmują.)

5. Zadbaj o dokumentację. Efekt każdego pokoju musi być spisany. Bez tego cały sens mieszania leci na marne, bo wiedza zostaje tylko w głowach osób, które były w pokoju, i umiera wraz z pierwszym długim weekendem.

Po kilku tygodniach zobaczysz efekt: na Sprint Planningu więcej zespołów będzie mogło podjąć się realizacji tematów. Kolejki zaczną się skracać. Współpraca zacznie się pojawiać naturalnie i to nie dlatego, że ktoś wpisał ją w OKR-y, tylko dlatego, że ludzie znają tematy i chcą pomagać.

Podsumujmy całość

Wróćmy do scenariusza z początku.

8 zespołów. Najważniejszy temat w produkcie. Zespół, który go znał, jest akurat zajęty.

W klasycznym modelu: temat stoi. Siedem zespołów nie może pomóc. Manager pisze eskalację. Ktoś proponuje „spotkanie synchronizacyjne". Czas płynie, a Top 1 priorytet stoi.

W mieszanych refinementach: na refinemencie w pokoju z danym tematem przyszli ludzie z kilku różnych zespołów. Dokumentacja została spisana. Dwa zespoły zgłaszają się na Sprint Planningu. Jeden bierze temat i rusza od pierwszego dnia Sprintu. Zero czekania.

Organizacja pracuje nad tym, co ma największy impakt.

Też tak chcesz? Zacznij od jednego pytania:

„Ile zespołów w mojej organizacji mogłoby jutro przejąć najważniejszy temat, który znajduje się na 1-szym miejscu w globalnym Product Backlogu?"

Jeśli odpowiedź brzmi „jeden", to wiesz już, co zmienić.

Masz pytania? Umów się ze mną na niezobowiązującą konsultację.