Odcinek 80. Co jeśli to (nie) rozmiar zadania ma znaczenie?

W świecie zwinnego zarządzania pracą pytanie o znaczenie rozmiaru zadania wraca jak bumerang. Czy większe zadania zawsze trwają dłużej? Czy cycle time rośnie proporcjonalnie do story pointów? A może wpływają na to zupełnie inne czynniki? Innymi słowy: czy rozmiar zadania ma znaczenie?

W tym artykule dzielę się refleksjami z rozmowy z Justyną „Kęsik” Rędzińską, Scrum Masterką i Agile Coachką. Wspólnie przyjrzeliśmy się pułapkom związanym z mierzeniem pracy, wizualizacją danych i wyciąganiem wniosków, które mogą mieć realny wpływ na sposób, w jaki pracują zespoły i podejmują decyzje menedżerowie.

Jak to się zaczęło?

Ta historia zaczęła się trochę przypadkiem, a trochę z potrzeby. Justyna i ja od dawna próbowaliśmy się umówić na rozmowę, ale dopiero spotkanie na konferencji Scrum Summit sprawiło, że temat wrócił. Inspiracją był wpis Justyny na Slacku Agile Coach Campu, gdzie zadała pytanie o sens rozdzielania danych na rodzaje pracy: bugi, incydenty, zadania deweloperskie. Jej przełożony chciał zobaczyć takie zestawienie, ale ona miała wątpliwości, czy to coś wnosi.

Zamiast krótkiej rozmowy powstał z tego pełnoprawny odcinek podcastu, pełen przemyśleń, historii z praktyki i kilku cennych zwrotów akcji.

Wstrzykiwanie Kanbanu i miary bez formalności

Justyna opowiedziała mi o tym, jak „wstrzykuje” Kanban do organizacji. Nie robi tego formalnie, nie mówi: „teraz wdrażamy Kanban”. Zamiast tego, po prostu poprawia sposób działania zespołów, m.in. wprowadzając wizualizację pracy, ograniczanie WIP-u czy mierzenie cycle time i throughputu.

Kluczowe dla niej jest mierzenie rzeczywistości taką, jaka jest, a nie taką, jaką chcielibyśmy widzieć. Dane są po to, żeby lepiej rozumieć system, a nie żeby go oceniać. Ale same dane nie wystarczą. Trzeba jeszcze nauczyć się je interpretować i o nich rozmawiać.

Pułapki cycle time: kiedy praca naprawdę trwa?

W trakcie naszej rozmowy poruszyliśmy temat cycle time, czyli czasu od rozpoczęcia do zakończenia zadania. I choć definicja wydaje się prosta, to w praktyce skrywa kilka pułapek.

Zwróciłem uwagę na zjawisko, które nazywam pułapką niewidocznej nieciągłości pracy. Chodzi o to, że choć czas biegnie nieprzerwanie od rozpoczęcia do końca, to samo zadanie niekoniecznie jest realizowane ciągiem. Bywa przerywane, przekładane, odkładane na bok. W rezultacie licznik pokazuje 14 dni, a realnej pracy było może 2 lub 3 dni.

To rodzi złudzenie: wydaje się, że większe zadania zawsze trwają dłużej. Ale w rzeczywistości równie dobrze mogą po prostu dłużej czekać na realizację.

Rozmiar zadania ma znaczenie, ale… nie takie oczywiste

Justyna przyznała, że długo broniła tezy, iż rozmiar zadania nie ma większego znaczenia. I trudno się dziwić, bo często większy wpływ na czas realizacji mają zupełnie inne rzeczy. W trakcie rozmowy wymieniliśmy kilka najczęstszych czynników:

• rozproszenie uwagi i przełączanie kontekstu,
• oczekiwanie w kolejkach, np. na review, testy lub decyzje,
• ryzyka, które ujawniają się dopiero w trakcie pracy,
• historia zespołu i jego współpracy z innymi działami.

Dodatkowo, praca reaktywna jak incydenty czy zgłoszenia z produkcji często jest traktowana priorytetowo. Może to skutecznie „wywłaszczyć” czas zadań deweloperskich, przez co nawet małe zadania ciągną się tygodniami.

W efekcie, rozmiar zadania może mieć znaczenie w teorii, ale niekoniecznie w praktyce. Często decydują inne zmienne, z którymi nie liczymy się w trakcie estymacji.

