Kanban to dużo więcej niż karteczki na tablicy

Transkrypcja podcastu:

Paweł: Cześć jestem Paweł Tomkiel.  Jestem z Deloitte Digital. Kiedy myślę Kanban to wyobrażam sobie 3 kolumny: do zrobienia, w trakcie i zrobione. Do dzisiejsze rozmowy zaprosiłem Kubę Drzazgę, który wyjaśni nam, że jest w tym coś więcej.

Kuba: Witam wszystkich zgromadzonych jak się nazywam Kuba Drzazga. Na co dzień zajmuje się trzema rzeczami. Pomagam projekty wyciągać z bardzo trudnej sytuacji, z ruiny. Pomagam wprowadzać usprawnienia na poziomie procesów produktów i Leadershipu. No i pomagam ludziom się też rozwijać np.  szkole właśnie ludzi z Kanbana i Scruma.

Paweł: Cześć Kuba. Do dzisiejszego odcinka zaprosiłem Kubę Drzazge.  Kuba jesteś przede wszystkim akredytowanym trenerem Kanbana, ale kiedy wejdzie się na Twoje profile, na Twoją stronę www to widać, że chociażby z samego Scrum org masz certyfikaty. Właściwie od początku do końca masz professional Scrum mastera. Masz Scrum with w Canva, masz Scrum with user experience. A gdybym miał Cię zapytać, co robisz na co dzień, to jak byś sam siebie opisał.

Kuba: Kurcze, to trudne pytanie wbrew pozorom. Myślę, że jako osobę, która pomaga moim klientom rozwiązywać właściwe problemy. Ja nie wiem jeszcze wchodząc do klienta z czym ma naprawdę problem. Raz na przykład klient mówi, Kuba pomóż nam usprawnić naszego Scruma. Ja tam wchodzę i po pierwszych rozmowach okazuje się, że połowa firmy no małej może, ale próbuje już po prostu szukać nowej pracy, za chwilę chcą rzucić papierami. No to 180 stopni obrotu wykonaliśmy, przestaliśmy usprawniać Scruma, zajęliśmy się kwestiami nazwijmy to HR-owymi, więc rozwiązuje problemy, które klient ma. Jeżeli Kanban, albo Scrum są właściwym narzędziem do rozwiązania tych problemów to pomagam je wdrożyć. Jeżeli nie, to nie. Tak to wygląda.

Paweł: Powiedziałeś, że kampanie. Kanban to będzie to narzędzie, o którym sobie dzisiaj chcemy porozmawiać. Tak jak podziałem we wstępie, zawsze myślę, że nie tylko w mojej głowie, kiedy ktoś słyszy Kanban widzi te 3 kolumny, widzi tablicę z karteczkami i wydaje się, że to jest prosty system.  ale jakbyś miał odpowiedź na pytanie: czym jest Kanban? 

Kuba: Wiesz co, to odpowiem jako konsultant- to zależy jak na to spojrzymy. Ja tak szybko bym wymyślił, powiem Ci nawet tak z siedem znaczeń Kanbana. W ogóle Kanban to jest coś, co wywodzi się z Japonii. To jest słowo japońskie. Japończycy nie dość, że mają tak skomplikowany alfabet, to jeszcze się okazuje, że mają kilka wersji różnych alfabetów. I teraz, jeżeli użyjesz odpowiedniego znaku w jednym alfabecie, np. Carte, czyli po naszemu Ticket. Weź mi wypisz Kanbana na to, a to oznacza weź mi na przykład ticketa w Jirze zrób. Też może oznaczać w innym alfabecie szyld, tablice, czyli to jest po prostu tablica. Tutaj w zasadzie trochę dotykamy tego, co powiedziałeś. Nie możemy mieć po prostu to- do i progres- done. Chociaż powiem szczerze, że ta tablica, przynajmniej w nomenklaturze kanbanowej, to też nie jest taka zwykła tablica. Najczęściej mamy na myśli taką tablicę, która realizuje tzw. system Kanban.  System Kanban to też tzw. system PULL, czyli system ciągniony. No bardzo dziwnie brzmi po polsku, dlatego ja najczęściej właśnie operuję na oryginalnych wyrażeniach. Co jest ważne w systemie pull. Decyzję o tym, żeby zaciągnąć następne zadanie podejmuje zespół, który jest częścią tego systemu. Jest to przeciwieństwo systemu Push, gdzie jakaś osoba zewnętrzna, jakiś nad rządca albo po prostu PM decyduje o tym, żeby przypisać ludziom zadanie i teraz co jest ważne system kanban. Takim triggerem dla zespołu, żeby zaciągnąć następne zadanie jest tzw. limit pracy w toku. Nie ma systemu kanban bez limitu pracy w toku. to jest esencja tego po prostu. Każda wyróżniona kolumna, która jest w systemie Kanban, posiada właśnie tzw. limit pracy w toku i np. jeżeli zespół, jest już na maksymalnej ilości zadań w toku, no to nie może zaciągać kolejnego. To broni nas przed przeładowaniem. Pomaga nam utrzymać balans, skraca czas dostarczania itd. Jeżeli okazuje się, że jesteśmy trochę poniżej tego właśnie limitu pracy w toku zespół ma sygnał, okej możemy zaciągać następne zadanie. I teraz co jest bardzo ważne odnośnie do systemu Kanban, o czym najczęściej ludzie zapominają. System Kanban musi mieć wewnątrz siebie tzw. stany pasywne i aktywne, czyli musi mieć kolejki i stany aktywne. Wyobraźmy sobie taką sytuację, że programiści skończyli swoją robotę i od razu wrzucają do testing in progres. To w zasadzie mamy wewnątrz systemu pull- system push. Tak być nie może, więc musi być ready for testing. No i tak w kwestii formalnej musi być bardzo precyzyjnie określony początek i koniec systemu kanban tzw. commitment i delivery point. 

