Zależności w pracy zespołu

IDEALNY ŚWIAT

W teorii nie ma różnicy między teorią a praktyką. Zespół, który na nikogo nie czeka, dowozi szybko. A w życiu? No właśnie. Zależności to top killer produktywności i jednocześnie codzienność w pracy zespołów scrumowych. Dlaczego tak jest?

Wyobraź sobie: zespół gotowy, user story nawet nieźle zdefiniowane, a mimo to nie ruszacie. Bo czekacie. Na dane. Na podbicie wersji API. Na DevOpsa, który siedzi w innym zespole. Mija tydzień. No dobra, zależność A odblokowana. Ruszamy. Albo i nie: kiedy wy musieliście przesunąć swoje prace, tamten zespół (żeby nie tracić czasu) wziął kolejne zadania ze swojej kolejki. Głupio teraz przerywać. Będą dla was wolni za tydzień. Właśnie odkryliście zależność B. Brzmi znajomo?

Chcielibyśmy zależności wyeliminować. Często się nie da, przynajmniej na razie, albo tak nam się wydaje. Wtedy trzeba nimi świadomie zarządzać. O tym jest ten tekst.

TL;DR

Zależności w zespołach produktowych bywają top killerem produktywności. Często są też nieuniknione. Trzeba je monitorować, zarządzać nimi i usuwać, kiedy przekroczą próg bólu. Zawsze bolą, utrudniają i opóźniają, ale nie muszą paraliżować.

Z artykułu dowiesz się, jakie są typy zależności, skąd się biorą, jak wpływają na wartość produktu i co może z nimi zrobić Product Owner albo Product Manager.

Omówimy praktyki w dwóch sytuacjach: gdy organizacja dopiero wdraża zwinność oraz gdy zespół współpracuje z innymi zespołami scrumowymi.

CO TO SĄ ZALEŻNOŚCI?

Zależność to sytuacja, w której wykonanie pracy przez jeden zespół albo osobę zależy od pracy innej osoby, zespołu, systemu albo decyzji. Coś musi wydarzyć się gdzieś indziej, zanim my zrobimy swoją część.

W pracy zespołów produktowych zależności bywają:

Techniczne - dostęp do API, wspólna baza, zależność między komponentami.
Kompetencyjne - brak specjalisty w zespole, konsultacje z prawnikiem, UX, DevOpsem, analitykiem albo „mistrzem Yoda” od systemu ABC.
Procesowe - zgoda, akceptacja, podpisy (na przykład „poświęcenie” kierunku produktu przez Komitet Sterujący Produktów Ważnych i Mniej Ważnych).
Organizacyjne - inny zespół ma inne priorytety albo zmienia się strategia.
Czasowe - jedna funkcjonalność musi powstać wcześniej, żeby druga miała sens.
Osobowe - wiedza albo decyzja siedzi u jednej osoby (kluczowy ekspert).

Żeby było trudniej, często występują w kombinacjach.

Nie jesteś pewien, jakie zależności ma Twój produkt? Sprawdź listę kontrolną.

SKĄD SIĘ BIORĄ ZALEŻNOŚCI?

Zależności są naturalnym efektem rozwoju, skalowania i specjalizacji. Powstają, gdy:

żyją historyczne struktury: centralne działy, silosy, shared services;
produkt robi się bardziej złożony i wymaga wielu zespołów;
kompetencje są rozproszone i zespoły muszą się wspierać;
architektura wymusza integrację komponentów;
organizacja jest mieszana: część zespołów działa zwinnie, część projektowo;
zmienia się charakter rozwoju produktu - kiedyś produkt miał własną strukturę raportowania, teraz dane lecą do hurtowni.

DLACZEGO UTRZYMUJEMY ZALEŻNOŚCI?

Bywają tańsze, wygodniejsze albo odziedziczone. Trzymamy je, bo:

są tańsze krótkoterminowo - jeden zespół z trzema DevOpsami zamiast DevOpsa w każdym z dziesięciu zespołów;
tak się zawsze robiło - brak impulsu do zmiany struktury;
dają iluzję kontroli - „to u architektów, oni ogarną”;
zmiana wymaga odwagi i inwestycji - architektura, przeszkolenie zespołu;
centralizacja procesów - jeden zespół pilnuje standardu;
ograniczenia ludzi i zasobów - mało programistów mobilnych, więc jeden zespół robi mobilne dla wielu produktów;
strumień pracy był nierówny - „taniej” wynieść wsparcie do zespołu, który już coś utrzymuje;
iluzja efektywności - tematem XYZ zajmują się „ci od D”, bo znają się najlepiej. Często to prawda. Nie bierze jednak pod uwagę, że zespoły A, B i C potrzebują XYZ w tym samym momencie. Zespół D nie ogarnie wszystkiego naraz. Ktoś poczeka;
iluzja parku maszynowego - produkty wymagają powrotów: feedback, poprawka, zmiana. Przy zależności każda poprawka znów idzie do tamtego zespołu. Oni akurat nie piją kawki. Realizują inne zlecenie. Więc czekasz.

