Mamy coraz więcej pracy, ale coraz mniej kończymy

Seria o pracy zespołowej (3/4). Wcześniej: zespoły czekają na inne zespoły. Następnie: nie umiemy przewidzieć kiedy gotowe.

Start jest tani. Finish kosztuje

Nowa inicjatywa łatwo wchodzi na roadmapę: slide, decyzja, kickoff, ticket w Jirze, kanał na Slacku. Domknięcie wymaga integracji, testów, decyzji o scope, negocjacji zależności, czasem też odwagi, żeby coś odciąć.

Dlatego w wielu organizacjach przybywa rozpoczętych rzeczy, a ubywa skończonych. Ludzie czują przeciążenie. Backlog puchnie. Lista „w toku” wygląda jak muzeum niedokończonych obietnic.

TL;DR

• Rozpoczęcie inicjatywy jest tanie. Domknięcie wymaga integracji, testów, decyzji i kilku ról naraz.
• Typowe przyczyny: nagradzanie startu, brak limitu równoległości, zmiana priorytetów w trakcie i role potrzebne do domknięcia spoza planu.
• Test: policzcie starty i domknięcia z ostatnich 30-60 dni.
• Pomaga limit inicjatyw na poziomie obszaru, jawne zabijanie tematów, DoD obejmujące finish i zasada „najpierw domknij, potem startuj”.

Co widzimy w organizacjach

Widzieliśmy zespoły, które w kwartale wystartowały kilkanaście tematów „strategicznych”, a na produkcję wyszły dwa, i to nie te, które startowały z największą fanfarą. Reszta wisiała w „prawie”, „czekamy”, „wrócimy w następnym PI”.

Dlaczego tak się dzieje

Nagradzanie startu. Kickoff wygląda na postęp. Release wygląda na ryzyko. Liderzy chcą pokazać ruch. System uczy się zaczynać.

Brak limitu równoległości. „Weźmiemy jeszcze ten mały temat” wydaje się niewinne. Po miesiącu macie piętnaście małych tematów i zero dużych domknięć.

Zmiana priorytetów w trakcie. Nowy temat wchodzi „na górę”. Stary nie jest oficjalnie zabity, tylko cicho stoi. Capacity jest zajęte obsługą przełączeń.

Domknięcie wymaga więcej ról naraz. Start często robi jeden zespół. Finish wymaga QA, ops, prawnego, marketingu, migracji danych. Jeśli te role nie są w planie od początku, finish staje się niespodzianką.

To łączy się z zajętością bez throughputu i z czekaniem na inne zespoły. Zapchany system generuje obie rzeczy naraz.

Objawy

• roadmapa ma więcej pozycji „in progress” niż „done” w horyzoncie kwartału,
• na retrospektywie regularnie pada „za dużo tematów naraz”,
• nikt nie umie wskazać trzech rzeczy, które skończyliście w zeszłym miesiącu bez zaglądania do Jiry,
• tematy wracają po „pauzie” w gorszym stanie niż gdy je odkładaliście,
• Definition of Done jest formalnie, ale w praktyce „done” znaczy „dev finished”.

Jeśli to brzmi znajomo, problemem jest zdolność do domykania.

Test: starty vs domknięcia

Weźcie jeden obszar (jeden produkt, jedna jednostka) i policzcie za ostatnie 30-60 dni:

Jeśli startów jest wyraźnie więcej niż domknięć + zabitych, system się zapycha. Pauza bez decyzji to też forma długu: zajmuje uwagę i miejsce w planach.

Dołóżcie mierniki procesu: aging WIP szybko pokazuje, które rzeczy gniją w „in progress”. Throughput mówi, ile naprawdę kończycie, niezależnie od tego, jak optymistyczna jest roadmapa.

Co zwykle pomaga

Limit równoległych inicjatyw na poziomie obszaru. Poza WIP w zespole developerskim potrzebny jest limit na to, ile dużych tematów jednocześnie prowadzi product i leadership. Reszta czeka w kolejce wejściowej i nie udaje, że jest w toku.

Jawne zabijanie tematów. Jeśli coś nie wraca w tym kwartale, zamknijcie albo odłóżcie oficjalnie. Cisza wokół niedokończonego tematu kosztuje więcej niż trudna rozmowa.

Definition of Done, które obejmuje finish. Zmergowany kod to jeszcze nie koniec. Done obejmuje wszystko, co naprawdę kończy wartość, zgodnie z tym, jak opisujemy DoD i DoR.

Polityka: najpierw odblokuj i domknij, potem startuj. Brzmi banalnie. W praktyce wymaga, żeby ktoś miał mandat powiedzieć „nie” nowemu kickoffowi, dopóki kolejka aging nie spadnie.

Widoczność kolejek. Kanban i WIP pomagają zobaczyć, że „więcej pracy” to często po prostu dłuższe kolejki.

Pułapka „jeszcze jeden sprint i domkniemy”

Częsty rytuał: zostawiacie niedokończone rzeczy „na dokończenie w następnym sprincie”, a jednocześnie bierzecie nowe zobowiązania. Po trzech cyklach macie warstwę zaległości i świeży zestaw obietnic.

Lepsze pytanie na planningu: ile domknięć realistycznie zmieścimy, jeśli najpierw obsłużymy to, co już stoi? Dopiero potem: co wolno wystartować.

Rozróżnijcie też dwa rodzaje „więcej pracy”:

• więcej wejścia - nowe pomysły, tickety, inicjatywy z biznesu,
• więcej niedokończenia - te same tematy krążą, wracają z UAT, stoją na zależnościach.

Pierwsze leczy się kolejką i selekcją. Drugie: limitem WIP, DoD i odblokowywaniem. Mylenie ich prowadzi do odruchu „weźmy więcej ludzi”, gdy trzeba najpierw skończyć to, co już wisi.

Kiedy estymacje zaczynają kłamać

Gdy system jest zapchany, daty „kiedy skończymy” stają się loterią, nie dlatego, że ludzie źle szacują story pointy, tylko dlatego, że priorytety i zależności skaczą. O tym jest czwarty tekst z serii.

Jeśli chcecie przećwiczyć zarządzanie przepływem i limitami w praktyce: szkolenia oraz Professional Scrum with Kanban.

Dalej w serii: Nie umiemy przewidzieć kiedy gotowe · Start serii: Dostarczamy zbyt wolno mimo zajętości