Metoda kanban służy w zasadzie do zarządzania całą firmą. Jest takie podejście w metodzie kanban, że wszystko jest serwisem w organizacji, na wejściu mamy smutną, niezadowoloną buźkę klienta a na końcu spełnia się potrzeby klienta i uszczęśliwia.

Kuba: Słychajcie, mówiłem, że z tych siedmiu znaczeń to takim czwartym znaczeniem słowa kanban jest kanban produkcyjny. Powiedzmy to jest ten, który wywodzi się Toyota Production system. Ten, którego autorem jest Taaichi Ohno legenda leana można powiedzieć.  To jest generalnie Kanban, który wykorzystuje systemy kanban oczywiście, ale do wytwarzania dóbr materialnych np. samochodów Toyota. Piąty kanban to jest metoda kanban. Twórcą metody kanban jest David Anderson i teraz ważne. To jest ogromna sprawa. Ludzie nie zdają sobie często sprawy, że metoda kanban jest gigantycznym obszarem wiedzy, gdzie w zasadzie sam system kanban jest tylko małą częścią. Metoda kanban służy do w zasadzie powiedział zarządzania całą firmą. I ciekawe w metodzie kanban jest takie podejście, że wszystko jest serwisem w organizacji, czyli na wejściu ma smutną buźkę klienta niezadowolona a na końcu gdzieś tam spełnia powiedzmy potrzeby klienta i uszczęśliwia i metoda kanban całą organizację widzi jako taką wielką sieć serwisów. No i właśnie służy do tego, żeby tą organizacje no ukanbanowić powiedzmy. I to jest taki bym powiedział meta Framework. I to jest bardzo ciekawe, bo np. Scrum jest po prostu frame workiem, gdzie mamy ustalone role, eventy, jakieś tam zasady. To metoda kanban mówi tak, że zbuduj sobie ten proces od samego początku. Nie powiemy jakie role masz mieć, możemy dać jakieś sugestie i powiemy Ci jakie eventy masz mieć, czyli pętle zwrotne. Damy Ci tylko jakieś sugestie, a ty to wszystko sobie zbuduj. My damy narzędzie, ale z czym skończysz, tego nie wiemy. No i kolejną taką odsłoną, kolejnym takim rodzajem kanbana jest tzw. Scrumban. To jest właśnie ciekawe, bo twórcy tego podejścia mieli takie założenie, że no tak wiecie musicie wiedzieć, że kanban University ze Scrumwork no tak za bardzo się nie lubiły nigdy. Niby teraz jest trochę jakaś odwilż, ale dalej nie jakoś kolorowo. W każdym razie podejście kanban University, było, że Scrum to jest taka dziecinada trochę, taki nieprawdziwy, niedojrzały powiedzmy proces zarządzania.  Ale jeżeli ktoś tego dobrego Scruma ma i chciałby zająć się zarządzaniem na poważnie, no to zaczyna tworzyć Scrumbana tzw., czyli kanbana, który wywodzi się ze Scrumu. Ja osobiście nie mam takiego podejścia, jak oni właśnie. Dla mnie Scrum czy kanban to po prostu dwa różne narzędzia, które czasami mogą dać po prostu gigantyczną wartości i nawet fajnie się łączą. Nie trzeba z jednego wychodzić, można stosować dwa od razu. W każdym razie w praktyce Scrumban to zazwyczaj coś innego oznacza niż autor miał na myśli. Jakby rynek przyjął to trochę inaczej. Jak ja słysze Scrumban o mojego klienta, to dla mnie to już wiem, że to będzie taki Frankenstein procesowy. Zaczęliśmy stosować Scruma i nie umiemy go tworzyć dobrze. Po miesiącu stosowania stwierdzamy, że już wiemy o nim wszystko, zaczynamy rozbierać na części pierwsze, a nie retro, po co retro. Nie róbmy incrementów na koniec sprintu, bo to niewygodne. No i co, tego kanbana zastąpimy tutaj, ale takiego scrumbana sobie niby połączymy, taką hybrydę zrobimy. Ale limity pracy w toku testem dla nas niewygodne no i w końcu mamy taki nonban troche, w sumie nic nie mamy. Ja bym porównał w ogóle wszelkiego rodzaju zwinność czy tam linowość do takiego systemu nerwowego. Tak, jakbyśmy położyli gorącą rękę na rozgrzany piec, to powinniśmy poczuć ból, powinien nas oparzyć ten piec. System nerwowy powinien dać nam sygnał, pentle zwrotną, że trzeba rękę oberwać. No i tak samo właśnie Scrum
i kanban powinny działać.  To są podstawowe właściwości tego systemu jednego i drugiego. Ten Scrumban często, tak pozwolę sobie stwierdzić, to taki wykastrowany system nerwowy. W zasadzie jest przyjemny, ale nic kompletnie nam nie daje. Nie Informuje nas, że robimy coś nie tak. No i teraz ostatni rodzaj kanbana o którym chciałbym powiedzieć, pewnie jeszcze pare by się znalazło, żeby to też było jasne. Ale to jest coś co całkiem niedawno Scrumwork stworzył. To jest Professionals Scrum with kanban. I teraz tutaj często są różne nieporozumienia. Niektórzy myślą, że to jakieś podejście bezoperacyje, ale to jest właśnie rodzaj Scrumbana. No właśnie nic bardziej mylnego. Professional Scrum with Kanban to jest stuprocentowy Scrum. Mamy 100% scruma i do tego dodajemy trochę okrojoną metodę kanban. Czyli mamy określone role, nie musimy tutaj ich układać od nowa, bo mamy Scrummastera, product ownera i deweloperów, wszystko co w Scrumie jest po prostu. Ale mamy dodatkowe metryki, dodatkowe diagramy, praktyki, coś co pozwala nam wejść na wyższy poziom zwinności.

