IDEALNY ŚWIAT
W teorii nie ma różnicy między praktyką. Zespół, który nie musi na nikogo czekać – dostarcza szybko. A w życiu? No właśnie?! Zależności to Top Killer produktywności. Jednocześnie, zależności to codzienność w pracy zespołów Scrumowych. Dlaczego tak się dzieje?
Wyobraź sobie sytuację: Twój zespół jest gotowy, user story jest nawet nieźle zdefiniowane, a mimo to – nie ruszacie. Dlaczego? Bo czekacie. Np. na dane, na podbicie wersji API, na DevOps (który jest w innym zespole!?!) za które odpowiedzialny jest inny zespół. Mija tydzień No dobra! Udało się – zależność A odblokowana! Ruszamy! Aaaa jednak nie, gdy my musieliśmy przesunąć swoje prace, inny zespół (żeby nie tracić czasu – bo to nieefektywne) zajął się kolejnymi zadaniami ze swojej kolejki. Głupio, żeby teraz przerywał. Będzie dla nas ponownie dostępny za tydzień – właśnie odkryliśmy zależność B. Brzmi znajomo?
Tak więc zależności mogą być Top Killerem produktywności. Chcielibyśmy je wyeliminować, są jednak sytuacje i decyzje które powodują, że to niemożliwe (przynajmniej na razie albo tak nam się wydaje). Wtedy można (i trzeba!) nimi świadomie zarządzać. I właśnie o tym jest ten artykuł.
TL;DR
Zależności w pracach zespołów produktowych mogą stać się Top Killerem produktywności. Jednocześnie, bardzo często są nieuniknione. Należy je monitorować, zarządzać nimi i usuwać gdy przekroczą próg bólu. Tzn. zależności zawsze bolą, utrudniają i opóźniają – ale nie muszą być 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/ Product Manager.
Omawiamy konkretne praktyki w dwóch sytuacjach: A) gdy organizacja dopiero zaczyna wdrażać zwinność oraz B) 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ół (lub osobę) jest uzależnione od pracy innej osoby, zespołu, systemu lub decyzji. To coś, co musi się wydarzyć gdzieś indziej, zanim my będziemy mogli wykonać swoją część pracy.
W pracy zespołów produktowych zależności mogą być:
⚙️Techniczne – np. dostęp do API, wspólna baza danych, zależność między komponentami.
🎓Kompetencyjne – brak specjalistycznej wiedzy w zespole, konieczność konsultacji (np. z prawnikiem, ekspertem od UX/ DevOps/ Analizy czy innym mistrzem Yoda od systemu ABC).
📝Procesowe – konieczność uzyskania zgody, przejście przez etap akceptacji, zebranie podpisów (np. „poświęcenie” kierunku w którym ma iść rozwój produktu przez Komitet Sterujący Produktów Ważnych i Mniej Ważnych)
🏢Organizacyjne – zależność od innego zespołu, który ma inne priorytety, zmieniające się kierunki strategiczne.
⏳Czasowe – np. jedna funkcjonalność musi zostać zrobiona wcześniej, żeby druga miała sens.
🙋♂️Osobowe – wiedza lub decyzja jest w rękach jednej osoby („kluczowy ekspert”).
I żeby sobie jeszcze bardziej utrudnić, mogą występować kombinacje powyższych.
Nie jesteś pewien jakie zależności ma Twój produkt? Sprawdź tutaj.
SKĄD SIĘ BIORĄ ZALEŻNOŚCI?
Zależności są naturalnym efektem rozwoju, skalowania i specjalizacji w organizacji. Powstają, gdy:
🕰️ funkcjonują historyczne struktury: centralne działy, silosy, „shared services”.
🧩produkt staje się bardziej złożony i wymaga pracy wielu zespołów,
🧠 kompetencje są rozproszone i zespoły muszą się wspierać,
🏗️architektura techniczna wymusza integrację komponentów,
🔀 organizacja pracuje w modelu mieszanym – część zespołów działa zwinnie, część w trybie projektowym.
zmienia się charakter rozwoju produktu – do tej pory produkt miał swoją strukturę raportowania, teraz wysyłamy dane do hurtowni.
DLACZEGO UTRZYMUJEMY ZALEŻNOŚCI?
Zależności bywają tańsze, wygodniejsze lub „dziedziczone” z przeszłości.
Utrzymujemy je, bo:
💸są tańsze krótkoterminowo – np. jeden zespół składający się z 3 DevOpsów zamiast wielu DevOpsa w każdym z 10 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 – zmiana architektury, przeszkolenie zespołu,
🏢centralizacja procesów – jeden zespół zapewnia spójność wykorzystywanego standardu,
👥 ograniczenia ludzkie i zasobów – nie mamy tak wielu programistów mobilnych, więc tworzymy zespół, który realizuje wszystkie prace związane z mobilnymi usługami (dla wielu produktów),
🐢spowolnienie rozwoju – strumień pracy w danym obszarze był niejednostajny, w związku z tym „taniej” było przenieść wsparcie do innego zespołu (który utrzymuje już pewne produkty),
🧾iluzja efektywności realizacji – tematem XYZ zajmują się Ci od D, oni się na tym znają najskuteczniej. I to prawdopodobnie jest prawda, tyle że nie bierze w ten sposób pod uwagę sytuacji gdzie zespoły A,B,C potrzebują w tym samym czasie czegoś związanego z XYZ. Z reguły zespół D nie może obsłużyć tych zgłoszeń na raz. Ktoś będzie musiał więc poczekać.
🧾iluzja pracy jak w parku maszynowym – prace nad produktami wymagają często powrotów (dostajemy feedback, poprawiamy, zmieniamy). Jeśli mamy zależność, to zmiana (np. poprawka w funkcjonalności) wymaga ponownego sięgnięcia do zależności. A Ci raczej nie siedzą i nie piją kawki w tym momencie (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,
🧨 Zwiększa się liczba 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 – bo nie widać sensu pracy.
JAK PRODUCT MANAGER/ OWNER MOŻE POMÓC ZARZĄDZAĆ ZALEŻNOŚCIAMI?
💡Przede wszystkim warto zadać sobie pytanie który zależnościami warto żebyś się zajął jako PO/PM? A co jest a co nie jest Twoja odpowiedzialnością? Zbuduj płaszczyznę współpracy ze Scrum Masterem, Zespołem i Managerami. Pomoże Ci to podzielić ciężar pracy.
💡Jako Product Owner nie musi wszystkiego rozwiązywać sam. Ale musisz mieć świadomość zależności i ich wpływu na wartość.
Dobry PO:
🔎identyfikuje zależności podczas definiowania kierunku dalszych prac, np. poprzez refinement backlogu,
🗺️ wizualizuje je (dependency board, roadmapa, Miro),
📆ustala priorytety i negocjuje kolejność z innymi PO/interesariuszami,
🧮 uwzględnia zależności w planowaniu Sprintów i roadmapy,
🧹szuka sposobów eliminacji zależności (np. przez redesign architektury, wzmocnienie kompetencji w zespole),
🧑🤝🧑współpracuje ze Scrum Masterem, by rozładowywać blokady,
🧑💼oczekuje (wymaga?) by zespół identyfikował zależności na poziomie wytwórczym i nimi aktywnie zarządzał (zgłoszenie Ci: „Hej mamy problem!” – to najsłabszy ze sposobów 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),
✅Ustalaj Definition of Ready dla zadań zależnych (np. „API gotowe”),
📣Zbieraj zgłoszone podczas Daily zależności – czy są rozwiązywane – kto czeka, co się opóźnia – może to powód do eskalacji?
🧾Prowadź zapisy „kto się zobowiązał i do kiedy” – proste, ale działa.
B) GDY WSPÓŁPRACUJESZ Z INNYMI ZESPOŁAMI SCRUMOWYMI
🗺️Wspólna roadmapowanie – tu się wszystko zaczyna, o to wszystko się rozbija,
🧭Organizuj regularny PO Sync – pomaga wyjaśnić problemy, zsynchronizować pracę, zarządzić zależnościami i release’ami,
🎁Najważniejszy jest Przyrost – kieruj swoje działania tak by skracać czas potrzebny do posiadania czegoś działającego (idealnie codziennie),
🧱Pracujcie na wspólnym backlogu nadrzędnym (epiki + podział na zespoły),
🤝Róbcie refinementy międzyzespołowe – dla tematów wspólnych,
🚀Dzielcie się inkrementami – zapraszaj na Sprint Review, chodź na Sprint Review innych zespołów,
🙏Dziękuj za pomoc – doceniaj udzielane wsparcie.
🔓Wprowadź zasadę – najpierw odblokuj – jeśli ktoś czeka na Ciebie, najpierw go odblokuj. W ten sposób wyślesz sygnał że zależności są ważne w dostarczaniu 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. Ustalają plan: backend przygotuje mock API za 5 dni, frontend robi testy lokalne do tego czasu. Na Daily jest raportowany postęp.
Jeśli masz tego typu zależność (co Sprint na coś czekasz) – to jesteś w ogromnych tarapatach! Powyżej opisaliśmy workaround. Szukaj sposobu, który definitywnie rozwiąże problem – połączenie zespołów lub stworzenie dwóch (każdy zawierający kompetencje frontendowe i backendowe).
Przykład 2: 3 zespoły scrumowe – jeden produkt
Trzy zespoły rozwijają nową aplikację. PO organizują wspólny refinement. Tworzą wspólną roadmapę i backlog epików. Co tydzień mają PO sync. Inkrementy są omawiane na wspólnych Sprint Review. Zespoły wymieniają się feedbackiem i testują wzajemnie swoje funkcjonalności.
PODSUMOWANIE
💡Zależności mogą zabić Twój produkt. Chociaż nie wydają się być złe same w sobie. To niezarządzane zależności prowadzą do chaosu, przestojów i frustracji. Product Owner powinien być brokerem zależności – osobą, która je rozumie, prognozuje ich wpływ i wspiera zespół w ich rozwiązywaniu.
Zacznij od prostych pytań: Co możemy zrobić, by choć jedna z tych zależności zniknęła? Od kogo zależymy w tym Sprincie? Kto zależy od nas?
Potem zadaj sobie trudne pytanie: Ile czasu możesz żyć z zależnościami? Co stanie się dostępne jeśli je definitywnie usuniesz? A jak Ty radzisz sobie z top killerem produktywności – zależnościami?
Jeśli podoba Ci się nasz punkt widzenia, chcesz dowiedzieć się więcej i zacząć stosować praktyczne rozwiązania, które pomogą Ci być lepszym PM/PO -> wpadnij na nasze szkolenie Product Management Transformed™
MATERIAŁY DODATKOWE:
O znaczeniu i identyfikacji zależności – LINK
Idea wizualizacji zależności i ich wpływu na realizację projektów – LINK
Teoretyczny fundament dlaczego organizacje utrzymują pewne zależności – LINK
Zespół badaczy identyfikuje 22 mechanizmy koordynacyjne i analizuje je w kontekście zarządzania zależnościami(dependencies) w dużych skalach – LINK