Kanban boli – ma boleć!

Kanban ma boleć! Niektórzy uważają, że ból jest czymś złym. Wyobraź sobie jednak hipotetyczną sytuację. Opierasz się dłonią o rozgrzany piec, jednak ból pojawia się dopiero po miesiącu. Odroczyłbyś w czasie dużą nieprzyjemność, takie oparzenie to nic fajnego! Czy, aby na pewno tego właśnie byś chciał?

Prawda jest taka, że najprawdopodobniej nie zdjąłbyś ręki z pieca od razu – zareagowałbyś na niekorzystną sytuację dopiero po pewnym czasie. Doszłoby do poważnych i trwałych uszkodzeń tkanki. Do tego odroczony ból, koniec końców,  byłby o wiele silniejszy.

Często powtarzam moim klientom, że proces delivery powinien być jak system nerwowy – w momencie gdy cokolwiek złego dzieje się w projekcie powinno nas to od razu: kłuć, palić, szczypać i nie pozwolić nam przejść nad tym do porządku dziennego! Bez „bólu” nie jesteśmy w stanie szybko zareagować. Rzeczywistość jest jednak bezlitosna, nierozwiązywane na bieżąco problemy będą nas kosztować coraz więcej i więcej. Nie rozwiązują się też samoistnie.

Metoda Kanban daje nam kilka narzędzi, aby „poczuć ból”. Oto kilka z nich:

1. Wiek Elementu Pracy (Work in Progress Age)

To niewątpliwie potężne narzędzie Metody Kanban – chociaż bardzo niedoceniane! Jest to czas jaki upłynął od rozpoczęcia pracy nad danym zadaniem.Na przykład zadanie X zostaje wciągnięte na tablicę w dniu 1 to jeżeli w dniu 22 dalej będzie w toku, to jego wiek wynosi 21 dni – nie ma znaczenia ile kolumn przeszło tak długo jak jest nieukończone w 100%.

Wiek elementu pracy można wizualizować poprzez dodawanie codziennie na Daily kropki na karteczce reprezentującej to zdanie np. za pomocą mazaka. Karteczka z dużą ilością kropek „kłuje” w oczy każdego kto tylko spojrzy na tablicę kanbanową. Daje to zespołowi motywację, aby jak najszybciej dokończyć starzejący się item.

Czasami tłumaczę zespołom, że zadania które zaciągają do pracy są jak banany – po zbyt długim czasie psują się, a nawet gniją.

2. Wizualizacja blokad

Bardzo często zespół wytwórczy jest w pewien sposób zależny od osób z zewnątrz. Przykładowo programiści nie posiadają wszystkich potrzebnych uprawnień administracyjnych i do ukończenia niektórych zadań potrzebują pomocy kogoś z innego zespołu albo nawet działu. Istnieje duża pokusa, aby zająć się kolejnym zadaniem na liście, a o zablokowanym zadaniu zwyczajnie zapomnieć.

W takiej sytuacji zawsze zachęcam do odpowiedniego zwizualizowania blokady na tablicy kanban. Dobrym pomysłem jest doczepienie karteczki w kolorze którego nie używamy na co dzień i opisanie powodu blokady. Za każdym razem gdy tylko spojrzymy na tablicę kanban przypomnimy sobie o tym, że zadanie w dalszym ciągu „gnije” w naszym przepływie. Może nas to zmotywować do skuteczniejszej eskalacji problemu albo gdy sytuacja się powtarza do zdobycia brakujących kompetencji.

3. Analiza Czasów Realizacji

Czas Realizacji (Lead Time) to czas jaki upłynął od zaciągnięcia zadania do pracy do momentu gdy zostało ukończone. Opisywany w punkcie 1 Wiek Elementu Pracy dotyczy zadań w trakcie realizacji – jeszcze nieukończonych. Natomiast Czas Realizacji dotyczy zadań zamkniętych.

Warto śledzić trendy tej metryki w czasie. Do tego świetnie nadaje się prosty wykresik Run Chart (nie znalazłem dobrego tłumaczenia – jeżeli masz pomysł napisz proszę komentarz). Za każdym razem gdy jakieś zadanie zostaje ukończone dodajemy jego Lead Time na wykresie. Szybko można zauważyć czy efektywność pracy zaczyna maleć czy rosnąć. Najważniejsze jednak, że szybko możemy na to zareagować!

Przykładowo jeżeli zespół ukończy kolejne zadanie w 36 dni to, aby dodać je do powyższego wykresu umieszczamy nowy punkt X=23 (to zadanie zostało ukończone jako 23) oraz Y=36.

4.Limitowanie Pracy w Toku (Limiting Work in Progress)

Limit Pracy w Toku to polityka/zasada określająca jak dużo może być zadań w danej części przepływu. To bywa dla zespołów bardzo bolesne, przykładowo gdy testerzy osiągają maksymalną ilość zadań w toku to programiści nie mogą im dokładać kolejnych. Jeżeli ta sytuacja się utrzyma dłużej to programiści osiągną własny limit zadań i nie będą mogli niczego nowego rozpocząć.

W tym momencie zawsze pojawia się silna pokusa – „może zignorujemy tym razem limity pracy w toku? Inaczej nie będziemy efektywnie pracować”. Smutna prawda jest taka, że przepływ pracy się zablokował na testach. Jeżeli programiści będą dokładać kolejną pracę to tylko pogłębią problem. W tym momencie zwiększenie WiP Limitów to jak wzięcie silnego leku przeciwbólowego i dalsze trzymanie ręki na piecu. Zamiast tego utrzymane WiP limity zmuszają nas do skupienia się nad rozwiązaniem problemu ¹.

***

Oczywiście Metoda Kanban oferuje dużo więcej „bolesnych doświadczeń” – wymieniłem tylko kilka. Co ważne bez  „systemu nerwowego” nie może istnieć empiryczny proces dostarczania wartości. Krótko mówiąc: bez bólu nie ma zwinności.

Terminologia i dodatkowe uwagi:
1. Problemy z zablokowanym przepływem najlepiej rozwiązać za pomocą POOGI (Process of Ongoing Improvement opisany w poście Teoria Ograniczen Pracy Scrum Mastera).