Dla mnie Scrum czy Kanban to po prostu dwa różne narzędzia, które czasami mogą dać gigantyczną wartości i nawet fajnie się łączą. Nie trzeba z jednego wychodzić, można stosować dwa od razu. W każdym razie w praktyce Scrumban to zazwyczaj oznacza coś innego niż autor miał na myśli

Paweł: To Kuba powiedziałeś nam o rodzajach Kanbana i to była karta Kanban, tablica Kanban, system Kanban, Kanban produkcyjny, ten z Toyoty, metoda Kanban, Scrumban i profesional Scrum with Kanban.  To jakby powiedziałeś nam o tych rodzajach. Jaka jest według Ciebie charakterystyka. Czym się charakteryzuje Kanban. Myślę tutaj chyba o metodzie kanban prawa.

Kuba: Ja bym powiedział, że wszystkie mają jakiś taki pierwiastek wspóly. Przed nawias można dużo tutaj wyciągnąć.  Więc przede wszystkim powiedziałbym, że we wszystkich Kanbanowych podejściach, jakby przepływ jest religią. Tutaj jestem Bogiem. Właśnie dla mnie było zaskoczenie, że w tym kanbane linowym, nawet w metodzie kanban przepływ jest już na poziomie wartości. Czyli wartości, które wymieniamy to szacunek i przepływ, że to jest aż tak istotne, że wszystko w zasadzie traktujemy jak przepływ. To Jest też bardzo charakterystyczny mindset dla kanbanowców. Każdą pracę, zwłaszcza intelektualną, można przedstawić jako przepływ work itemów, przez flow, gdzie tam np. operujemy za pomocą tablicy. Po prostu wszystko w ten sposób widzimy. No i już wcześniej wspominałem właśnie, że wszystko traktujemy jak serwis, który można za pomocą systemu kanban napisać, czyli zaspokajanie potrzeb klienta. No i że ta organizacja składa się właśnie z tych sieci, nazwijmy to współzależnych serwisów.

Paweł: Chce Cię tu zatrzymać i zapytać o to, co można rozumieć pod pojęciem serwis. Bo w takim moim świecie, kiedy słyszę serwis, od razu myślę o mikro serwisie, czyli jest to jakiś faktycznie serwis, coś co spełnia jakąś funkcję, ale co ty masz na myśli mówiąc serwis?

Ten Scrumban często, tak pozwolę sobie stwierdzić, to taki wykastrowany system nerwowy. W zasadzie jest przyjemny, ale nic kompletnie nam nie daje. Nie Informuje nas, że robimy coś nie tak

