Podobno kiedyś Konfucjusz powiedział: „Naprawa państwa zaczyna się od naprawy pojęć”. Nikt nie jest pewien, czy naprawdę to powiedział, ale co ważne, chciałbym dzisiaj sprecyzować znaczenie słowa „kanban”. Bardzo często ludzie interpretują to na własny sposób, i kiedy dwie osoby rozmawiają na ten temat, mają na myśli dwie zupełnie różne rzeczy.
#1 Karta kanban
Japończycy posługują się kilkoma alfabetami. W zależności od tego, jak fonetycznie zapiszemy słowo „kanban” w różnych alfabetach, otrzymamy różne znaczenia. „Kanban” zapisane w alfabecie hiragana oznacza „kartę”.
Ta karta symbolizuje jednostkę pracy, która przemierza strumień tworzenia wartości. Jeżeli korzystamy z tablicy, ta jednostka pracy przechodzi przez poszczególne kolumny tej tablicy.
Tradycyjnie, w Toyocie na karcie kanban umieszczane były dodatkowe informacje o potrzebnych materiałach, na przykład o częściach z magazynu. Ktoś mógł wtedy powiedzieć: „Przyniosę Ci to, czego potrzebujesz, ale musisz mi na to wystawić kanbana”.
Karta kanban jest graficzną reprezentacją sygnału lub informacji. Dzięki niej, w odpowiednim momencie, możemy „zaciągnąć” pracę, podjąć pewne decyzje oraz aktywnie zarządzać przepływem.
#2 Tablica kanban
Jeżeli Japończycy zapiszą słowo „kanban” za pomocą alfabetu kanji, oznacza to tablicę kanban1. Jest to najbardziej popularne znaczenie tego terminu. Co istotne, nie chodzi tu o dowolną tablicę, lecz o tablicę implementującą system kanban…
#3 System kanban
Zacznijmy od tego, że każdy system kanban to jednocześnie system typu pull2. Oznacza to, że osoby zaangażowane w pracę decydują samodzielnie, kiedy zabrać się za kolejne zadanie (zaciągnąć je). To przeciwieństwo systemu typu push3, w którym zadania są przydzielane do wykonania.
Nawet domowa drukarka jest systemem pull. „Decyduje” sama, kiedy przystąpić do realizacji następnego zadania – gdy jeden arkusz jest już wydrukowany, drukarka ma „wolne miejsce” i pobiera kolejny arkusz. To proste do zrozumienia.
Bez wątpienia mogę stwierdzić, że kanban to król wszystkich systemów pull!
System kanban opiera się na limitach pracy w toku. Każda faza przepływu, lub w przypadku tablicy kanban, każda kolumna, powinna mieć określony LIMIT PRACY W TOKU.
Co ważne, aktywne stany przepływu muszą być oddzielone pasywnymi stanami, nazywanymi także kolejkami. Wyobraźmy sobie sytuację, w której programista kończy swoją pracę i natychmiast przenosi ją do kolumny „Testowanie w toku”. W takim wypadku mamy do czynienia z systemem push. Musi istnieć stan „Gotowe do testowania”, kolejka, z której testerzy mogą pobierać zadania.
Warto również wspomnieć o rzeczy oczywistej, ale często ignorowanej – musi istnieć bardzo klarownie określony początek i koniec systemu. To jest niezmiernie ważne z perspektywy miar stosowanych w kanbanie.
#4 Kanban Produkcyjny
Czwarte znaczenie, które możemy spotkać, to tzw. Kanban Produkcyjny4. Jest on elementem Systemu Produkcyjnego Toyoty, znanego również jako Lean Manufacturing5. Twórcą tego systemu jest legendarny inżynier z Toyoty, Taiichi Ohno – „cesarz” Lean. Co istotne, Kanban Produkcyjny dedykowany jest zarządzaniu produkcją. Bazuje na systemach kanban, o których wspomniałem wcześniej. Celem Kanbana Produkcyjnego powinno być… przyspieszenie produkcji samochodów marki Toyota.
Warto również zrozumieć, że Japonia jest krajem o ograniczonym obszarze, gdzie każdy centymetr kwadratowy jest na wagę złota, dlatego magazynowanie jest czynnikiem, który warto minimalizować. Z tego powodu Kanban Toyoty sprzyja redukcji zapasów. Legenda głosi, że inspiracją dla Taiichi Ohno był sklep z warzywami. Pomidory czy ziemniaki psują się bardzo szybko, więc nie można ich przechowywać zbyt długo. Gdy Ohno to zauważył, zdał sobie sprawę, że podobną strategię można zastosować w fabrykach, aby ograniczyć kosztowne magazynowanie.
#5 Metoda Kanban
Metodę Kanban stworzył David J. Anderson, adaptując Kanban Produkcyjny do zarządzania pracą intelektualną. Metoda Kanban może być stosowana nie tylko w tworzeniu oprogramowania – w zasadzie możliwe jest jej zastosowanie wszędzie.
Aby lepiej zrozumieć Metodę Kanban, warto odnieść się do Scruma, jako do najbardziej znanego agile’owego frameworka. Scrum jest celowo niekompletny, jest jak szkielet, który trzeba uzupełnić potrzebnymi praktykami. Ale podczas gdy Scrum jest frameworkiem, Metoda Kanban jest raczej meta-frameworkiem. Daje ona znacznie więcej wolności.
Myślę, że teraz jest idealny moment na analogię z filmem Arnolda Schwarzeneggera. W Terminatorze 2 pojawia się tzw. T 1000, terminator z ciekłego metalu. Kanban jest dokładnie taki jak T 1000! Jest zdolny do transformacji, adaptacji do każdej sytuacji, przyjmowania najróżniejszych form – można go używać niemal wszędzie!
W Scrumie mamy bardzo jasno zdefiniowane role: Scrum Master, Product Owner i samozarządzający się, interdyscyplinarni Deweloperzy. W Metodzie Kanban role nie są zdefiniowane – trzeba je określić samodzielnie. Istnieją jedynie nieformalne wskazówki, takie jak konieczność posiadania osoby zarządzającej procesem oraz osoby zarządzającej zapytaniami o usługi.
Podobnie jak w Scrumie, w Kanbanie też będziemy potrzebować szeregu zdarzeń, ale jak łatwo się domyślić trzeba je zdefiniować samodzielnie! Kiedy nie ma możliwości zastosowania Scruma, prawie zawsze można użyć Kanbana.
Niestety elastyczność Kanbana ma swoją cenę. Kanban jest naprawdę skomplikowanym podejściem. Scrum daje nam pewne ramy, a Kanban… jest łatwy do zepsucia. Kanban wymaga także znacznie większej dojrzałości organizacji.
Metoda Kanban to podejście ewolucyjne. Zaczynasz od „tego, co robisz teraz” i dopiero z czasem wyłania się ostateczna definicja procesu. Jeśli zdecydujesz się na Project Managerów, to twój proces będzie zawierał Project Managerów, jeśli zdecydujesz się na Scrum Masterów, to twój proces będzie zawierał Scrum Masterów. To naprawdę charakterystyczne dla Metody Kanban w porównaniu do Scruma – po transformacji Scruma końcowym rezultatem jest proces Scrum.
Metoda Kanban to w rzeczywistości niezwykle obszerny temat. Przedstawiłem tutaj tylko niewielki wycinek całego zagadnienia. Jest to temat znacznie bardziej rozbudowany niż Scrum. Mamy tu na przykład praktyki, metryki, prognozy statystyczne, dodatkowe koncepcje, jak również wartości, zasady zarządzania zmianami i zasady dostarczania usług.
A wracając do analogii filmowych – tak jak Predator miał różne tryby widzenia, w Kanbanie mamy coś, co nazywamy soczewkami kanbanu, reprezentującymi trzy różne sposoby patrzenia na system. Wszystko to sprawia, że Metoda Kanban to naprawdę ogromny temat do omówienia.
#6 Scrumban
Corey Ladas jest autorem koncepcji Scrumbana. Wyraził przekonanie, że zespoły, które skutecznie zaimplementowały Scrum, powinny dążyć do wyższego poziomu rozwoju. Powinny przejść do Metody Kanban. Osobiście nie jestem zwolennikiem postrzegania Scruma czy Kanbana w kontekście hierarchii, czy to w sensie jednego podejścia jako lepszego lub gorszego – to po prostu różne metody. Niemniej, takie było stanowisko Ladasa. Na początku Scrumban oznaczał Kanbana wywodzącego się ze Scruma, ale ta koncepcja szybko straciła na znaczeniu.
Obecnie termin ten stosowany jest przez każdego, kto ma na myśli dowolną hybrydę Scruma i Kanbana. Idea hybrydy brzmi intrygująco, ale praktyka często wygląda inaczej. Niestety, prawie zawsze kończy się ona tworzeniem czegoś na kształt potwora Frankensteina.
W dziewięciu na dziesięć przypadków obraz wygląda tak: nie jesteśmy w stanie zastosować prawidłowo Scruma, więc rezygnujemy ze Sprintów, Sprint Retrospective i Sprint Review (są niewygodne), zaczynając pracować zgodnie z Kanbanem. Tworzymy tablice, ale limity prac w toku okazują się również dla nas niewygodne, więc decydujemy się na ich niestosowanie. W praktyce Scrumban oznacza „wygodny” proces – ale proces empiryczny nie może być wygodny! Powinno to być bardzo bolesne, kiedy robimy coś źle! Scrumban zazwyczaj jest anty-empiryczny, niwecząc wszelkie korzyści wynikające z podejścia empirycznego, które jest dla nas tak istotne!
#7 Professional Scrum with Kanban
„Świątynia Scruma”, czyli Scrum.org, stworzyła własną wersję Kanbana, dostosowaną do udoskonalenia istniejącego już Scruma. Jej nazwa to: Kanban dla Zespołów Scrumowych, albo Professional Scrum with Kanban (PSK).
Co istotne, PSK to Scrum w czystej postaci. Wprowadza on elementy z Metody Kanban, ale nadal pozostaje w pełni zgodny ze Scrumem. Zawiera te aspekty Metody Kanban, które nie są uwzględniane przez Scruma. Jeśli więc Scrum coś pokrywa, nie jest to, powiedzmy, dublowane lub nadpisywane. Na przykład, w Metodzie Kanban występuje praktyka o nazwie „Utwórz pętle zwrotne”, która nie pojawia się w PSK, ponieważ Scrum pokrywa kwestię pętli zwrotnych poprzez Scrum Events. Podobnie w Metodzie Kanban mamy praktykę „Doskonal się poprzez współpracę, rozwijaj na drodze eksperymentów”6 – nie jest ona obecna w PSK, ponieważ w Scrumie jest to uwzględniane przez Inspekcję i Adaptację.
Co ważne, tak jak Metoda Kanban jest podejściem ewolucyjnym, PSK ma bardziej charakter Scruma, stanowiąc rodzaj rewolucji. Musimy przeprowadzić transformację, aby wprowadzić Scrum, a następnie, mając już Scruma, możemy iść dalej, implementując dodatkowo Kanban w celu jego optymalizacji. Pozwoli to na stworzenie jeszcze bardziej efektywnego procesu, skupionego na przepływie.
1 To naprawdę smutne, widziałem wiele „transformacji kanban”, gdzie cała zmiana polegała tylko na rozpoczęciu używania tablic z kolorowymi karteczkami.
2 „Pull” oznacza „ciągnąć” albo „zaciągać”. Przyznaję, że troszkę uprościłem definicję systemu pull, jednak to temat tak obszerny, że można by o nim napisać oddzielny artykuł.
3 „Push” oznacza „pchać”.
4 Pisany wielką literą!
5 To oczywiście pewne uproszczenie, Toyota Production System i Lean Manufacturing to nie jest dokładnie to samo.
6 Improve collaboratively, evolve experimentally.
Akredytowany trener Scrum.org oraz Kanban University. Posiada doświadczenie z najróżniejszych obszarów powiązanych z projektami IT. Od wielu lat pomaga rozwiązywać najróżniejsze problemy organizacjom począwszy od startupów na korporacjach kończąc. Gdy wymaga tego sytuacja dołącza do projektu i pomaga wyprowadzić go z krytycznej sytuacji. Nie akceptuje kosmetycznych zmian i podążania za projektową modą. Jeżeli pomaga wdrażać w organizacji Kanbana albo Scruma to tylko po to, aby wytwarzano lepsze oprogramowanie spełniające oczekiwania i potrzeby
użytkowników.