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 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, 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, jak 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śla się, ile karteczek maksymalnie może się w niej znaleźć – to właśnie będą limity WIP. Co dadzą te 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 jako taki 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).

Skoro Kanban to strategia, na co jest ona nastawiona? Na optymalizację wartości, przy czym sposobem na uzyskanie tego optimum jest optymalizacja procesu, w jakim wartość ta powstaje. Inaczej mówiąc, jeśli mamy jakąś pracę do wykonania, dzięki której pojawi się wartość (a po ludzku: korzyść), to im szybciej tę pracę wykonamy i im płynniej ona przebiega, tym szybciej nasza wartość się pojawi.

Ta płynność, o której wspominam, odnosi się do tego, czy z upływem czasu udaje się realizować pracę tak, że nieustannie przybliżamy się do jej zakończenia, czy też zdarza się, że praca stoi, bo jest czymś zablokowana. Albo stoi, bo osoby, które miałyby ją wykonywać, zajmują się czymś innym. Jeśli chcemy uzyskać wartość jak najszybciej i w optymalnych kosztach, to oczywiste, że im rzadziej praca się zatrzymuje, tym lepiej. Dlatego dążymy do uzyskania takiego procesu, żeby w ogóle się nie zatrzymywała – by płynęła. I tu pojawia się idea przepływu (ang. flow), który jest właśnie takim stanem optymalnym.

Składając to do kupy: Kanban jest strategią optymalizacji wartości poprzez optymalizację przepływu pracy przez proces, w którym ta wartość jest wytwarzana.

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? To może, skoro Kanban jest strategią optymalizacji wartości, dałoby się go użyć 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, albo świadomie sięgają po Kanban, uzupełniając nim Scruma, albo organicznie wypracują praktyki, które będą 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, a jedynie strategią optymalizacji przepływu pracy przez ten proces. Czyli w tej sytuacji Zespół będzie musiał sam zdefiniować swój proces albo popadnie w chaos.

3. Kryterium dojrzałości nie istnieje

Każdy Zespół, niezależnie od tego, czy dojrzały, czy początkujący, może posłużyć się dowolną metodą lub strategią. Im lepiej ją rozumie i im więcej ma umiejętności oraz doświadczenia, tym lepsze efekty może uzyskać. Nie jest jednak tak, że istnieje jakiś magiczny „egzamin dojrzałości” dla Zespołów, upoważniający ich do użycia Kanbana. Strategia wymagająca na początek dojrzałości byłaby mało przydatna, czyż nie?

To kryterium dojrzałości jest pewnym 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 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, to nieuchronnie zacznie działać bardzo podobnie do tego, jak definiuje to Scrum i inne 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 może zdeterminować o niemożności użycia np. Scruma, albo o konieczności jego zastosowania. 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, rzędy 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, 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, bo 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 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, to zmuszeni będziemy 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ę).

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 na raz 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, to jeśli robota stoi w miejscu, uzyskanie tej wartości oddala się w czasie (albo w ogóle nie uda się jej uzyskać, bo pojawi się zbyt późno).

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ść prac, jakie 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 nawet 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 na raz. Mówimy, że powstaje system wciągania pracy (ang. pull system), bo rzeczywiście, 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 analizując miary przepływu i ich wizualizacje. Są też takie Zespoły, które zamiast limitów sięgają po inne sposoby kontrolowania WIP-u, o czym pisałem już wcześniej.

9. Limity WIP można przekraczać

Przyjmując, że limity WIP zostały zdefiniowane, byłoby absurdem, gdyby nie można było ich świadomie przekroczyć („złamać”). I niekoniecznie wynikać to będzie z głupoty Zespołu, który radośnie postanowi utopić się w nadmiarze roboty.

Czemu służyć mają te limity? 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, tak po prostu. Przecież od samego ich obniżenia nie zmniejszy się magicznie WIP, jeśli był wysoki.

Moment, moment! A 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. Jak to 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 stanu (i związanej z nim kolumny) „zablokowana praca”, który 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 „zjada” 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 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ę czy to Scruma, czy 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 artefaktu. 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 kanbanowe 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.