Kuba: Wiesz co, znowu ten temat jest bardzo szeroki. Praktycznie wszystko, co po prostu spełnia czyjeś potrzeby w formie przepływu wartości.  Tak jakby systemowo patrząc. Jest System, który ma na wejściu potrzebę a na wyjściu wartość. Wszystko w zasadzie, HR jest serwisem mikro serwis jest serwisem, zespół scrumowy jest serwisem. CIO jest serwisem, cała firma jest serwisem. To jest też ważne, żeby uświadomić, że w tej organizacji jest ogromna ilość tych serwisów i jedne serwisy zasilają inne. Są równoległe serwisy, jeden serwis wewnątrz drugiego. Właśnie kanban stara się to pokazać, no i oczywiście usprawnić. Co jest tutaj ważne. Po to, głównie stosujemy właśnie te wszelkiego rodzaju systemy kanban, żeby dostarczać szybciej, więcej. Od razu się tutaj na chwilę zatrzymam. Szybciej i więcej to nie jest to samo. Możemy mieć ogromną ilość dostarczania zadań per miesiąc, ale te zadania np. dostarczajmy równo w miesiąc. Po prostu mamy batcha, czyli partię taką wielką. Możemy też zrobić tak, że dostarczamy np. tyle samo zadań w miesiąc, ale średnio zadanie wytwarzane krócej w czasie, czyli to są po prostu dwie różne rzeczy. O tym powiem jeszcze trochę później, ale często ludziom się to myli. 

Też jedną z największych zalet stosowania kanbana, po co my to w ogóle robimy, co jest charakterystyczne- to jest przewidywalność. Właśnie na poziomie dostarczania pojedynczego zadania, jak długo będzie dostarczone i jak dużo dostarczamy per sprint, per miesiąc, per tydzień itd.

Co Andersson się śmiał właśnie, że oni tam na retro gadają o uczuciach, się przytulają, podają sobie ręce, a my tu mamy konkretne miary. Więc tu trzeba powiedzieć, że kanban jest taki konkretny. Po inżyniersku, pomierzone, opieramy się na liczbach a nie przeczuciach np. żeby było jasne. Tak uważam, że Anderson przesadzania. Ale coś może w tym jest rzeczywiście, że kanban jest taki bardziej namacalny i kanban np.  Wprowadza statystykę. To mi się mega też podoba, że pozwala np. powiedzieć coś takiego: to zadanie na 50% będzie w 3 dni lub szybciej, na 95% 7 dni lub szybciej.  Nie to jest trochę konkretniejsze, niż takie podejście, no jak zrobimy, to tak zrobimy. Możemy np. mieć 100 zadań do wykonania, na kiedy będzie ten projekt np. no i jeżeli mamy dane historyczne, no to możemy powiedzieć, że 15 marca w 50% przypadków nasze symulacje pokazują 90%, no to już bardziej tam bliżej 1 kwietnia. No a 98% np. jakiś tam nie maj, czy coś takiego. Więc to jest bardzo fajny i charakterystyczne właśnie dla kanbana. No i kolejna kwestia, która byłaby dla kanbana charakterystyczna. Tu widzę ogromne podobieństwo do scruma właśnie. To jest nacisk na samą organizacji.  To Taichi Ohno twierdził właśnie w ten sposób, że budujmy przepływ tak, żeby ludzie mogli go sami stosować, żeby był bezobsługowy. Let people self organised and managed the flow, takie podejście. Więc to też jest bardzo charakterystyczne i jak wszelkie linowe podejścia, zwinne też oczywiście. Kanban bardzo mocny nacisk daje na zadowolenie klienta. To jest esencja, to nawet Anderson bardzo często powtarza, że jakby to powiedzieć, że nieważne jak szybko biegniesz, jeżeli biegniesz w niewłaściwym kierunku. Zarządzanie wartością biznesową, czyli product ownership, service ownership jest numero uno. To jest po prostu must have, musi to być. Te rzeczy są takie najbardziej charakterystyczne właśnie.

Paweł: To Kuba chyba chce Cie dopytać o jedną rzecz z tego co powiedziałeś. Kanban wprowadza statystyke i i pozwala lepiej przewidywać. Teraz myślę o takim świecie wytwarzania oprogramowania, gdzie te zadania są różnej wielkości, są czasem trudne do wystymowania, czasem są takim polem jeszcze nieeksploatowanym, czy kanban i w takich wypadkach potrafi się sprawdzić?

