Odcinek 62. Czy zadania na tablicy Kanban mogą zawracać?

Temat, który poruszymy w obecnym odcinku podcastu to prawdziwy evergreen – wiecznie zielona roślina. Pytanie, które wraca przy praktycznie każdej okazji szkoleniowej czy konsultacyjnej: czy zadania na tablicy Kanban mogą zawracać?

Bardzo często rozpoczynam rozmowy związane z tym – czym jest Kanban i jak go rozumieć? – od prezentacji jakiejś tablicy. Wtedy też pada pytanie, że skoro tablica pokazuje przepływ pracy, to po której jej stronie spodziewalibyśmy się zadań skończonych lub bliskich ukończenia. Tu odpowiedź prawie jednoznacznie pada, że zadania takie znajdują się po prawej stronie tablicy.

W kulturze, w której uczymy się od małego pisać i czytać od lewej do prawej naturalnym jest przepływ zadań na tablicach właśnie w ten sam sposób. Niejednokrotnie jednak zdarza się, że zadanie trafia na jakiś etap lub aktywność, które nie idą po naszej myśli i to oznacza, że stajemy w niekomfortowej sytuacji – co zrobić z takim zadaniem?

Wiele osób sądzi, że na tablicach Kanban zadania pod żadnym pozorem nie powinny wracać, czyli przesuwać się w lewą stronę, ponieważ jest to ruch niezgodny z przepływem wytwarzania wartości czy uzyskiwania informacji.

Wychodząc jednak od jednej z praktyk Metody Kanban – zacznij od tego, co robisz obecnie, warto zastanowić się, co obecnie robimy z zadaniami, które napotykają w swoim cyklu życiowym moment, którym chcemy cofnąć je w lewą stronę.

Najczęściej słyszę, że zadanie nie spełnia jakichś kryteriów jakościowych albo funkcjonalnych, które uzasadniałyby przesunięcie go do kolejnego stanu (najczęściej pasywnego) w prawą stronę. Co to oznacza mówiąc po ludzku? Na przykład to, że zadanie nie przechodzi prawidłowo przeglądu kodu, nie przechodzi „na zielono” wszystkich przypadków testowych albo że klient na wczesnym etapie feedbacku odrzuca istniejące rozwiązanie czy design.

Uproszczone myślenie sugeruje, że w pracy intelektualnej jesteśmy w stanie przewidywać i przeciwdziałać takim sytuacjom przez dokładną specyfikację wymagań czy zapewnienie bardzo wyczerpujących kryteriów wyjścia z poprzednich kolumn, co w Kanbanie nazywamy kryteriami wyjścia lub po angielsku exit criteria.

Ponieważ jednak działamy w obszarze nienamacalnej pracy opartej o wiedzę, pracy często niepowtarzalnej, to wszędzie tam, gdzie następuje komunikacja kilku osób, zawsze istnieje ryzyko, że, mówiąc wprost, nie dogadamy się i pomimo wielu istniejących i pomagających nam zasad oraz reguł może dojść do sytuacji, w której wyprodukujemy coś, co nie będzie spełniało pierwotnie oczekiwanej jakości czy funkcjonalności.

W takich sytuacjach staramy się zwizualizować jakoś tę sytuację i mamy ochotę przysunąć zadanie do wcześniejszej fazy, by pokazać, że musimy wrócić do jakiejś innej aktywności.

Jeśli cofać, to gdzie?

Pierwszym najczęściej stosowanym podejściem jest cofanie zadania, czyli przenoszenie go do jakiejś wcześniejszej kolumny po lewej stronie. Nie mówimy, że to rozwiązanie jest idealne albo kategorycznie zabronione, ale warto zadać sobie pytanie: do jakiej kolumny przesuwamy to zadanie? Jeśli nie chcemy stosować systemu wpychania pracy innym, tzw. systemu push, to prawdopodobnie powinniśmy przesunąć takie zadanie do wybranej kolumny pasywnej. Taką kolumną może być dedykowana kolumna na zadania otwarte po raz kolejny, ale też może być to kolumna, w której będą znajdowały się nowe, dotąd nie rozpoczęte zadania. Jeżeli hołdujemy mantrze: „stop starting, start finishing” to prawdopodobnie zadania umieszczane w tej samej kolumnie, w której znajdują się zupełnie nowe, powinny znajdować się powyżej nich tak, by motywować osoby, które teraz podejmą kolejne zadania do pracy nad poprawianiem tym zadań, które pierwotnie nie przeszły przez cały system, a w które już wcześniej zainwestowaliśmy czas. Jeśli nie stoi to w opozycji do istniejących klas usług, to poprawianie zadań raz rozpoczętych powinno mieć większy priorytet niż rozpoczynanie nowych rzeczy.

Tego typu podejście jest problematyczne z perspektywy łatwego i wiarygodnego śledzenia przepływu pracy. Większość narzędzi, nawet bardziej zaawansowanych, które śledzą metryki przepływu, mówiąc kolokwialnie, wyłoży się na takiej sytuacji, a więc trudno będzie powiedzieć, jaki był właściwy czas realizacji tych elementów, które wracały.

Jest to też podejście, które pokazuje kulturę w której przerzucamy sobie niechciany „ticket”, trochę jak gorącego ziemniaka.

Podsumowując, jeśli obecnie cofamy zadania i chcemy na razie trzymać się tego podejścia, to ustalmy jasno dla wszystkich, do której kolumny zadania są cofane.

Pokażmy, co poszło nie tak

