Dostarczamy zbyt wolno mimo że wszyscy są bardzo zajęci

Seria o pracy zespołowej (1/4). Kolejny tekst: zespoły czekają na inne zespoły.

Zajętość vs dostarczanie

Kalendarze pełne. Standupy trwają dłużej niż kiedyś. Backlog rośnie. A klient albo biznes wciąż pyta: „kiedy to będzie?”. Często pada odpowiedź: „jesteśmy zajęci, robimy co możemy”.

Zwykle nie chodzi o lenistwo ani brak talentu. Zaczynacie więcej, niż kończycie. Praca krąży między osobami, zespołami i etapami. Ludzie są zajęci obsługą kolejek. Throughput stoi w miejscu albo spada.

Widzieliśmy to w firmach, które właśnie „zwiększyły capacity”: więcej ludzi, więcej równoległych tematów, dłuższy czas od pomysłu do produkcji. Zajętość poszła w górę. Domknięcia nie.

Gdzie znika czas

Cztery typowe mechanizmy:

Za duże kawałki pracy. Epik, który „trzeba dowieźć w całości”, bo „nie da się podzielić”. W praktyce da się prawie zawsze; niewygodna jest decyzja o podziale. Duży kawałek dłużej stoi w review, dłużej czeka na integrację, dłużej blokuje inne rzeczy.

Za dużo rzeczy naraz. Każdy ma trzy „priorytety”. Kontekst switching zjada dzień. Statusy wyglądają na zielone, bo „ktoś nad tym pracuje”, ale nic nie dochodzi do Definition of Done.

Zależności i kolejki. Czekacie na API, na design, na security, na release train. Więcej o tym w zależnościach w pracy zespołu. Tu wystarczy zauważyć, że czas oczekiwania rzadko widać w burndownie.

Praca, która wraca. „Prawie gotowe” wraca z testów, z UAT, z code review z listą uwag. Każdy powrót to kolejka od nowa. Bez jasnego Definition of Done i Ready ten cykl się powtarza.

Objawy, które warto nazwać

Sprawdź, czy brzmi znajomo:

ludzie pracują po godzinach, a liczba rzeczy w „Done” w miesiącu nie rośnie,
w sprintcie startujecie 12 rzeczy, kończycie 4-5,
status „in progress” ma więcej kart niż „ready” i „done” razem,
ten sam temat jest „na 80%” przez trzy tygodnie,
spotkania statusowe trwają dłużej niż praca nad odblokowaniem.

Jeśli większość z tego pasuje, macie problem z przepływem, nie z motywacją.

Krótki test na jednym temacie

Weź jedną inicjatywę z ostatnich 6-8 tygodni (wybraną losowo, nie „najładniejszą”). Zapisz:

Kiedy zaczęliście pracę? (pierwszy commit, pierwsze zadanie, pierwsze spotkanie kickoff: wybierzcie jedną definicję i trzymajcie się jej)
Kiedy poszło na produkcję / do użytkownika?
Ile dni faktycznej pracy vs ile dni kalendarzowych?
Gdzie staliście najdłużej? (review, zależność, decyzja, testy, „czekamy na slot”)

Jeśli czas kalendarzowy jest kilka razy dłuższy niż czas pracy, wąskie gardło siedzi w oczekiwaniu i przełączaniu, nie w pisaniu kodu.

Powtórz dla trzech tematów. Szukasz wzorca, nie anegdoty.

Co zwykle pomaga (zanim kupicie kolejne narzędzie)

Zacznijcie od dźwigni, które widać w tydzień:

Ograniczcie pracę w toku. Mniej równoległych inicjatyw na poziomie zespołu i obszaru. Kanban to nie tylko tablica: limity WIP i widoczność kolejek opisujemy w Kanban to nie tylko kartki.

Dzielcie na mniejsze, kończalne kawałki. Cel: coś da się zintegrować i sprawdzić w dniach, nie w miesiącach. Jeśli „nie da się podzielić”, często brakuje decyzji produktowej, nie technicznej.

Policzcie starty i domknięcia. Ile rzeczy weszło w „in progress” w tym miesiącu, ile wyszło na produkcję. Gdy startów jest wyraźnie więcej, system się zapycha, nawet jeśli wszyscy wyglądają na zajętych.

Skróćcie pętlę feedbacku. Review i testy w tym samym cyklu co rozwój, nie „na końcu”. Im dłużej coś czeka na sprawdzenie, tym drożej wraca.

Mierniki procesu (lead time, throughput, aging) pomagają odróżnić „dużo ruchu” od „rzeczy dochodzą do końca”. Nie musicie od razu budować dashboardu dla całej firmy. Wystarczy jeden zespół i kilka tygodni uczciwych danych.

Czego unikać

dokładania ludzi do zapchanego systemu bez ograniczenia WIP (zwykle zwiększa chaos),
kolejnego status meetingu zamiast odblokowania konkretnej zależności,
„przyspieszania” przez równoległe startowanie jeszcze większej liczby tematów.

Zajętość jest tania w raportowaniu. Domknięcie kosztuje dyscyplinę: mniej naraz, mniejsze kawałki, mniej czekania.

Kiedy iść dalej

Jeśli ograniczyliście WIP i nadal większość czasu znika na interfejsach między zespołami, temat przesuwa się z „jak pracujemy w zespole” na „jak zespoły na siebie czekają”. O tym jest drugi tekst z serii.

Jeśli chcecie przećwiczyć zarządzanie przepływem w praktyce, warto zajrzeć na szkolenia, w szczególności Professional Scrum with Kanban, gdzie WIP, kolejki i lead time przestają być teoriami z slajdu.

Dalej w serii: Zespoły czekają na inne zespoły · Coraz więcej pracy, coraz mniej kończymy · Nie umiemy przewidzieć kiedy gotowe