Kuba: No więc generalnie, jeżeli chodzi o Kanbana, ja bym powiedział, że on jest wręcz do tego stworzony, żeby właśnie w tym takim nieprzewidywalnym świecie trochę porządku wprowadzić. I tu bym takie pomocnicze pojęcie wprowadził.  Flow debt, czyli dług przepływu. Mówimy o długu technicznym, że robimy różne rzeczy, później musimy spłacać tak powiem braki jakościowe czy niedoróbki. Mamy też dużo czynników, które powodują, że nasz system staje się nieprzewidywalny, to właśnie ten Flow debt, że koniec końców za to zapłacimy kiedyś. System kanban pozwala nam właśnie zarządzić tym w ten sposób, żeby ten flow był bardziej przewidywalny, żeby ten flow debt właśnie minimalizować. Przykładowo, pozwala nam wprowadzić odpowiednie zarządzanie różnego rodzaju typami zadań, żeby wprowadzić powtarzalność. Nawet jeżeli pracujemy i iteracji, bo dużo osób myśli, że kanban zawsze beziteracyjny, nic bardziej mylnego, możemy pracować iteracjach, nawet sprintach. Chcemy, żeby każdy sprint był coraz bardziej podobny do siebie na poziomie właśnie przepływu. Wprowadzamy dodatkowe polityki, rodzaje zadań np. klasy serwisów tzw., w zależności od typu kosztu opóźnienia itd. odpowiednie polityki stosujemy, stosujemy powtarzalność. Tutaj wspominałeś też o rodzajach zadań. Też staramy się szukać tych rodzajów zadań o specjalnych charakterystykach i też możemy mieć np. dla określonego typu zadań statystykę na kiedy by to było. Niektórzy np. robiąc coś takiego, że prowadzą sobie własne histogramy na temat ilości Story pointów, że zadania z trzy story pointy, to zadania od-do najczęściej. Mimo wszystko też kanban zachęca do tego, żeby bardzo często, jakby mimo wszystko Unifikować te zadania, nie mówie, że zawsze się da, ale warto próbować. Czyli Ideał jest wtedy, gdy mamy zadania tej samej wielkości, przynajmniej tego samego typu nazwijmy. No bo wiadomo bugi są zawsze nieprzewidywalne, chociaż nieprzewidywalność też statystyka czasami chwyta. Bo kanban bym powiedział on tak łapie jakieś wzorce w rzeczywistości. Teraz może się okazać, że po prostu kanban nam pokaże, jaki mamy rozstrzelony system, może nam pozwoli stworzyć tutaj jakąś strategię, jak tutaj te zadania tak zbliżyć do siebie pod względem np. dostarczania. Też daje szereg strategii, np. pomaga nam zarządzać zależnościami pomiędzy serwisami to jest największe zło. Tutaj Scrum powiem szczerze w ogóle się wykłada kompletnie na łopatki. Musimy mieć cross funtional team i koniec po prostu inaczej to nie ma sensu. Kanban mówi, no fajnie, żebyśmy mieli no, ale nie mamy to rzeźby.  I też pomaga tutaj jakoś to jeszcze wszystko powiem ogarnąć. Ale też no umówmy się, nie ma tutaj jakby nie wiem. No tak powiem rozwiązań idealnych nie, ale przynajmniej tutaj trzeba powiedzieć, że ta przewidywalność, nawet jeżeli jest duży rozstrzał, to my to widzimy. Tutaj odwołałbym się do burndown charta tzw., Release Burndown churta, gdzie generalnie mamy np. prognozy, mamy ileś tam Story pointów do przepalenia no i np. product ownerowi wychodzi, że za 7 sprintów to będzie, ale co to znaczy, że za 7 sprintów będzie. To jest 5% prawdopodobieństwa? Może 8? A może 23,5? A może 72? Nie wiadomo, no to właśnie metoda kanban tutaj już dużo lepiej sobie z tym radzi. Nawet jeżeli mamy taki bałagan trochę bym powiedział, to powie nam, że mamy ogromny rozstrzał.  10%, że za tydzień 58% za 4 miesiące i nam to pokaże. Nas to powinno w oczy kłóć i od razu wtedy można coś usprawnić.

Paweł: Na dobra Kuba. Powiedziałeś nam, jakie są rodzaje kanbana powiedziałeś, czym się charakteryzuje kanban. Gdybyś teraz mógł nam opowiedzieć, jakie są praktyki wokół kanbana. Wiesz, to jest tylko wyłącznie ta tablica. Wspomniałeś już o histogramach, wspomniałeś o statystyce, chyba chce Cię zapytać o taką operacjonalizację kanbana, jak byś to zdefiniował.

Kuba: Więc generalnie wspominałem, że kanban jest takim podejściem nazwijmy, to zaczynasz z tym, co masz teraz i zaczyna go powoli sobie rozwijać, więc warto tutaj wspomnieć właśnie o tym jak się Kanbanem tutaj w ogóle, że tak powiem rozwija, jak się kanbanizuje organizację. Więc po prostu znajdujemy jakiś obszar, już o skalowaniu to nie będę mówił, niestety nie ma czasu, ale generalnie chodzi o to, że zaczynamy z tym co jest teraz i powoli tego kanbana zaczynamy rozwijać i zaczynamy stosować natychmiast. No ale umówmy się jasno, to nie jest tak, że ktoś wchodzi już po 3 sekundach w prognozy statystyczne. Tu trzeba niestety bardzo dużo porządku zrobić właśnie tutaj występuje takie pojęcie w kanbanie, jak praktyka, dosłownie jest takie słowo, które daje taki obszar, wokół którego ewolucyjnie się rozwijamy, tych obszarów jest 6. I taki pierwszy obszar, w którym zaczynamy w ogóle działać, kanbanizować.  Wizualizacja.

Moje doświadczenie konsultanta, podpowiada mi, że czasami wystarczy pokazać klientowi, że ma jakiś problem, zwizualizować, właśnie ten system nerwowy uruchomić, żeby go kłuło w oczy. To Już często jest rozwiązanie problemu. Więc wizualizacja często, to jest tablica, odpowiedni rodzaj zadań, pokazywanie, kto co robi, jakie jest obciążenie pracą.

