Z czym kojarzy się wam Kanban? Na tak zadane pytanie ludzie najczęściej odpowiadają: z tablicą kanbanową. Niektórzy wspomną również o limitach WIP, ale to już mniej oczywiste. Być może w odpowiedzi usłyszymy coś o przepływie (ang. flow) i związkach Kanbana z prawem Little’a. O czymś takim, jak oczekiwany poziom obsługi (ang. service level expectation, w skrócie SLE) powiedzą jedynie ci, którzy używają Kanbana na serio i robią to profesjonalnie.

Kanban w krzywym zwierciadle

W potocznym rozumieniu Kanban to taka metoda, której używa się zamiast Scruma. Dlaczego zamiast? Tu pada wiele różnych uzasadnień. Jedni utrzymują, że Scrum jest dla niedojrzałych i słabych Zespołów, które potrzebują gorsetu w postaci zasad frameworku, żeby poradzić sobie ze zrobieniem czegokolwiek wartościowego. Inni, że Kanban jest dla Zespołów, które nie są w stanie pracować iteracyjnie – widać są jakieś nieogarnięte, że tego nie potrafią… Jeszcze inni dopatrują się w Kanbanie metody dla Zespołów utrzymaniowych, wykonujących powtarzalne prace itd.

W jaki sposób zacząć korzystać z tak rozumianego Kanbana? Trzeba stworzyć tablicę z kolumnami, które opisują rodzaj i kolejność wykonywanych prac. Na tablicy umieszczone zostaną w formie karteczek (wirtualnych albo fizycznych, zależnie od tablicy, jaka jest używana) rzeczy, nad którymi pracuje Zespół. Oczywiście, jeśli wcześniej używany był Scrum, należy zaprzestać planowania Sprintów i zastąpić to planowaniem just-in-time – bo przecież z iteracjami to nie byłby Kanban, prawda?

Co jeszcze? Można zdefiniować limity WIP. Ten WIP to praca w toku (ang. work in progress), czyli to wszystko, nad czym aktualnie pracuje Zespół. A może nawet trzeba je zdefiniować? Tu już zdania są podzielone. Im ktoś więcej o Kanbanie słyszał lub czytał, tym bardziej skłania się ku tezie, że Kanban jednak tych limitów wymaga. Co oczywiste, gdy już limity są ustalone, nie wolno ich złamać. A może właśnie wolno? To już zależy od tego, kto i co przeczytał lub usłyszał.

Jak się takie limity definiuje? Ano, dla każdej kolumny na tablicy kanbanowej określić należy, ile karteczek maksymalnie może się w niej znaleźć – to właśnie będą limity WIP. Co dadzą limity? To oczywista sprawa: nie będzie można robić dużo rzeczy na raz, więc wszystko kończone będzie szybciej, tylko trzeba dobrze te limity dobrać. No, chyba że są nieobowiązkowe, wtedy nie trzeba.

Kanban na serio

Czy to, co napisałem powyżej, ma cokolwiek wspólnego z Kanbanem? Tak – jak każde nieporozumienie, niedopowiedzenie i przekłamanie mają związki z prawdą i faktami. Pora więc przejechać się walcem po tych bzdurach.

1. Strategia nie metoda

Kanban nie jest metodą, ale strategią działania, którą możemy zastosować w różnych metodach. Oczywiście istnieje też Metoda Kanban, ale nie jest ona tożsama z Kabanem, tylko jest propozycją jego implementacji (to mniej więcej takie nieporozumienie, jak uznawanie Agile i Scruma za synonimy, podczas gdy Scrum to tylko jedna z metod Agile).

Strategia kanbanowa nastawiona jest na optymalizację wartości poprzez optymalizację procesu, w jakim wartość ta powstaje. Inaczej mówiąc, jeśli mamy do wykonania jakąś pracę, dzięki której pojawi się wartość (a po ludzku: korzyść), to im szybciej tę pracę wykonamy i im płynniej będzie ona realizowana, tym szybciej spodziewana wartość się pojawi.

Płynność przebiegu pracy, o której piszę, jest tym wyższa, im rzadziej dochodzi do zatrzymania procesu ze względu na niespodziewane blokady lub przestoje. Te ostatnie są najczęściej wynikiem braku dostępności ludzi i środków niezbędnych do wykonania kolejnych działań.