Drugim podejściem jest tworzenie różnego rodzaju zadań typu „przeróbka czy „błąd wewnętrzny” często nazywanych po angielsku „children tasks”, czyli dziećmi zadania nadrzędnego. Te zadania pokazują, że konieczne jest dorobienie jakieś brakującej części funkcjonalności albo poprawienie jakości. Takie nowe tworzone w przypadku odkrycia jakiejś niezgodności zadania zwykle tworzone są tam na lewej stronie tablicy (np. Sprint Backlog) i mają one podobny cykl zadań cykl życia jak ich zadania nadrzędne. Takie zadania dzieci (często sub-taski) wędrują przez tablicę do momentu spotkania się ze swoim zadaniem rodzicem, w którym możemy wznowić aktywność na przykład testowania albo odbioru przez klienta.

Takie rozwiązanie pozwala zaobserwować, jak duży przestój tego zadania został spowodowany oraz, jak długo trwała poprawka części funkcjonalności. Na dodatek, jeśli weźmiemy pod uwagę wszystkie elementy, które będą nasz system opuszczały znajdziemy wśród nich takie, które takich elementów podłączonych nie będą miały i to oznacza, że przeszły przez system prawidłowo już za pierwszym razem oraz takie, które będą miały jedno lub więcej takich podzadań, co pokazuje pewnego rodzaju doróbki. To przy okazji spotkania takiego jak Flow Review może być pomocne by zrozumieć:

• które zadania,
• z jakich źródeł,
• w jaki sposób opisywane przechodzą przez nasze filtry jakościowe.

Czy też inne czynniki powodujące konieczność poprawiania.

Rozwiązanie takie wspiera lepiej śledzenie metryk przepływu zarówno tych elementów nadrzędnych, jak i podrzędnych. Tu będziemy musieli uważać, by nie wpisywać do tempa dostarczania czy przepustowości tych zadań „dzieci”, ponieważ nie są to zadania pierwotnie zamówione przez klienta, a efekt właśnie czegoś, co sami wygenerowaliśmy. To w Kanbanie nazywamy z angielskiego „failure demand”, czyli zapotrzebowanie w wyniku niepowodzenia.

Pewien punkt bólu może spowodować, że przy powyższym podejściu zadania będą musiały zatrzymać się na przykład w kolumnie „testowanie”, zająć tam pewną pracę w toku, co być może ograniczy liczbę zadań, nad którymi będziemy równolegle pracować przy testowaniu i będziemy musieli poczekać, aż wznowimy tę aktywność. Tu należy uważać by nie oskarżać osób odpowiedzialnych za testowania jako te, które przyczyniają się do starzenia pracy.

Lekcje wyciągnięte przy okazji Flow Review warto wpisać w nasze jasne i jawne zasady.

Podsumowując – możemy pokazywać pracę dodatkową nad zadaniami w postaci zadań podłączonych do zadania nadrzędnego, co pozwala nam lepiej mierzyć przepływ zarówno jednostek nadrzędnych, jak i podrzędnych.

A może tak dociągnijmy to wspólnie?

Trzecim podejściem, spójnym z filozofią, która mówi o tym, że to, co widnieje w nagłówku kolumny, jest właściwie jedynie aktywnością wiodącą, a nie jedyną jaka może mieć miejsce, jest wspólna praca nad zadaniem.

Zadanie, które zatrzymało się w aktywności takiej jak przykładowe testowanie, będzie tam oczekiwało, aż właściwa osoba (ta, która wykonywała to zadanie wcześniej albo nowa osoba skierowana do tego) przyjmie na siebie właścicielstwo nad zadaniem, często w parze z kimś, kto zgłosił jakieś niedoskonałości czy błędy i w podejściu kolaboracyjnym taka osoba przypisze się do tego zadania i rozpocznie naprawę.

Co może spowodować pewien zgrzyt? Dorabianie czegoś w kolumnie, która pierwotnie może nas swoją nazwą mylić – nowy lub kontynuowany development może dziać się w kolumnie „testowanie”. Pamiętajmy jednak o tym, że właściwie często jest tak, że nad jednym zadaniem prowadzone są pewne aktywności równolegle – na przykład w momencie pierwotnego developmentu ktoś również mógł tworzyć przypadki testowe. Tym razem pokazujemy, że zadanie zatrzymało się na etapie testowania i czeka, aż pojawi się asysta, pomoc ze strony kogoś, kto jest w stanie naprawić coś do takiego stanu, żeby można było wznowić przykładowe testowanie.

To jest podejście bardzo dalekie od przerzucania sobie ticketów, jak gorących ziemniaków, ponieważ mówimy, że właśnie w duchu współpracy nad zadaniem może rozpoczniemy od rozmowy testera z deweloperem. Być może w czasie rzeczywistym powstaną nowe dane testowe. Może za to feedback w postaci testowania będzie robiony tak szybko jak to możliwe, w efekcie czego nie będziemy spędzać czasu w oczekiwaniu na rozpoczęcie nowych testów.

Tu w temacie metryk warto byłoby oczywiście odnotować coś takiego w zadaniu i pokazać, że to zadanie zostało w taki odmienny względem innych sposób zrealizowane.

Podsumowując może być tak, że kultura w której pracujemy, skupienie na efekcie (outcome) pozwoli zrezygnować z zawracania zadań.

Powyższe przykłady nie wyczerpują wszystkiego, co możemy zrobić, ale zamiast szukać innych, bardziej egzotycznych rozwiązań, może warto zadać sobie pytanie, czy wszyscy rozumieją obecne sytuacje, które powodują, że chcemy zadania zawracać i czy robimy to w spójny sposób?

A Wy co robicie z zadaniami, kiedy czujecie, że powinny wrócić?

Pomóż innym, podziel się!