Powiem wam szczerze, że klienci naprawdę często są zaskoczeni, że np. testerzy w jakimś zespole, no tak naprawdę nie robią pracy związanej tylko z tym projektem, tylko mają jeszcze wrzutek z 3 innych.  To jest nagle takie łał. Albo wizualizacja całego Upstreamu, skąd się wymagania biorą, tam czasami to jest po prostu bym powiedział czarna dziura. No i też limitowanie pracy w toku jest kolejnym obszarem i znowu niektórzy myślą, że na kolumnie można dodać limit i koniec. Słuchajcie to jest początek drogi, to wiele szerszy temat. Można limitować per osoba na dodatek, można limitować per cały system jest tzw. conwep. To bardzo fajnie się sprawdza np. w przypadku, kiedy klient nam nie odbiera roboty, możemy powiedzieć, dopóki czegoś nie odbierzesz, nie możesz czegoś dołożyć nowego zupełnie. Całość limitujemy, ze względu na osobę, na kolumnę, nawet możemy ze względu na klienta. Możemy też limitować zależne serwisy, że serwisy nie mogą naraz obsługiwać zbyt wielu np. innych serwisów, więc to jest temat szerszy. I bardzo istotną kolejną taką praktyką, jest aktywne zarządzanie przepływem. Mówiłem wcześnie, że kanban opiera się na samoorganizacji, więc najlepiej, żeby codziennie, cały serwis się spotkał i żeby sobie tak zarządzili tą tablicą. Tutaj taka praktyka od prawej do lewej, bo te tablice mają limit pracy w toku, więc musimy od prawej zaczynać, żeby po prostu zwalniać kolejne elementy. I zespół się zastanawia, co może dzisiaj zrobić, żeby najwięcej wartości dostarczyć, czyli np. może bugi krytyczne najpierw zacznijmy np. przepychać przez nasz system zamiast np. zaciągać nowych rzeczy. No i tutaj no myślę, że to chyba nie będę wchodził w jakieś szczegóły. Tak to mniej więcej wygląda z tym aktywnym zarządzaniem przepływu no i takim kolejnym obszarem, wokół którego budujemy kanbana, taką kolejną praktyką. To jest na budowanie polityk, zasad, że tak powiem procesowych w oryginale nazywa się make politics explicite.  Nigdy nie jak dobrze przetłumaczyć na polskim, lepiej nie będę nawet próbował. W każdym razie musimy cały proces zbudować, określić rolę, określić event, określić przepływ, definicję przepływu itd. itd. wartość biznesową jakoś tutaj ogarnąć. Trzeba to po prostu zrobić, to też ewolucyjnie robimy. To jest właśnie charakterystyczne, zaczynamy organizacji, gdzie jest powiedzmy silny Leadership, taki mikro menagmentowy, to od tego zaczynamy. Pracujemy w organizacji, gdzie są scrum masterzy, samoorganizujące się zespoły. No tak działamy, więc budujemy po prostu ewolucyjnie, rozwijamy te, że tak powiem polityki. Kolejną kwestią jest budowanie systemu empirycznego, zbudowanie pętli zwrotnych, feedback loop’ów tzw. po angielsku i znowu w Scrumie mamy te feedback loopy, np. już częściowo przynajmniej mamy inkrement, mamy eventy wszystkie, nie mamy np. reviev, retro itd. to tutaj trzeba wszystko od podstaw stworzyć. Tutaj metryki też mogą jakieś fajne być, które pokazują różne rzeczy, diagramy, tablice w ogóle, które informują nas kłują nas oczy jak robimy coś źle. Kolejną taką ostatnią szóstą praktyką jestimprove collaboratively, evolve experimentally, prawdziwy łamacz językowy trzeba przyznać.  Generalnie chodzi po prostu o to, że rozwój jest taki pewnego rodzaju, no ewolucyjny, ale bazujący na wiedzy, którą po drodze zdobywamy. Tutaj jest takie są przeciwne podejście niż scrum. Bo transformacja Scrum dąży do tego, żeby mieć scruma. Jesteśmy punkcie a gdzie nie mascruma, w punkcie b jesteśmy później na końcu transformacji, gdzie scrum jest. Kanban zakłada zaczyna z tym co teraz i nie wiesz z czym skończysz może skończyć ze scrumem, może skończysz z czymś przeciwnym wręcz do scruma. Więc tu jest takie bym powiedział Krokowe podejście i i często pętle zwrotne. Czyli taka meta zwinność na poziomie właśnie samego tworzenia procesu nie tylko produktu, czy tam usługi, tak to wygląda.

Kanban opiera się na samoorganizacji, więc najlepiej, żeby codziennie, cały serwis się spotkał i żeby sobie tak zarządzili tą tablicą. Tutaj taka praktyka od prawej do lewej, bo te tablice mają limit pracy w toku, więc musimy od prawej zaczynać, żeby po prostu zwalniać kolejne elementy. I zespół się zastanawia, co może dzisiaj zrobić, żeby najwięcej wartości dostarczyć

Paweł: Brzmi to bardzo zachęcająco.