Jeśli chcemy uzyskać wartość jak najszybciej i w optymalnych kosztach, im rzadziej praca się zatrzymuje, tym lepiej. Nie tylko dlatego, że dłużej trzeba wtedy czekać na pojawienie się korzyści, ale również ze względu na to, że im dłużej praca trwa, tym większe ryzyko, że stanie się coś, co uniemożliwi albo utrudni jej ukończenie. Dlatego robienie nadmiernej liczby rzeczy naraz jest wyjątkowo szkodliwe.

W Kanbanie dąży się do uzyskania procesu, w którym praca realizowana jest najszybciej, jak to możliwe i bez żadnych zatrzymań. I tu pojawia się idea przepływu (ang. flow), który jest właśnie takim stanem optymalnym. Praca ma płynąć poprzez proces.

2. Brak sprzeczności ze Scrumem

Dlaczego Zespoły stosują Scrum? Bo dążą do uzyskania maksimum możliwej wartości w środowisku o niestabilnej złożoności. Maksimum możliwej wartości – to brzmi jak optimum tejże wartości, czyż nie? Może więc da się użyć Kanbana, który służy do optymalizacji wartości, jako strategii w Scrumie?

Pewnie, że się da. A, prawdę mówiąc, dojrzałe Zespoły Scrum, które ani myślą porzucać tej metody, świadomie sięgają po Kanban, uzupełniając nim Scruma, albo organicznie wypracowują własne praktyki, które są niemal dokładnym odwzorowaniem tych kanbanowych.

Warto też zwrócić uwagę, że Zespoły Scrum odchodzące od Scruma, aby pracować w Kanbanie, wciąż potrzebują jakiegoś procesu. Bo Kanban procesem nie jest i stanowi jedynie strategię optymalizacji przepływu pracy przez jakiś proces. Zespół chcący korzystać wyłącznie z Kanbana musi sam zdefiniować swój proces albo popadnie w chaos.

3. Kryterium dojrzałości nie istnieje

Każdy Zespół, nawet zupełnie początkujący, może posłużyć się dowolną metodą lub strategią, a im lepiej ją rozumie i im więcej ma umiejętności oraz doświadczenia, tym lepsze efekty może uzyskać. Nie istnieje żaden egzamin dojrzałości dla Zespołów, upoważniający ich do użycia Kanbana. Poza tym strategia wymagająca na początek dojrzałości byłaby mało przydatna, czyż nie?

To kryterium dojrzałości jest mitem, który ciągnie się za Kanbanem. Tak, Scrum daje zasady i wymaga zastosowania konkretnych elementów, które umożliwią empiryczną kontrolę procesu. Czy to znaczy, że Scrum „prowadzi Zespoły za rączkę”? Nic bardziej mylnego – wystarczy popatrzyć, jak wiele Zespołów nie radzi sobie z praktycznym zastosowaniem tych zasad, które jakoby mają je „prowadzić za rączkę”. Napiszę złośliwie, że Zespoły takie często uciekają do Kanbana (albo czegoś, co uważają za Kanban), bo Scrum czyni ich nieefektywność zbyt widoczną.

Z drugiej strony dojrzały Zespół pracujący w jakimś innym procesie, niż ten znany ze Scruma, jeśli posługuje się Kanbanem jako strategią i będzie dążył do zbudowania wartościowych produktów, nieuchronnie zacznie działać tak, jak definiuje to Scrum i inne produktowe metody Agile.

4. Charakter pracy nie ma znaczenia

Użycie Kanbana jako strategii możliwe jest niezależnie od tego, jaki rodzaj pracy wykonuje Zespół. Zakładając oczywiście, że oczekiwanym efektem zastosowania Kanbana jest optymalizacja wartości, jaką ten Zespół generuje swoją pracą.

Charakter pracy może mieć istotny wpływ na wybór metody, jaką Zespół się posłuży i czasem jest przyczyną niemożności użycia albo konieczności zastosowania np. Scruma. Niezależnie od tego, jaki proces zostanie ostatecznie użyty (jaką metodą posłuży się Zespół), da się ten proces uzupełnić praktykami kanbanowymi i jednocześnie stosować Kanban.

