Zespoły ciągle czekają na inne zespoły

Seria o pracy zespołowej (2/4). Wcześniej: dostarczamy zbyt wolno mimo zajętości. Następnie: coraz więcej pracy, coraz mniej kończymy.

Wąskie gardło rzadko siedzi w IDE

W małym zespole opóźnienie często oznacza: „trudny problem techniczny” albo „za mało rąk”. W większej organizacji częściej słyszymy: „czekamy na platformę”, „czekamy na compliance”, „czekamy aż drugi release wyjdzie”, „czekamy na decyzję z product foruma”.

Ludzie piszą kod, a system stoi, bo praca nie może przejść dalej bez kogoś innego. Synchronizacja i uzgadnianie zjadają kalendarz. Programowanie bywa najkrótszą częścią lead time’u.

Szerszy kontekst zależności (typy, skutki, praktyki dla PO) jest w zależnościach w pracy zespołu. Tu: jak to wygląda na co dzień i od czego zacząć, zanim narysujecie kolejną mapę zależności na Miro.

Jak wygląda czekanie w praktyce

Typowy przebieg:

1. Zespół A kończy swoją część i ustawia status „blocked”.
2. Zespół B ma własny sprint goal. Wasza zależność nie jest w nim.
3. Za tydzień B „wskoczy” na chwilę, potem wraca do swoich priorytetów.
4. A tymczasem przełącza się na inny temat, żeby „nie siedzieć bezczynnie”.
5. Gdy B wraca, A już nie jest w kontekście. Integracja trwa dłużej niż sama zmiana.

Nikt nie sabotuje. Każdy optymalizuje swój backlog. Firma traci na łącznym czasie dostarczenia.

Inny wariant: zależności są „oficjalnie zarządzane” przez cotygodniowy sync. Sync trwa godzinę, lista zależności rośnie, a odblokowań jest mało. Spotkanie dokumentuje czekanie zamiast je skracać.

Objawy warte nazwania

• w retrospektywach najczęściej wraca „zależności od innych”,
• sprint goal pada, bo jeden zewnętrzny ticket nie wszedł na czas,
• macie rolę „integratora” albo „dependency managera”, bo inaczej nic się nie spina,
• zespoły budują lokalne obejścia (duplikacja logiki, własne API, ciche forki), żeby nie czekać,
• roadmapa zakłada równoległą pracę trzech zespołów „w synchronizacji” - i regularnie się rozjeżdża.

Jeśli to Wasza codzienność, problem nie rozwiąże się kolejnym developerem w zespole A.

Trzy pytania na zależności z ostatniego miesiąca

Wybierzcie 5 rzeczy, które „stały” dłużej niż tydzień:

1. Na kogo konkretnie czekaliście? (zespół, rola, decyzja - nie „na biznes”)
2. Czy ta zależność była znana przed startem pracy? Jeśli nie, macie lukę w przygotowaniu, nie tylko w współpracy.
3. Czy druga strona miała tę zależność w swoim planie z priorytetem? Jeśli nie, czekanie było zaplanowane milcząco.

Zapiszcie odpowiedzi w jednej tabeli. Po godzinie zwykle widać 2-3 powtarzające się węzły (platforma, dane, design, security, „wspólny komponent”). To Wasze realne wąskie gardła organizacyjne.

Co zwykle pomaga

Uczyńcie zależności widocznymi przed startem. Nie jako życzenie w kickoffie, tylko jako warunek wejścia do pracy - blisko Definition of Ready. Jeśli bez API zespołu B nie ruszycie, B powinno wiedzieć o tym zanim A wejdzie w „in progress”.

Mniej równoległych „wspólnych” inicjatyw. Im więcej rzeczy wymaga trzech zespołów naraz, tym więcej czekania. Czasem sensowniej skończyć jedną wspólną rzecz, zanim wystartujecie drugą.

Uzgodnijcie sposób obsługi zależności, nie tylko listę. Na przykład: slot capacity w zespole platformowym na zależności od innych, albo wspólny cel na 2-3 sprinty zamiast trzech osobnych goalów, które się nie stykają.

Mierzcie czas oczekiwania osobno. Mierniki procesu pomagają zobaczyć, ile lead time’u to „working”, a ile „waiting”. Bez tego dyskusja kończy się na wrażeniach.

Ograniczcie WIP na styku zespołów. Widoczność kolejek i limity - praktycznie w Kanbanie - często pokazują, że „czekamy na innych” to objaw przeładowania całego systemu, nie złej woli jednego zespołu.

Sync, który coś odblokowuje

Spotkanie między zespołami ma sens, gdy wychodzicie z konkretną decyzją albo datą odblokowania. Przydatny format na 30 minut:

• lista zależności starszych niż X dni (nie cała historia świata),
• dla każdej: kto odblokowuje, do kiedy, co blokuje po naszej stronie,
• jedna rzecz, którą świadomie odkładacie, żeby zrobić miejsce.

Jeśli po trzech syncach lista tylko rośnie, problem nie jest w częstotliwości spotkań. Jest w capacity albo w tym, że zależności nie mają priorytetu po drugiej stronie.

Czego nie robić

• nie dodawajcie syncu „dla pewności”, jeśli poprzedni sync nie odblokował niczego konkretnego,
• nie karzcie zespołu B za własne priorytety, skoro nikt nie ustalił wspólnego celu dostarczenia,
• nie zakładajcie, że reorganizacja w jeden „superzespół” automatycznie usuwa zależności - czasem tylko przenosi je do środka.

Kiedy to jest większy temat

Jeśli te same węzły wracają kwartał po kwartale, a zespoły uczą się omijać oficjalne kanały, jesteście bliżej problemu modelu współpracy niż „lepszego Jiry”. Wtedy warto też spojrzeć na to, jak startujecie więcej, niż kończycie - bo każde nowe równoległe zobowiązanie mnoży liczbę interfejsów.

Praktyczne warsztaty z przepływem i zależnościami: szkolenia oraz Professional Scrum with Kanban.

Dalej w serii: Coraz więcej pracy, coraz mniej kończymy · Nie umiemy przewidzieć kiedy gotowe