Od karty do Metody, czyli Kanban w 5-ciu smakach!
Czas na pierwszy artykuł podyktowany ankietą “O Czym pisać?”. Przedstawiam w nim definicje i stawiam możliwie jasne granice pomiędzy różnymi typami (smakami 🙂 Kanbanu. Próbuję też wyjaśnić co nie jest Kanbanem często i niesłusznie stawianym w opozycji do Scrumu.
Mówi się, że żyjemy w czasach post-prawdy. Czarne można nazwać białym, białe czarnym i znajdą się tacy, którzy temu przytakną. Mimo wszystko to zwykle rozumiemy, gdy ktoś mówi:
– To jest stół.
A potem dodaje:
– To jest krzesło.
Jeszcze lepiej gdy to pokaże. O tak..
Łatwe, prawda?
Kiedy jednak ktoś mówi:
– To jest stół. I to też jest stół
rzeczy przestają być tak oczywiste. Zaczyna się słyszeć:
– No tak, ale..
Jedni widzą odjazdowy stolik w kształcie dyskietki a inni.. no właśnie.
Tu pojawia się nieszczęście tego, że wiele “rzeczy” można nazwać jakiegoś rodzaju Kanbanem. To zaś prowadzi do nieporozumień i nadinterpretacji. Co gorsza, brak wspólnej terminologii staje na drodze nauki, rozwoju i doskonalenia metod pracy. Zacznijmy od podstaw – definicji.
1. (Karta) kanban
Celowo pisany małą literą “kanban” oznacza wizualną reprezentację jakiejś pracy do wykonania. Taka reprezentacja nie musi być formą fizyczną (choć lepiej żeby była 🙂 W praktyce kanbanami są więc i karteczki Post-it na tablicach i wpisy w bazie danych znane np. jako niesławne “tickety w Jirze”. Choć znaczenie kart kanban wydaje się banalne, to leży ono u podstaw sukcesu wszystkich wyższych poziomów Kanbanu i szerzej zarządzania wizualnego. Karta kanban jest bowiem widoczną reprezentacją zadania, które samo nie musi być łatwe do zidentyfikowania i śledzenia. Bez karty nie ma mowy o skutecznej wizualizacji pracy twórczej oraz odpowiednim jej zarządzaniu. Zespoły, które robią skróty i nie śledzą części zadań w postaci kart, narażają się na coś, co nazywam “krwawieniem czasem”. Liczne zadania, co do których nakład czasu zostaje często trywializowany powodują, że zespołom czas przecieka przez ręce i bardzo trudno określić, gdzie i z jakiej przyczyny tak się dzieje.
2. Tablica Kanban
to fizyczna lub cyfrowa tablica, na której układ (najczęściej kolumn) wizualizuje przepływ pracy. Przepływ od momentu jej zidentyfikowania (lewa strona) do stanu jej dostarczenia a przynajmniej ukończenia (prawa strona). Umieszone na tablicy karty kanban reprezentują poszczególne zadania na różnych etapach ich wykonania. W celu łatwiejszej pracy z tablicą zespoły wprowadzają często kod kolorów lub kształtów. Innym pomocnym podejściem jest ich fizyczne oddzielanie w wierszach (swimlanes) np. jeśli karty są częścią składową większej całości (historyjka i przynależne do niej zadania). Tablica jest również dobrym narzędziem wizualizacji tego kto pracuje nad danym zadaniem (realizowanym np. przez graficzne avatary) oraz czy zadania nie są zablokowane.
Mamy tablicę Kanban więc pracujemy w Kanbanie. Otóż nie.
Tablica Kanban jest tylko narzędziem. Narzędziem, które powinno odzwierciedlać przepływ pracy przez jakiś system. Niestety może to oznaczać, że tablica będzie wizualizacją starego dobrego podejścia kaskadowego (waterfall). Tablica może pokazywać pracę w Scrumfallu, gdzie każdy sprint to mały projekcik kaskadowy, Może w końcu pokazywać podejście w pełni zwinne (agile) i/lub szczupłe (lean). Tablica jest narzędziem, które powinno skłaniać do komunikacji, współpracy i rodzić pytania pchające zespół lub organizację w stronę ulepszania swoich procesów. Jak? O tym poniżej.
Nie ucieknę tu od odniesień. Tak samo jak obecność Scrum Mastera, czy Product Ownera nie gwarantuje pracy w Scrumie, tak tablica Kanban nie oznacza pracy “w Kanbanie”. To najczęściej praca, jakkolwiek nazwana, z wykorzystaniem tablicy Kanban.
3. Proto-Kanban oraz 4. System Kanban
Gdy wiemy już, że mamy tablicę Kanban, warto zadać pytania o to, czy owej tablicy towarzyszą praktyki tego co stoi u podstaw dojrzałych Systemów Kanban. Są nimi:
wizualizacja pracy – tj. czy cała praca jest zwizualizowana i czy zadania znajdują się w odpowiednich miejscach
ograniczenie pracy w toku (WIP limit, od work-in-progress) – czyli czy istnieją jasno określone i przestrzegane ograniczenia co do ilości zadań aktualnie przypisanych członkom zespołu, ograniczenia co do liczby zadań w danej kolumnie, wierszu, lub na całej tablicy
orientacja na zarządzaniu przepływem pracy (flow)
zdefiniowane, widoczne i znane zespołowi zasady dotyczące wymagań koniecznych do przesunięcia zadań, np. jak choćby definicja gotowości (definition of ready), definicja ukończenia (definition of done), czy też jasne zasady cofania zadań, zgłaszania błędów.
pętle zwrotne a więc zasady reagowania na zmiany zachodzące na tablicy, na pojawiające się zadania zablokowane, powstające kolejki, lub tzw. bąble (braki zadań)
uzgodniona współpraca w grupie prowadząca do ewolucji systemu opartego na eksperymentach i metodzie naukowej.
Wiele zespołów pracujących z tablicą realizuje zwykle kilka z powyższych praktyk. Najczęściej są nimi wizualizacja i jakiegoś rodzaju ograniczenia pracy w toku. Rzadziej jasne zasady przesuwania zadań, lub sytuacja, gdy wystepują one tylko dla niektórych statusów. Czy to dobrze? Tak, bo to oznacza, że zespół postawił kilka kroków w stronę zbudowania systemu Kanban, ale droga ta jeszcze nie została ukończona. Taki stan, w którym doświadczamy choć części praktyk systemów Kanban nazywamy proto-Kanbanem.
Trzeba dodać, że Proto-Kanban nie jest terminem o zabarwieniu negatywnym. Celowo społeczność związana z Kanbanem woli używać przedrostka proto-, sugerującego dalszą ewolucję (jak protogwiazdy, czy protoplanety) zamiast określeń stygmatyzujących. Co może zrobić zespół na etapie swojej ewolucji, który wpada w kategorię proto-Kanbanu? Nie zatrzymywać się. To jedna z obserwowanych bolączek, kiedy wprowadzenie kilku praktyk przynosi ulgę i poprawę na poziomie członków zespołu i zespół “spoczywa na laurach”. Praktycy Kanbanu sugerują iść dalej i nawigować ewolucję Metodą Kanban.
5. Metoda Kanban
Twórca pojęcia – David J. Anderson tłumaczy, że Metoda Kanban to w pełni rozwinięty System Kanban (lub ewoluujący, ale nie zastały proto-Kanban) oraz postępowanie w zgodzie z nastepującymi zasadami zarządzania zmianami (change management principles):
Zacznij od tego, co robisz (zrozumienie obecnie istniejących procesów, uszanowanie istniejących ról)
Zbuduj porozumienie co do podążania ścieżką ewolucyjnych zmian ku ulepszeniom
Zachęcaj do przywództwa na każdym poziomie organizacji.
Gdybyśmy mieli więc podsumować Metodę Kanban to mamy następujące równanie:
System Kanban (6 praktyk) + Podejście Ewolucyjne = Metoda Kanban
Na drodze ewolucji (a jakże!) Metody Kanban Anderson dodał jeszcze dwa istotne czynniki. Pierwszym są podwaliny podejścia – a więc próba zarządzania pracą nienamacalną (intelektualną, lub kreatywną) tak jak dobrami fizycznymi (simple underlying principles) oraz zasady dostarczania usług (service delivery principles):
zrozumienie i skupienie na potrzebach klienta
zarządzanie pracą, a nie ludźmi, którzy powinni samoorganizować się wokół zadań
ewolucja (znowu!) zasad zarządzania w celu poprawy rezultatów dla klienta i naszej firmy
Całkiem zwinnie chciałoby się dodać, hm?
Teraz zróbmy użytek z pozyskanej wiedzy, zbudowanych definicji i podkreślmy, co nie jest Kanbanem.
Często trafiam w swojej pracy na bolesne uproszczenie, które stoi za otwierającym artykuł komiksem. Zespoły pracujące w Scrumie, lub czymś podobnym, nie oceniam, natrafiają na ograniczenia związane ze sprintami, problemy z ich “dowożeniem” czy ceremoniami i postanawiają je odrzucić. W swoim mniemaniu zespoły te traktują przełączenie się na tryb pracy bez ram czasowych jako równoznaczne z pracą “w Kanbanie”.
Tu stawiam również hipotezę, że za szerzenie krzywdzącego uproszczenia, że “Kanban to Scrum bez sprintów“ można winić Atlassiana, w którego flagowym produkcie – Jirze można tak “przełączyć” projekt.
Powstaje więc pytanie w jakim Kanbanie? Jeśli zespół praktykuje śledzenie przepływającej pracy przy pomocy fizycznej lub cyfrowej tablicy, można powiedzieć, że używa tablicy Kanban. W zależności od dojrzałości i dyscypliny zespół może stosować ograniczenia pracy w toku (limity WIP), czy jasno ustalone zasady a tym samym powiedzieć, że zbudował proto-Kanban, lub System Kanban.
Na trudniejsze pytania o to czy zadania po skrajnie prawej stronie tablicy są nie tylko ukończone, ale i dostarczone klientowi zespoły te rzadko odpowiadają twierdząco. Wtedy okazuje się, że ów kanbanujący zespół nadal zmaga się z brakiem systemów ciągłego dostarczania, czy nawet ciągłej integracji, a pętla zwrotna informacji od klienta trwa tygodnie, lub nie istnieje wcale. Pojawia się smutna konkluzja, że płytkie rozumienie Kanbanu staje się usprawiedliwieniem dla słabej dyscypliny pracy czy niskiego poziomu odpowiedzialności za nią. Kanban, podobnie jak cała koncepcja lean ma za cel dostarczanie wartości szybko i często (ciągle), a nie zamrażanie zadań w kolumnie “Done” na tygodnie.
Jak widzicie, żaden z poziomów Kanbanu nie mówi nic o sprintach, czy story pointach. Nie mówi o praktykach rozwoju produktu ani że musisz, ani że nie możesz ich stosować. Scrum i Kanban są bowiem dwiema koncepcjami, które skutecznie można zaprząc do pracy nad jednym projektem.
Naturalnie może się okazać, że na drodze ewolucyjnych zmian dojdziesz do wniosku, że któraś z istniejących aktywności czy zasad, nie ma sensu, bo na drodze zweryfikowanego eksperymentu wypracowaliście coś lepszego, osadzonego w waszym kontekście. Coś, co nie przynosi wartości i staje się przejawem kultu cargo. W świecie Kanbanu nazywa się językiem ewolucji – reliktem, żywą skamieliną. Co z tym zrobisz? Zależy od Ciebie!
PS. Dzięki dla Piotra za feedback! Będę pisał krócej 🙂