Jak lepiej wizualizować dane?

Punktem przełomowym w historii Justyny była decyzja, żeby pokazywać dane inaczej. Zamiast tworzyć osobne zestawienia dla każdego typu pracy, zdecydowała się na jedną wizualizację z rozróżnieniem kolorystycznym.

Takie podejście przyniosło kilka korzyści:

• kierownictwo zobaczyło udział poszczególnych typów pracy w throughputcie,
• zespoły zyskały całościowy obraz działania swojego systemu,
• nikt nie stracił kontekstu, a dane zaczęły być punktem wyjścia do rozmowy.

Zestawienie typu: 30 procent throughputu to zadania, 70 procent to incydenty, mówi więcej niż jakakolwiek tabela. A jeśli do tego dołożymy cycle time dla każdej kategorii, zaczyna się naprawdę wartościowa analiza.

12 zasad mierzenia i rozmowa zamiast oceny

W pracy z zespołami Justyna zawsze zaczyna od omówienia 12 zasad mierzenia, opracowanych w ramach podejścia Management 3.0. To nie są „twarde” reguły techniczne, ale zasady pracy z metrykami w sposób świadomy i bezpieczny.

Kilka z nich warto przytoczyć:

• miary nie służą do oceniania ludzi, tylko do poprawy systemu,
• dane muszą być transparentne i uzgodnione z zespołem,
• każda liczba wymaga kontekstu i rozmowy.

Justyna stosuje też bardzo ciekawe ćwiczenie warsztatowe. Pokazuje dane anonimowego zespołu i prosi uczestników, żeby zadali pytania do tych danych. Okazuje się, że większość od razu wyciąga wnioski zamiast pytać. To pokazuje, jak trudna jest praca z metrykami, jeśli nie nauczymy się oddzielać interpretacji od faktów.

Metryki nie dla metryk: tylko dla problemu

W naszej rozmowie wracaliśmy kilkukrotnie do tej samej zasady. Miary nie są celem same w sobie. Trzeba je dobierać w zależności od problemu, który chcemy rozwiązać.

Przykładowo:

• jeśli zespoły mają problemy z przewidywalnością, to warto mierzyć cycle time,
• jeśli problemem jest przeciążenie WIP-em, to dobrym wskaźnikiem może być throughput,
• jeśli chcemy zrozumieć wpływ incydentów na system, to warto pokazać ich udział w całym przepływie.

Metryki powinny mieć żywotność ograniczoną czasowo. Justyna podkreśliła, że nie trzyma metryk na siłę. Gdy problem znika, metryka znika razem z nim.

Rozmowy z dyrektorami: odwaga i cierpliwość

Rozmowa z dyrektorem, który domaga się „liczb”, nie należy do najłatwiejszych. Justyna opowiedziała, jak w jednej z organizacji zamiast bezrefleksyjnie dostarczyć wykres, zaczęła zadawać pytania: „po co, co chcesz zobaczyć, do czego to wykorzystasz?”.

Ten krok wymagał odwagi, ale pozwolił uniknąć klasycznego błędu: metryki dostarczone bez kontekstu są nie tylko bezużyteczne, ale mogą… wyrządzić szkody.

Często zakładamy, że osoby wyżej w hierarchii wiedzą wszystko. Tymczasem to my, będąc blisko zespołów i pracy operacyjnej, możemy dostarczyć lepszego zrozumienia.

Podsumowanie: kiedy rozmiar zadania ma znaczenie?

Rozmiar zadania może mieć znaczenie. Ale tylko w sytuacji, gdy:

• system pracy jest stabilny i przewidywalny,
• różne typy pracy są traktowane podobnie,
• nie występują duże zakłócenia, takie jak pilne zgłoszenia,
• dane są zbierane w sposób wiarygodny i konsekwentny.

W pozostałych przypadkach większe znaczenie mają inne czynniki: źródło pracy, sposób jej priorytetyzowania, obecność przestojów i poziom zakłóceń w systemie.

Dlatego zanim zaczniemy mierzyć, warto odpowiedzieć sobie na pytanie: co chcemy naprawdę zrozumieć i co chcemy usprawnić?

Więcej o metrykach?

Sprawdź #33 odcinek podcastu tutaj.