Odcinek 56. Jak wdrożyć Kanban? STATIK

Powracającym niczym bumerang jest pytanie: jak wdrożyć Kanban? Podobnie jak z nauką języka możemy opanować cały słownik, ale nie będzie to oznaczało nawet średnio zaawansowanej znajomości praktycznej np. umiejętności rozpoczęcia rozmowy. Na dodatek znajomość naszego rodzimego języka może wpuścić nas na minę tzw. false friends. W dobrej intencji będziemy robić coś, co spowoduje tylko stres, ośmieszenie się czy inną wpadkę. Jak uniknąć częstych błędów?

Zacznijmy od tego, co rozumiemy jako Kanban? Jeśli coś więcej niż tylko tablicę, to może nie od tablicy warto zaczynać. Tablica ma być bowiem tylko narzędziem, które podobnie jak wiele innych elementów systemu Kanban ma podejmować konkretne wyzwania czy problemy, a w ostateczności przynosić korzyści w tym, jak pracujemy i co wartościowego dostarczamy.

I tu pojawia się tajemniczy anglojęzyczny skrótowiec, a więc STATIK, wyraz powstały od pierwszych liter System Thinking Approach to Introducing Kanban. Coś, co na język polski moglibyśmy przetłumaczyć jako podejście do wdrażania Kanbanu oparte o myślenie systemowe. Brzmi strasznie? Spróbujmy to opowiedzieć w bardzo przystępny sposób.

Jesteśmy w punkcje zerowym

Jak możecie wynieść z części audio, dobrze zacząć jest naszą wędrówkę od punktu zerowego – określenia, co stanowi dostarczane przez nas usługi, jednostki wartości, które klient rozpoznaje jako dostosowane do potrzeb (ang. fit-for-purpose). To może być bardzo odkrywcze, szczególnie jeśli zaangażujemy do tego klientów, użytkowników czy interesariuszy. Może się okazać, że próbujemy polerować i pozłacać nie to, na czym zależy odbiorcom. Punkt zerowy to często osobny temat, warsztat product discovery lub seria wywiadów.

Czy mamy słonia w pokoju lub na zewnątrz?

Nawet jeśli nie mamy czasu, możliwości i wglądu w powyższe tematy proponujemy rozpoczęcie od czegoś nieintuicyjnego. Zbadania istniejących przyczyn niezadowoleniach:

  • zewnętrznych – a więc opinii, ocen ze strony osób, które naszą pracę odbierają. Mogą pojawić się tu tematy związane z nieterminowością, czasami realizacji, brakiem przewidywalności czy transparencji,
  • wewnętrznych – czyli tego co doskwiera zespołowi. Tu bez sugerowania często pojawiają się tematy, które Scrum Masterzy znają z Retrospektyw w swoich zespołach.

Czego się od nas chce?

Tak można podsumować w jednym zdaniu temat analizy zapotrzebowania, a więc identyfikacji tego, skąd i jakie zapotrzebowanie do Nas spływa. Warto wziąć tu pod uwagę źródła, kanały, komunikowaną ważność lub pilność pracy oraz charakterystykę zapotrzebowania w czasie np. jego sezonowość.

Ile z tego robimy?

Jest pewne spojrzenie na systemy Kanban, które mówi, że ich celem jest wprowadzenie równowagi pomiędzy zapotrzebowaniem a zdolnością dostarczania wartości. To stanowi podstawę systemów „pull”, a więc takich, w których nie wciskamy pracy w oparciu o myślenie życzeniowe, ale respektujemy to, ile możemy zrealizować i skupiamy się na tym, co najistotniejsze, jeśli widzimy, że nie możemy obsłużyć wszystkiego. Tu potrzebna jest ilościowa analiza tego, ile ze spływającego zapotrzebowania istotnie jest dostarczane. Które elementy pobieramy do realizacji, czym się tu kierujemy, a które pozostawiamy – czy to nierozpoczęte (starzejące się z backlogach), czy też tkwiące już w systemie w kolejkach czy nawet stanach tylko z nazwy aktywnych. Dobrą pomocą jest tu analiza przeszłego dostarczania np. delivery rate. Może nam to pokazać, czy system jest drożny i zdolny dostarczać to, czego się od niego oczekuje.

A gdyby tak zostać „karteczką”?

Dobrym pomysłem zaczerpniętym ze świata leanu jest przyjęcie perspektywy jednostki pracy, zamówienia czy karty Kanban zamiast pytania ludzi, co robią z pracą. Kolejny etap STATIK to zbudowanie istniejącego modelu przepływu, który może być taki sam lub różny dla różnych elementów pracy, ale który zawsze warto właśnie budować przez zadawanie pytań z perspektywy takiej karty, a nie roli czy stanowiska. Nie chodzi o to, co testujemy czy projektujemy, bo może obie te czynności robimy bez przerwy, ale skąd bierze się element do testów, co dzieje się z czymś, co zostało zaprojektowane. Tu często identyfikujemy potrzebę wizualizacji tego, że praca nie jest ciągła i pomocne są kolumny pasywne.

Zadanie zadaniu nierówne

I nie mam tu na myśli złożoności czy deklaratywnej wielkości zadania, choć i takie różnice mogą występować. Jak wiemy z analizy przepływu najczęściej za czas przejścia przez system odpowiada priorytet lub po kanbaniarsku klasa usług. I dlatego czas porozmawiać o tym, czy zadania traktujemy w systemie tak samo, a jeśli nie, to czym kierujemy się realizując jedne z pierwszeństwem ponad innymi. Pomocą może być tu jak spływające zadania są komunikowane (patrz analiza zapotrzebowania), ale też obserwacja tego, co przez system przechodzi, a co się w nim gromadzi (analiza dostarczania). Warto nie spinać się na stosowanie klas usług, jakie możecie znać z kanbanowej literatury (fixed date czy expedite), bo pewnie istnieją na to lokalne nazwy, których będzie łatwiej używać np. deadline, czy „od prezesa”.

I tu cały na biało wjeżdża System Kanban

Dla wielu jest zaskoczeniem, że tablica, a wkrótce System Kanban ze swoimi politykami, limitami, zasadami, odpowiednim kodem kolorów czy wierszy pojawiają się dopiero tu. Na końcu warsztatu STATIK. A może to wcale nie koniec? To, co tu powstanie będzie tylko albo aż pierwszą wersją, która powinna ewoluować. Będzie się zmieniać, bo będziemy odkrywać, że coś pominęliśmy, o czymś zapomnieliśmy, albo dokonaliśmy pewnej projekcji rzeczywistości i widzimy rodzącą się różnicę pomiędzy tym jak być powinno, a jak jest.

Gdzie jeszcze szukać pomocy?

Znasz jeszcze jakieś fajne materiałī? Daj znać! I naturalnie – powodzenia we wdrażaniu Kanbanu ze STATIK-iem pod pachą!

Pomóż innym, podziel się!


One Reply to “Odcinek 56. Jak wdrożyć Kanban? STATIK”

Leave a Reply