5. Tablica to za mało

Tablica kanbanowa jest jedynie wizualizacją definicji przepływu pracy (ang. definition of workflow). To, czy tam będą kolumny, wiersze czy cokolwiek innego, nie ma znaczenia – mają być jasno określone stany, przez które przepływa to, nad czym pracuje Zespół, a co jest nośnikiem wartości. Co oznacza, że tablica kanbanowa, wbrew obiegowym opiniom, nie służy do zarządzania pracą, ale do zarządzania przepływem – a poprzez to procesem uzyskiwania wartości.

Zachęcam do lektury Kanban Guide (z moimi komentarzami), w którym wymienione są wszystkie elementy składowe definicji przepływu pracy.

Co oczywiste, wprowadzenie tablicy nie wystarczy, by twierdzić, że pracujemy w Kanbanie – to nie tablica optymalizuje przepływ. Kluczowe znaczenie ma tu dobre zdefiniowanie elementów, jakie poprzez tę tablicę przepływają („karteczek na tablicy”) oraz jawnych i jednoznacznych zasad (ang. explicit policies), sterujących przepływem.

6. Planowanie może odbywać się kadencyjnie

Kanban bynajmniej nie wymaga planowania just-in-time, bo nie zawsze jest ono korzystne. Posługując się tą strategią, nie musimy stosować iteracji, ale konieczność pracy iteracyjnej może wynikać z czego innego: z charakteru pracy, jaką wykonuje Zespół.

Jeśli będzie to budowanie produktów o dużej złożoności, które mają odpowiadać na równie złożone potrzeby, a całość odbywać się będzie w niestabilnym, ciągle zmiennym i nieprzewidywalnym środowisku, na pewno zechcemy sięgnąć po empiryczną kontrolę procesu, żeby sobie z tym poradzić. A empiryzm nie istnieje bez iteracyjności, bo wymaga inkrementalnego rozwoju produktu oraz regularnego sprawdzania i dostosowania zarówno tego, co Zespół robi, jak i sposobu pracy (w tym i procesu).

Z kronikarskiego obowiązku dodam, że iteracyjność lub jej brak jest zawsze cechą procesu (metody), której używa Zespół, a nie Kanbana, będącego strategią nałożoną na ten proces (metodę). Inaczej mówiąc, Kanban jest agnostyczny względem iteracji i ani ich nie wymaga, ani nie stanowią one w nim przeszkody.

7. Limity WIP nie są obowiązkowe

Optymalizacja przepływu wymaga kontrolowania ilości pracy w toku (ang. work in progress, w skrócie WIP), ponieważ w myśl prawa Little’a, im większa jest średnia ilość pracy wykonywanej jednocześnie, przy zachowaniu tej samej średniej możliwości jej kończenia – czyli przepustowości (ang. throughput), tym bardziej wydłużał się będzie średni czas wykonywania tej pracy – czas cyklu (ang. cycle time).

Jeśli Zespół będzie zaczynał coraz więcej rzeczy, a nie będzie ich kończył, w oczywisty sposób część tego, co już zostało rozpoczęte, zatrzyma się w procesie. Możliwości ludzkie są ograniczone, więc pojawi się konieczność przełączania między taką pracą już zaczętą, bo wszystkiego naraz nie da się robić. A jeśli praca stoi, nie da się mówić o przepływie.

Z drugiej strony, jeśli to, co jest robione, ma przynieść wartość w momencie ukończenia, jeśli robota stoi w miejscu, uzyskanie wartości oddala się w czasie (albo w ogóle nie uda się jej uzyskać, bo pojawi się zbyt późno). Pisałem już zresztą o tym w punkcie pierwszym powyżej.

Limity WIP pozwalają kontrolować ilość pracy w toku, ale to jedna z możliwych strategii, którą Zespół może zastosować. Istnieją inne. Np. w Scrumie takim sposobem kontrolowania WIP-u jest stała długość iteracji (Sprint), która w połączeniu ze stałym składem Zespołu w iteracji ogranicza ilość pracy, jaką ten Zespół może podjąć do realizacji w jednostce czasu. Można więc powiedzieć, że nie dość, że Scrum nie jest sprzeczny z ideą kontrolowania WIP-u, to wręcz ma ją zakodowaną w swym DNA.