Kuba: Mam nadzieję, że coś tutaj przekaże.

Paweł: To Kuba powiedziałeś nam sporo już o samym Kanbanie. Nasi słuchacze, jeżeli chcecie, żebyśmy rozwijali ten temat coś konkretnego co Kuba powiedział, to dawać nam znać i będziemy zapraszać do kolejnych odcinków, ale chyba teraz już tak troszeczkę zawijając do brzeg chciałbym Cię zapytać jaką wartość daje korzystanie z Kanbana.

Kuba: Więc ja bym powiedział, także już część rzeczy tutaj gdzieś tam wcześniej padło, więc trochę tak przywołam. Generalnie, przede wszystkim szybciej, więcej dostarczajmy tej wartości i przewidywalności. To już o tym mówiłem, ale trzeba tutaj powiedzieć, że też poziom zadowolenia pracowników bardzo często też wzrasta, bo ich praca staje się zbalansowana, zrównoważona, nie ma takiej sytuacji, że nie ma nic do roboty, a później napierdzielamy po godzinach. Jest wyrównanie systemu pracy trochę. Więc to bardzo sobie ludzie cenią. Myślę, że też poziom zadowolenia odbiorców usługi, czy tam produktu też wzrasta, bo z przewidywalnością to trochę powiązane. Generalnie jest większy nacisk, szybszy feedback, dzięki temu ten user czy tam steak holder, czy ktokolwiek jest odbiorcą tej wartości, zazwyczaj jest bardziej zadowolony, bo bardziej skupiamy się na potrzebach tej osoby. No i teraz tak jak mówiłem na poziomie całej organizacji, też kanban wprowadzany, więc wydaje się, że to się wiąże po prostu z oszczędnością kasy. Bardziej efektywnie wykorzystujemy to, co mamy, więc mniej jest np. nikomu niepotrzebnej roboty wykonanej, mniej jest takiej sytuacji, że magazynujemy, chomikujemy wymagania, bo może będą potrzebne. Mamy większą przewidywalność, więc już nie trzeba tak magazynować, chomikować.

To od czego się zazwyczaj w Kanbanie zaczyna to jest to, co mówiłeś w zasadzie. Po prostu zwizualizujmy to, co mamy. Następne kroki, to może być właśnie stworzenie systemu, ale właśnie dobra wizualizacja, to jest podstawa. Ta transparentność, żebyśmy zobaczyli, gdzie naprawdę jesteśmy.

Paweł: 300 zadań Work in Progress,

Kuba: Kiedyś miałem taką sytuacje. Mamy kanbana książkowego od niedawna, ile ten koleś ma na sobie zadań- 95. To tak czasami wygląda, więc tak nie powinno być, najlepiej by jedno miał.  Generalnie też inna kwestia, że zarządzanie firmą jest dużo łatwiejsze też. Nie chcę tutaj zaczynać tematu skalowania, bo to jest ogromny temat, ale nawet taki C-level ma łatwiej, bo to jest bardziej poukładane, widzi po prostu taki klocuszki, właśnie serwisy, które jakoś sobie tam pracują. Ma własny system kanban na poziomie np. portfeli produktów. Jest tam od razu po prostu przejrzyście, transparentność, dokładnie. Też umówmy się, jeżeli mamy rzeczywiście dobrze przygotowany samo zarządzalny proces, to mniej zarządzania potrzeba, tych oficerów, tych scrum masterów, product ownerów jest po prostu potrzebnych mniej. Po prostu na zagęszczenie, że tak powiem ludzi, którzy się uczciwą robotą zajmują, czyli kodują np. testują, taki żart, to jest po prostu większe.

Paweł: Ja mam takie doświadczenie z pracy z zespołami, z bycia członkiem zespołu, że często poczucie chaosu to jest coś, co często nawiedza różnych pracowników. Mam poczucie chaosu, mam poczucie, że jest jakoś za dużo i często to można rozbić zwykłą wizualizacją tego, co masz do zrobienia tego, co jest Work in Progress. Nawet wprowadzenie głupiego kanbana, tablicy najprostszej.To już jest ogromnym krokiem naprzód.

Kuba: Ja się całkowicie z Tobą zgadzam, absolutnie tak. Czasami wystarczy pokazać, iż ludzie sami sobie z tym poradzą. Tutaj bym jeszcze dodał, że fajnie wtedy od razu wykorzystać okazję, bo często ludzie najskuteczniej zaczynają działać, kiedy czują frustracja, to umówmy się tak jesteśmy skonstruowani, musi nas coś gryźć, żebyśmy rzeczywiście się ruszyli z kanapy w cudzysłowie, ale generalnie wtedy właśnie ludzie narzekają na chaos. Jak im Się to pomoże zwizualizować, często sami sobie tablicę, ten system kanban są w stanie stworzyć. Jest ogień po prostu motywacyjny wtedy też u nich, więc taka dodatkowa wartość.

Paweł: Gdyby ktoś z naszych słuchaczy chciał zacząć swoją przygodę z kanbanem albo może ustrukturyzować to, co mają do tej pory, to jak powinien być pierwszy krok?