DLACZEGO ZALEŻNOŚCI TO TOP KILLER PRODUKTYWNOŚCI?

Spada przewidywalność - nie wiadomo, kiedy coś naprawdę będzie gotowe.
Rośnie liczba przestojów i przerywania pracy.
Więcej eskalacji i gaszenia pożarów.
Zespół traci autonomię - staje się wykonawcą cudzych decyzji.
Feedback od klienta przychodzi za późno, bo inkrement nie działa samodzielnie.
Spada motywacja - trudno zobaczyć sens pracy.

JAK PRODUCT MANAGER / OWNER MOŻE POMÓC ZARZĄDZAĆ ZALEŻNOŚCIAMI?

Najpierw pytanie: którymi zależnościami warto, żebyś zajął się Ty jako PO albo PM? A co nie jest Twoją odpowiedzialnością? Ułóż współpracę ze Scrum Masterem albo facylitatorem, z zespołem i z managerami. Łatwiej podzielić ciężar.

Jako Product Owner nie musisz wszystkiego rozwiązywać sam. Musisz jednak widzieć zależności i ich wpływ na wartość.

Dobry PO:

identyfikuje zależności przy wyznaczaniu kierunku prac, na przykład na refinementcie backlogu;
wizualizuje je (dependency board, roadmapa, Miro);
ustala priorytety i negocjuje kolejność z innymi PO oraz interesariuszami;
uwzględnia zależności w planowaniu sprintów i roadmapy;
szuka sposobów eliminacji (redesign architektury, wzmocnienie kompetencji w zespole);
współpracuje ze Scrum Masterem albo facylitatorem, żeby rozładowywać blokady;
oczekuje, że zespół sam wyłapuje zależności na poziomie wytwórczym i nimi zarządza. Zgłoszenie „Hej, mamy problem!” to najsłabsza forma zarządzania.

A) GDY ORGANIZACJA DOPIERO ZACZYNA ZE ZWINNOŚCIĄ

Prowadź mapę zależności z nazwiskami i datami.
Uzgadniaj zależności na warsztatach planowania, nawet kwartalnych.
Ustal Definition of Ready dla zadań zależnych, na przykład „API gotowe”.
Na Daily zbieraj zgłoszone zależności: czy są rozwiązywane, kto czeka, co się opóźnia. Może to powód do eskalacji.
Notuj, kto się zobowiązał i do kiedy. Proste, a działa.

B) GDY WSPÓŁPRACUJESZ Z INNYMI ZESPOŁAMI SCRUMOWYMI

Wspólne roadmapowanie - tu się wszystko zaczyna i o to wszystko się rozbija.
Regularny PO Sync: problemy, synchronizacja pracy, zależności, release’e.
Najważniejszy jest przyrost. Skracaj czas do czegoś działającego. Idealnie codziennie.
Wspólny backlog nadrzędny (epiki i podział na zespoły).
Refinementy międzyzespołowe dla tematów wspólnych.
Dzielcie się inkrementami: zapraszaj na Sprint Review, chodź na Review innych.
Dziękuj za pomoc. Doceniaj wsparcie.
Zasada „najpierw odblokuj”: jeśli ktoś czeka na Ciebie, najpierw jego. W ten sposób widać, że zależności mają znaczenie przy dowożeniu wartości.

PRZYKŁADY

Przykład 1: czekamy na backend

Frontend nie może testować, bo backend nie wystawia danych. PO organizuje spotkanie z PO backendu i architektem. Plan: backend przygotuje mock API w pięć dni, frontend robi testy lokalne do tego czasu. Na Daily raportują postęp.

Jeśli taka zależność wraca co sprint, jesteś w tarapatach. Powyżej to tylko workaround. Szukaj rozwiązania na stałe: połączenie zespołów albo dwa zespoły, każdy z kompetencjami frontendowymi i backendowymi.

Przykład 2: trzy zespoły, jeden produkt

Trzy zespoły rozwijają nową aplikację. PO robią wspólny refinement, wspólną roadmapę i backlog epików. Co tydzień mają PO Sync. Inkrementy omawiają na wspólnych Sprint Review. Wymieniają się feedbackiem i testują nawzajem swoje funkcjonalności.

PODSUMOWANIE

Zależności same w sobie nie muszą być złe. Zabija produkt brak zarządzania nimi: chaos, przestoje, frustracja. Product Owner powinien być brokerem zależności - rozumieć je, przewidywać wpływ i wspierać zespół w ich rozwiązywaniu.

Zacznij od prostych pytań: Co możemy zrobić, żeby choć jedna zależność zniknęła? Od kogo zależymy w tym sprincie? Kto zależy od nas?

Potem trudniejsze: Ile czasu możesz żyć z zależnościami? Co odzyskacie, jeśli je ostatecznie usuniecie? A jak Ty radzisz sobie z top killerem produktywności, czyli zależnościami?

Jeśli ten punkt widzenia Ci pasuje i chcesz praktycznych rozwiązań dla roli PM/PO, wpadnij na Product Management Transformed™.

Materiały dodatkowe