Innym sposobem kontrolowania WIP-u jest ustalenie warunków, jakie muszą być spełnione, by nowa praca mogła zostać rozpoczęta. Zamiast limitów można posłużyć się jedną z miar przepływu, jaką jest wiek jednostki pracy (ang. work item age) i ustalić, że jeśli choć jedna z rzeczy, nad którymi Zespół już pracuje, trwa dłużej niż np. trzy dni, nie można rozpoczynać realizacji niczego nowego.

8. Limity nie gwarantują kontroli WIP-u

Celem kontrolowania WIP-u jest uzyskanie stanu, w którym nowa praca rozpoczynana jest wtedy, gdy istnieją realne możliwości jej wykonywania (oczywiście nigdy nie ma gwarancji, że będzie możliwe jej skończenie).

W ten sposób proces i Zespół chronione są przed utonięciem pod nadmiarem roboty wykonywanej naraz. Mówimy, że powstaje system wciągania pracy (ang. pull system), bo nowe rzeczy wciągane są do procesu dopiero, jeśli spełnione są warunki pozwalające na to. Warunki wynikające przede wszystkim ze strategii kontrolowania WIP-u.

Samo wprowadzenie limitów WIP nie spowoduje automatycznie, że powstanie taki system wciągania pracy, ani nawet, że Zespół będzie skutecznie kontrolował WIP. Limity muszą realnie wpływać na decyzje podejmowane przez Zespół. A nie zawsze tak jest, bo przecież mogą być np. zbyt wysokie. W takim przypadku, mimo że nie zostały przekroczone, Zespół utonie pod nadmiarem pracy.

Dlatego nie ma tu żadnego magicznego działania limitów. Należy je świadomie ustalić i się ich trzymać, a jeśli trzeba – zmieniać, by zoptymalizować przepływ. Jak rozpoznać taką potrzebę? Na przykład dokonujące analizy miary przepływu i ich wizualizacji. Są też takie Zespoły, które zamiast limitów sięgają po inne sposoby kontrolowania WIP-u, o czym pisałem w poprzednim punkcie.

9. Limity WIP można przekraczać

Jeśli limity WIP zostały zdefiniowane, byłoby absurdem, gdyby nie można było ich świadomie przekroczyć. Wbrew przekonaniu wielu osób, łamanie limitów WIP nie musi świadczyć o głupocie Zespołu lub jego nieznajomości Kanbana.

Czemu bowiem służyć mają limity WIP? Kontrolowaniu ilości pracy w toku. Co powinno się stać, jeśli Zespół zauważy, że ustawił limity zbyt wysoko i nie chronią one procesu przed zalewem pracy niemożliwej do zrealizowania? Obniży te limity, to oczywiste. I nagle znajdzie się w sytuacji, gdy limity są przekroczone, bo przecież od samego ich obniżenia nie zmniejszy się automatycznie WIP.

Moment, moment! Czy aby nie powinno się najpierw zredukować WIP-u do poziomu docelowych limitów, a dopiero potem formalnie je zmienić? Nie. Takie działanie skutkowałoby tym, że Zespół kierował się będzie w procesie innymi wartościami limitów, niż te formalnie obowiązujące. Nie da się tego pogodzić ze stosowaniem jawnych zasad w Kanbanie. Gdzie w tym byłaby elementarna przejrzystość?

A czy można limity, które są sensownie ustanowione, mimo wszystko złamać? Tak, bo Kanban nie oznacza scedowania przez Zespół odpowiedzialności za podejmowanie decyzji na obiektywne reguły zdefiniowanego procesu. Jeśli Zespół uzna, że istnieje dobry powód, by przekroczyć limit WIP, może to zrobić. Jasne, że raczej nie powinno się to zdarzać, a już na pewno nie powinno się zdarzać często – ale nie jest zabronione.

10. Limity WIP nie muszą być związane z kolumnami na tablicy