Kuba: Pierwszy krok, taka piosenka chyba była. Chyba nawet najtrudniejszym pierwszym krokiem jest to, że potrzeba trochę pokory, żeby sobie uświadomić, że ma się jakiś problem, który chce się rozwiązać, ale to od czego się zazwyczaj w kanbanie zaczyna to jest to, co mówiłeś w zasadzie. Po prostu zwizualizujmy to, co mamy. Następne kroki, to może być właśnie stworzenie systemu, ale właśnie dobra wizualizacja, to jest podstawa. Ta transparentność, o której mówiłeś, że zobaczymy, gdzie naprawdę jesteśmy.  Możemy się bardzo zdziwić. Też często właśnie mam taki, że przełożeni narzekają na zespół, że jest leniwy, że się obija, nic nie robi tak jak powinien. Jak się później przyjrzy ich robocie, to jest kompletny bałagan. Więc trzeba to dobrze zwizualizować, pokazać im to i zaciągnąć ich razem i zbudować po prostu ten Flow krok po kroku. Stage odpowiednie, że tak powiem w przepływie i zacząć po prostu udrażniać. To są te pierwsze kroki, zanim zajmiemy się bardziej poważnymi kwestiami. I tutaj bym od razu przestrzegał wszystkich. Bo czasami nawet na szkoleniach z kanbana czasem widzę takie podejście, że ktoś np. nie chce dobrze zwizualizować roboty, a już wprowadza prognozy statystyczne, więc na wszystko przyjdzie czas. To jak w Karate Kid. Pan Miyagi mówił właśnie, zanim zacznie latać, naucz się chodzić. I tutaj jest podobne podejście, żebyśmy nie zaczynali z górnego c, bo to się może źle skończyć

Paweł: Dzięki Kuba za to wszystko co powiedziałeś. Mam poczucie, że ja sam dowiedziałem się bardzo dużo o kanbanie, i chyba to, co najbardziej we mnie w tym momencie rezonuje, to jest to, żeby zarządzać przepływem, a nie de facto pracą zespołów. Żeby zespoły były samo-organizujące się, ale zarządzać tym, co jest dookoła nich, tym takim środowiskiem. Ale gdybym miał Cie zapytać, co ty byś chciał podkreślić naszym słuchaczom z całej swoje wypowiedzi. Taka główna myśl z którą chciałbyś, żeby wyszli z tego odcinka, to co by to było.

Kuba: Chyba to, co zawsze powtarzam. Że kochajcie problem a nie rozwiązanie. Też bardzo bym przestrzegał przed takim podejściem, to teraz trochę znamy kanbana, czy tam teraz zanurzamy się super, poznajemy temat.  Dalej bym pamiętał po prostu o tym, że kanban, tak samo jak Scrum, tak samo jak wszystko, jest narzędziem, które może dać gigantyczną wartość, ale przede wszystkim musimy działać w punkt. Czyli chciałbym was zachęcić do tego, żeby zawsze ustalić jaki macie problem do rozwiązania.

Paweł: Dzięki Kuba, gdyby nasi słuchacze chcieli dowiedzieć się więcej o Tobie, skontaktować się z Tobą. Gdzie powinni zacząć szukać.

Kuba: Na Linkedinie występuje, pod nazwiskiem Drzazga Jakub Drzazga. No i też jestem Youtuberem, wyobraźcie sobie. Prowadzę kanał ,,zainspiruj mnie Kuba'', więc tam właśnie mówię o najróżniejszych kwestiach w dziesięciominutowych, takich treściwych moim zdaniem, odcinkach poruszam jakieś kwestie, związane właśnie ze zwinnością z linowością, zarządzanie procesem, produktem, Leadershipem, wszystko co mi się wydaje wartościowe.

Paweł: Ja nieustannie zachęcam też do odwiedzania naszego bloga zwinne organizację na stronie Deloitte.com. Zachęcam do ozwiedzania mediów społecznościowych, czy to Kuby, czy to naszych. Dajcie znać, co myślicie o tym odcinku. Jeżeli chcecie, żebyśmy rozwinęli jakiś temat, to również nam napiszcie. Na pewno z Kubą będzie jeszcze kolejny odcinek, na temat mierzenia w kanbanie. To już ustaliliśmy, ale być może skalowanie. Jeżeli jesteście tym zainteresowani, dawajcie nam znać.  Kuba, bardzo dziękuję za dzisiejszą rozmowę i do usłyszenia.

Kuba: Cała przyjemność po mojej stronie, do usłyszenia.

Paweł: Dziękuję za wysłuchanie. Ten i inne odcinki zwinnych organizacji, znajdziesz na stronie Deloitte.Com oraz na najpopularniejszych platformach podcastów, jak Apple Podcast’s czy Spotify. Jeśli chcesz otrzymywać powiadomienia o nowych odcinkach, zasubskrybuj nasz newsletter na Deloitte.Com/PL/subskrybcje.