Czy limity WIP muszą być zdefiniowane osobno dla każdej kolumny na tablicy kanbanowej? Nie, z wielu powodów. Po pierwsze, limity te nie są wcale obowiązkowe, jeśli stosowana jest inna strategia kontrolowania WIP-u. Po drugie, tablica kanbanowa nie musi wcale mieć kolumn – to wygodne, ale niejedyne możliwe rozwiązanie. Po trzecie, limity WIP mogą dotyczyć zbioru kolumn na tablicy, jej pojedynczych wierszy (czyli potoków, ang. swimlanes, stosowanych np. do zgrupowania jednego rodzaju pracy na tablicy), zbiorów takich wierszy itd. Mogą też dotyczyć całej tablicy.

Z tym że trzeba pamiętać o jednym, zanim zachłyśniemy się tą elastycznością stosowania limitów WIP: cały WIP ma być kontrolowany, zawsze i bezwarunkowo. Inaczej mówiąc, jeśli stosujemy tablicę z kolumnami, dla których zdefiniowane są limity WIP, to jeśli np. w jednej kolumnie ten limit nie jest ustanowiony, kontrola WIP-u w innej formie musi wciąż jakoś tej kolumny dotyczyć.

Takim częstym antywzorcem jest wprowadzenie kolumny „zablokowana praca”, która nie ma żadnego limitu. To oznacza, że Zespół może każdą rzecz, jakiej nie da się kontynuować, wrzucić do tej czarnej dziury i wciągać do procesu kolejne, nowe rzeczy. WIP rośnie wtedy w sposób niekontrolowany (bo to, co zablokowane, wciąż jest jego częścią, ale nie wyczerpuje limitów przez błędny sposób kontrolowania WIP-u). Nieskuteczna kontrola nad nim powoduje, że to już nie ma wiele wspólnego z Kanbanem.

Czy dobrym rozwiązaniem byłoby obłożenie kolumny „zablokowana praca” stosownym limitem WIP? Cóż, nie ma to sensu, bo Zespół nie ma wpływu na blokady i nie może zaplanować ich ilości. Albo więc ten limit powinien być na tyle wysoki, by w razie czego cały WIP mógł wylądować w tej jednej kolumnie, albo do przekroczenia limitu dochodzić będzie całkiem często. Dlatego najlepiej nie tworzyć osobnych pseudostanów w rodzaju „zablokowana praca” na tablicy kanbanowej.

Czy istnieje więcej takich mitów i półprawd?

Niestety tak. Kanban, choć staje się coraz popularniejszy, jest stosunkowo marnie rozumiany. Podąża w pewnym sensie tą samą ścieżką, którą przed nim przecierały inne idee, strategie i metody. Dlatego ważne jest, by dobrze rozumieć to, z czego korzystamy, zanim zrobimy sobie krzywdę albo zmarnujemy możliwości.

Sięgając po definicję Scruma, Kanbana, czy jakiejkolwiek innej metody, frameworku albo praktyki, zatrzymajmy się nad wszystkim, co nie jest dla nas jasne. Nie używajmy takich definicji jako instrukcji obsługi, bo one nigdy nie stanowią tego typu dokumentu. Za każdym zapisem kryje się jakiś ważny powód. Jeśli ten powód zrozumiemy, możemy posłużyć się czymś (np. Kanbanem) świadomie, a to daje o niebo większe szanse na uzyskanie korzyści, niż robienie czegoś… cóż, bezmyślnie albo nieświadomie.

SLE, prawo Little’a, miary przepływu itd.

W tym artykule wspominam kilka rzeczy, które zdecydowanie zasługują na szersze omówienie, np. czym jest oczekiwany poziom obsługi (SLE), prawo Little’a, miary przepływu, potoki na tablicy kanbanowej… Będę o tym jeszcze pisał w przyszłych artykułach, to mogę obiecać.

A jeśli ktoś chce poznać Kanban jako taki albo dowiedzieć się, jak łączyć tę strategię z pracą w Scrumie, zapraszam na kursy Mastering Professional Kanban oraz Professional Scrum with Kanban. Przy okazji przypominam o stałym kodzie zniżkowym 10MPRO na moje szkolenia.