Przewodnik po Kanbanie

Kanban jest strategią optymalizacji wartości poprzez optymalizację procesu, w którym ta wartość jest kreowana. A dokładniej poprzez optymalizację przepływu przez ten proces tego, co wartość przynosi.

W jaki sposób działa ta strategia objaśniają poszczególne rozdziały Przewodnika po Kanbanie (ang. Kanban Guide) i umieszczone w nich komentarze.

Przewodnik po Kanbanie (ang. Kanban Guide) stanowi praktyczną definicję Kanbana jako strategii i określa, jakie elementy są niezbędne, by poprawnie ją zastosować.

Istnieją metody i propozycje użycia strategii kanbanowej, które również posługują się nazwą Kanban, np. Metoda Kanban (ang. Kanban Method) – ta strona nie stanowi ich omówienia i nie odnosi się do nich.

Strategia to sposób postępowania, który ma doprowadzić do osiągnięcia jakiegoś ogólnego długoterminowego celu. Nie definiuje wprost procesu, nie wskazuje metody ani nie narzuca narzędzi, które mają być zastosowane. Określa natomiast zasady, wedle których proces będzie kształtowany oraz kryteria doboru metod i narzędzi. Nie określa konkretnych działań, ale wskazuje ich kierunki i cele, które działania te powinny pozwolić osiągnąć.

Skoro więc Kanban jest strategią a nie jedną konkretną metodą, frameworkiem, praktyką lub techniką, można posłużyć się nim równocześnie z użyciem różnych metod, frameworków, praktyk lub technik.

W praktyce oznacza to, że Kanban stanowi uzupełnienie procesu, jakim się posługujemy i nadaje kierunek naszym działaniom w tym procesie. To, jaki będzie sam proces, wynikać będzie z metod lub frameworków, jakimi się posługujemy.

Stąd również wniosek, że Kanban jest w istocie agnostyczny względem procesów, w których jest użyty jako strategia. I tak np. pozwala usprawnić działanie zwinne w metodach Agile (np. w Scrumie), ale sam przecież nie jest metodą zwinną, a jedynie strategią postępowania w ramach tych metod.

Długoterminowym celem strategii, jaką jest Kanban, jest optymalizacja przepływu wartości przez proces, w którym ta wartość jest wytwarzana. Wynika z tego kilka wniosków.

Po pierwsze, skoro Kanban optymalizuje przepływ wartości, kluczowe jest zadbanie, by to, co przetwarzane jest w procesie, było nośnikiem wartości. Najlepiej wyjaśnić to na przykładzie zespołu, który wytwarza produkt zaspokajający potrzeby klientów i użytkowników.

Nośnikiem wartości są np. wymagania (opisy potrzeb), których realizacja w formie nowych cech lub funkcjonalności produktu prowadzi do uzyskania tejże wartości (zaspokojenia potrzeb).

Natomiast nie jest nośnikiem wartości pojedyncze zadanie wykonywane przez jedną z osób w zespole, bo dopiero szereg takich zadań, ukończonych w określonej kolejności, skutkuje uzyskaniem nowych funkcjonalności lub cech produktu.

Po drugie, optymalizacja przepływu nie jest tożsama z jego maksymalizacją za wszelką cenę. Jeśli więc zespół buduje jakiś produkt i posługuje się w swoim procesie Kanbanem, to będzie dążył do jak najszybszego wytworzenia zmian w tym produkcie, ale nie kosztem obniżania jakości rozwiązań. Dzięki temu jest w stanie realizować szereg takich zmian przez długi czas bez konieczności rozwiązywania błędów i usuwania niedoróbek, a więc w ujęciu strategicznym zachowa zdolność do ciągłego kreowania wartości.

Po trzecie, Kanban nie określa, co jest wartością ani co powinno być jej nośnikiem w procesie. Zdefiniować muszą to użytkownicy Kanbana, a zależeć może to np. od tego, jaką metodą się posługują, jakie cele sobie stawiają, co właściwie robią, jaki jest ich proces itd. Z punktu widzenia strategii, jaką jest Kanban, skoro prace nad czymś się rozpoczynają, to znaczy, że to coś ma wartość – w przeciwnym razie nie byłoby robione.

Po czwarte, nośnik wartości (czymkolwiek on jest w danym procesie) przynosi faktyczną wartość dopiero w momencie, gdy proces jego obsługi (realizacji) się zakończy. Im szybciej taki nośnik przepłynie przez proces od jego rozpoczęcia do zakończenia, tym szybciej wartość zostanie wykreowana. Aby ten przepływ był szybki, nie powinien się zatrzymywać bez powodu, a jeśli się zatrzyma, należy dążyć do niezwłocznego usunięcia blokady. I w istocie na tym polega optymalizacja przepływu: na dążeniu do tego, by kreowanie wartości następowało jak najszybciej i bez przerwań.

Po piąte, skoro to, co realizowane jest z użyciem Kanbana przynosi wartość, co do zasady każda praca, jaka się rozpoczęła, powinna zostać ukończona. Zaleganie nośników wartości w nieskończoność w procesie powoduje, że wartość, którą można by uzyskać, nie zostanie w praktyce wytworzona. Rezygnacja z dalszych działań i usuwanie z procesu takich nośników wartości już po tym, jak prace nad nimi się rozpoczęły, również spowoduje, że potencjalnej wartości z nimi związanej nie uda się wykreować.

Po szóste, przepływ nośników wartości przez proces powinien wieść od rozpoczęcia tego procesu do jego zakończenia. Tym samym proces, w którym przewiduje się powroty do wcześniej ukończonych stanów procesu, jest daleki od optymalizacji i wymaga usprawnienia. Nie da się bowiem uzyskać wartości oddalając się od punktu zakończenia prac związanych z jej wykreowaniem.

I po siódme wreszcie, tak rozumiana optymalizacja przepływu wartości prowadzi do jednoczesnej optymalizacji samej wartości. Po prostu im płynniej wartość jest wytwarzana i im lepiej udaje się unikać marnotrawstwa, tym więcej korzyści w określonym czasie uda się uzyskać. Dlatego Kanban stanowi doskonałe uzupełnienie wszelkich metod, które nastawione są na kreowanie wartości (np. Scruma).

Kanban jako strategia wymaga posługiwania się opartym o wizualizację systemem wciągania pracy. Co to właściwie znaczy i dlaczego jest to niezbędne?

Wizualność wynika przede wszystkim z użycia tablicy kanbanowej, która przedstawia nie tylko proces (poszczególne stany w nim), ale również to, co w każdym z tych stanów w danym momencie się znajduje. Inaczej mówiąc, da się zobaczyć nad czym pracuje cały system (co już jest w procesie) i na jakim etapie jest kreowanie wartości dla każdej z tych robionych rzeczy.

Taka wizualizacja pozwala kontrolować ilość pracy, jaka wykonywana jest jednocześnie w procesie. Powinna też ujawniać, jak długo praca nad poszczególnymi rzeczami już trwa, bo to pozwala zobaczyć, czy następuje jakikolwiek progres (przepływ w stronę zakończenia procesu), czy też nie.

W szczególności, skoro Kanban jest strategią optymalizacji przepływu, każdy brak tego przepływu powinien być również widoczny – a więc zwizualizowany w jakiejś formie na tablicy kanbanowej.

System oparty o wciąganie pracy (ang. pull-based system) lub po prostu system wciągania pracy (ang. pull system) powstaje wtedy, gdy do procesu wciągane są nowe rzeczy do zrobienia tylko wtedy, gdy faktycznie możliwe jest rozpoczęcie prac nad nimi (stąd zresztą taka właśnie nazwa systemu). Inaczej mówiąc, to system zapobiegający rozpoczęciu nadmiernej liczby rzeczy na raz.

Ten system wciągania pracy jest kluczowy dla uzyskania przepływu wartości, bo możliwości wytwórcze każdego procesu i ludzi w niego zaangażowanych są zawsze ograniczone. Jeśli zostaną przekroczone, czyli jeśli rozpocznie się realizacja zbyt dużej liczby rzeczy na raz, praca może być wykonywana realnie tylko nad częścią z nich, a pozostałe będą czekać na dostępność ludzi i środków.

Każde zatrzymanie przepływu oznacza, że proces osiągania wartości zatrzymał się. Ten brak przepływu powoduje w najlepszym razie, że wartość pojawi się później, a być może konieczne będzie powtórzenie niektórych działań, jeśli przestój trwał na tyle długo, że coś istotnego się zmieniło. W najgorszym razie wartość nie pojawi się wcale, bo prac nie będzie się już dało ukończyć albo ukończone zostaną zbyt późno, by ich efekty generowały jakiekolwiek korzyści.

Dzięki skonstruowaniu systemu, który zabezpiecza się przed zalaniem nadmierną ilością pracy, proces realizacji tego, co już znajduje się w systemie, ma szansę posuwać się płynnie do przodu i trwać najkrócej, jak to możliwe. A to minimalizuje ryzyko, że z jakiegoś powodu prace zostaną zablokowane.

Podsumowując: wizualizacja umożliwić ma zarówno zbudowanie systemu wciągania pracy jak i aktywne zarządzanie przepływem rzeczy, które do procesu już zostały wciągnięte – tak, by minimalizować przestoje i usuwać potencjalne blokady.

Wartością jest każda korzyść, jaka wynika z wykonania pracy. Może więc tą wartością być wytworzenie nowej funkcjonalności jakiegoś produktu, może być rozwiązanie palącego problemu społecznego, może być to również uzyskanie wiedzy, która pozwoli na zrobienie czegoś, co do tej pory było niewykonalne.

Istnieje wiele metod, które skupione są na uzyskiwaniu wartości definiowanej na różne sposoby. Dobrym przykładem jest tu Scrum, którego wiele organizacji używa do wytworzenia produktów (oprogramowania, kampanii marketingowych, procesów biznesowych, leków itd.). W połączeniu ze wszystkimi takimi metodami strategia optymalizacji przepływu, jaką jest Kanban, może zostać użyta do zwiększenia uzyskiwanych korzyści, a także do podniesienia prawdopodobieństwa ich uzyskania.

Czy wartością może być sam fakt wykonywania jakiejś pracy? I czy można użyć Kanbana do optymalizacji przepływu w takim właśnie procesie? Procesie, który nie dba o to, jakie efekty przynoszą wykonywane działania, ale jedynie o to, by działania te były realizowane?

Formalnie tak, ale w praktyce to nie ma sensu. Pracę przecież wykonujemy zawsze po coś, a nie dla samego jej wykonywania. I to osiągnięcie tego czegoś (celu, dla którego praca jest wykonywana) jest zwykle źródłem wartości. Dlatego rozsądnie zastosowany Kanban nie będzie nigdy skupiony na optymalizacji samej pracy (np. na zadaniach wykonywanych przez różnych ludzi), ale na realizacji takich działań, które przynoszą wymierne korzyści (pozwalają osiągnąć wytyczony cel).

Trzy praktyki, o których tu mowa, muszą być użyte jednocześnie i uzupełniać się wzajemnie. Nie jest to zatem lista trzech rzeczy do jednokrotnego zrobienia w określonej lub dowolnej kolejności, po których ukończeniu uzyskuje się jakiś stan idealny procesu. Wręcz przeciwnie: nie istnieje coś takiego, jak stan idealny, jest jedynie ciągłe doskonalenie stanu bieżącego.

W jaki sposób praktyki łączą się ze sobą?

Dzięki wizualizacji i zdefiniowaniu przepływu pracy możliwe staje się identyfikowanie, co znajduje się już w procesie i czy następuje przepływ tych rzeczy w stronę uzyskania wartości. To pozwala dbać o utrzymanie przepływu i reagować na wszelkie problemy, które prowadzą do jego zaburzenia lub zatrzymania. A na tym właśnie polega aktywne zarządzanie tym, co już znajduje się w przepływie.

Dążenie do optymalizacji przepływu dotyczy nie tylko poszczególnych rzeczy, które przepływają przez proces, ale samego procesu, który może i powinien być udoskonalany. Definicja przepływu pracy i sposób jego wizualizacji pozwala poprawić widoczność stanu spraw i jasność obowiązujących w procesie zasad, a to ułatwia uzyskiwanie przepływu. Pozwala to również na dostosowywanie się do zmian, które następują z czasem i tym samym unikanie ich negatywnych skutków albo wykorzystywanie nowych możliwości.

Należy też pamiętać, że te trzy praktyki kanbanowe nie są jedynymi, jakimi najpewniej trzeba się będzie posłużyć. W zależności od tego, na jaki proces lub metodę nałożony zostanie Kanban jako strategia, różne praktyki mogą okazać się niezbędne. A jeśli staną się wymagane, to nie dlatego, że wymaga tego Kanban, ale ze względu na ten proces, który kanbanowo optymalizujemy.

Definiowanie i wizualizacja przepływu pracy ma na celu wykreowanie wizualnego systemu, o którym mowa jest w definicji Kanbana.

Warto zauważyć, że konieczna jest zarówno definicja jak i wizualizacja przepływu pracy (ang. workflow). To oznacza, że samo stworzenie tablicy kanbanowej nie uprawnia nikogo do twierdzenia, że posługuje się Kanbanem. Tablica jest prezentacją definicji workflowu, a nie całością tej definicji.

Wizualizacja nie kończy się na zaprezentowaniu bieżącego stanu systemu Kanban na tablicy kanbanowej, ale obejmować musi także miary przepływu.

Zarówno miary przepływu jaki i elementy, które składają się na definicję workflowu, omówione zostały w nastęnych komentarzach.

Ta praktyka to połączenie dbania o zapewnienie przepływu rzeczy, które znajdują się już w procesie, z budowaniem systemu wciągania pracy – czyli z chronieniem procesu przed zalewem nadmierną ilością pracy wykonywanej jednocześnie.

Dzięki temu ograniczone środki, możliwości ludzkie i czas mogą być optymalnie wykorzystane na wykonywanie pracy, która przynosi wartość oraz, jeśli to konieczne, na usuwanie blokad, które uniemożliwiają ukończenie takich prac.

Decyzje o tym, czy rozpocząć pracę nad jakąś nową rzeczą (wciągnąć ją do procesu) i nad czym skupić należy się najpierw, są właśnie implementacją aktywnego zarządzania pracą w toku. Oczywiście jest nią też wykonywanie czynności niezbędnych do uzyskania wartości w taki sposób, aby nie generować przestojów i marnotrawstwa.

Zbudowanie procesu idealnego, w którym już nie da się dokonać żadnych usprawnień, jest niemożliwe. Wraz z upływem czasu nieustannie pojawiają się rozwiązania, narzędzia, praktyki, technologie i ogólnie rozumiane możliwości, których wcześniej nie było, a których wykorzystanie pozwoli na poprawę procesu.

Sposób działania większości organizacji i zespołów daleki jest od ideału. Nie dlatego, że nie starają się działać jak najlepiej, ale ze względu na złożoność i nieprzewidywalność środowiska, w jakim funkcjonują. To oznacza, że potencjał dokonania usprawnień, które przyniosą wymierne korzyści, zawsze jest ogromny.

Kanban oparty jest o wizualizację nie tylko procesu, ale również i miar przepływu (opisane zostały w jednym z kolejnych rozdziałów). To pozwala lepiej zrozumieć, jak działa proces w chwili obecnej i zidentyfikować zmiany, które mogą spowodować poprawę przepływu albo wyeliminować różne jego ograniczenia. Czasami ujawni się również potrzeba udoskonalenia wizualizacji tak, by możliwy był lepszy wgląd w stan spraw i przebieg procesu.

Implementacja praktyk kanbanowych często nazywana jest procesem kanbanowym, ale to nie jest poprawne określenie. Kanban jest strategią optymalizacji, którą nakłada się na jakiś proces. Sam tego procesu nie definiuje (choć może na niego wpływać) i stanowi jedynie jego uzupełnienie.

Z drugiej strony mówienie po prostu o strategii kanbanowej też byłoby mylące, bo chodzi nam przecież o zastosowanie Kanbana (strategii) przez konkretny zespół i ludzi w nim pracujących, a nie o ogólne, oderwane od implementacji generyczne podejście.

Dlatego implementacja tych trzech praktyk nosi nazwę systemu Kanban (ang. Kanban system). W ten sposób, gdy mówimy o systemie Kanban, jest jasne, że odnosimy się do jednego określonego miejsca, gdzie Kanban został zastosowany, a jednocześnie nie sugerujemy niczego odnośnie do procesu, jaki w tym Kanbanie obowiązuje.

Kanban nie definiuje żadnych ról. Jeśli w zespole, który posługuje się Kanbanem, pojawiają się role, funkcje, specjalności, odpowiedzialności itd., zawsze wynika to nie z faktu używania Kanbana, ale z tego, jakim procesem posługuje się ten zespół.

To oznacza, że wszyscy, którzy pracują w ramach systemu Kanban nad wytwarzaniem wartości są po prostu członkami systemu Kanban (ang. Kanban system members).

Ten zapis niesie w sobie jeszcze jedną informację, która jest niepozorna, ale bardzo istotna: członkami systemu Kanban są tylko osoby, które pracują nad wytworzeniem wartości (czyli uczestniczą aktywnie w tym procesie i są jego częścią). Ktoś, kto wchodzi w interakcje z systemem Kanban, ale nie pracuje nad rzeczami, które realizowane są aktualnie w tym systemie, członkiem systemu Kanban nie jest.

Dlaczego ma to znaczenie? Bo tylko członkowie systemu Kanban decydują, jak wyglądać ma przepływ pracy (ang. workflow) i jakie zasady (ang. policies) w nim obowiązują. Nie jest więc poprawnym użyciem Kanbana sytuacja, w której o sposobie działania systemu Kanban decyduje np. jakiś kierownik liniowy stojący z boku.

Pojawić się może pytanie od użytkowników Scruma, czy to nie oznacza, że jeśli korzystają oni jednocześnie z Kanbana, to członkami ich systemu Kanban są zawsze jedynie Developerzy. Odpowiedź nie jest prosta, bo wszystko zależy od tego, co tak naprawdę system Kanban w przypadku każdego z takich Zespołów Scrum obejmuje. Jeśli wyłącznie pracę Developerów, wtedy ani Scrum Master ani Product Owner członkami takiego systemu Kanban nie są. Jeśli natomiast obejmuje pracę całego Zespołu Scrum, wtedy wszyscy w tym Zespole są również członkami systemu Kanban.

Oczywiście ktoś może teraz stwierdzić, że nad wytwarzaniem wartości w Scrumie pracują zawsze wyłącznie Developerzy, ale to dowodzić będzie jedynie błędnego rozumienia tej metody. Tak, prace developerskie wykonują jedynie Developerzy, ale na wytworzenie wartości składają się również decyzje, które w trakcie iteracji (czyli Sprintu) podejmuje Product Owner (np. jeśli ujawni się potrzeba zmiany niektórych wymagań). Składa się na to również sposób pracy, na który istotnie wpływać może Scrum Master. Dlatego nad wytworzeniem i dostarczeniem wartości w Scrumie w istocie zawsze pracuje cały Zespół, a jeśli się tak nie dzieje, to Scrum jest używany dość marnie.

Polskie tłumaczenie słowa flow, czyli przepływ, nie do końca oddaje kontekst, który niesie w sobie oryginał.

Jedna z anglojęzycznych definicji określa flow w ten sposób: the action or fact of moving along in a steady, continuous stream, czyli przepływ jest zjawiskiem przemieszczania się czegoś w formie stabilnego i ciągłego strumienia.

Dlatego polskie tłumaczenie wymagałoby powiedzenia, że chodzi o stabilny i nieprzerwany przepływ, a nie przepływ jakikolwiek. Jeśli więc mówimy po prostu o przepływie, nie zapominajmy nigdy o jego cechach (stabilności i ciągłości).

Systemem, o którym tu mowa, jest oczywiście system Kanban, którym jest zastosowanie strategii optymalizacji przepływu w konkretnym procesie, do którego wciągane są kolejne rzeczy, których realizacja przynieść ma wartość.

Dlaczego mowa jest o wartości potencjalnej, a nie po prostu o wartości? Przepływ przez system wiedzie od początku procesu do jego końca i wartość pojawia się dopiero po zakończeniu prac nad nią. Na każdym wcześniejszym etapie (w poszczególnych stanach procesu) mamy do czynienia jedynie z potencjałem uzyskania wartości, który rośnie w miarę, jak do zakończenia prac się zbliżamy. Tego, czy faktycznie wartość uda się wykreować nie wiemy, bo przyszłość zawsze pozostaje niewiadomą i możemy ją jedynie przewidywać.

Wart podkreślenia jest fakt, że po raz kolejny mowa tutaj o przepływie wartości, a nie po prostu o przepływie pracy. Praca jest wykonywana po to, by przepływ wartości następował – a bardziej po ludzku, by rzecz, której zrealizowanie przyniesie wartość, przesuwała się od początku do końca procesu w miarę, jak kolejne działania (praca) są wykonywane.

Optymalizacja przepływu prowadzi do optymalizacji wartości, ponieważ to, co wartościowe, wytwarzane jest w stabilnym procesie bez niepotrzebnych przerw. Brak przestojów pozwala uzyskać tę wartość najszybciej, jak to możliwe. Pozwala też uniknąć ponoszenia kosztów, jakie generowane są przez każdy przestój (kosztów magazynowania, ponownego wdrażania się w odłożony na półkę problem, odświeżania rozwiązania tak, by uwzględnić zmiany, jakie pojawiły się w trakcie przestoju itd.).

Oczywistym i kluczowym warunkiem dla takiej optymalizacji wartości poprzez optymalizację jej przepływu jest wciąganie do tego przepływu rzeczy, których realizacja przynosi wartość. To, w jaki sposób dokonać wyboru odnośnie do tego, co jest wartościowe, nie jest zdefiniowane w Kanbanie tylko w procesie, na który strategia kanbanowa jest nakładana.

Zarówno optymalizacja przepływu jak i wynikająca z tego optymalizacja wartości są zawsze ograniczone z jednej strony opłacalnością, a z drugiej strony ryzykiem, jakie może powodować podjęcie niektórych działań.

To oznacza, że przepływ jest na tyle ciągły i stabilny, na ile da się to realnie osiągnąć w określonym momencie. Stąd też wniosek, że zawsze możliwe jest jego udoskonalenie, do czego zresztą odwołuje się jedna z trzech kluczowych praktyk kanbanowych.

Próba uzyskania wartości za wszelką cenę, a więc zakończenia prac bez oglądania się na koszty i długofalowe skutki, najczęściej wiedzie do utraty wartości w przyszłości (jeśli to, co zostało wytworzone byle jak, okaże się bublem nienadającym się do użycia). Może też prowadzić do spadku możliwości utrzymania przepływu, a tym samym generowania wartości. Konieczność usuwania awarii, rozwiązywania błędów, poprawiania marnych rozwiązań itd., będzie dokładać członkom systemu Kanban pracy.

Strategia optymalizacji przepływu może zostać zwizualizowana jako trójkąt podparty w środku ciężkości. Jego wierzchołkami są skuteczność (ang. effectiveness), efektywność (ang. efficiency) i przewidywalność (ang. predictability), a optymalizacja polega na utrzymaniu trójkąta w poziomie tak, by nie spadł z podpory.

Na każdy z trzech wymienionych parametrów systemu Kanban (wierzchołków trójkąta) wpływ mają różne czynniki zmienne w czasie (wierzchołki te przesuwają się nieustannie). Dlatego nie da się zdefiniować jednego niezmiennego sposobu działania, który byłby stale odpowiedni (bo środek ciężkości trójkąta jest ruchomy) i dlatego też optymalizacja jest procesem ciągłym.

Bardzo często słowo effective tłumaczone jest na język polski jako efektywny, ale jest to nie do końca poprawna kalka brzmieniowa z języka angielskiego. Chodzi bowiem o zdolność do uzyskiwania właściwych (wartościowych) efektów działań, jakie są podejmowane przez członków systemu Kanban, czyli o skuteczność w działaniu. Dlatego effective lepiej tłumaczyć jako skuteczny.

Skuteczny przepływ pozwala uzyskać klientom (czyli tym osobom, na rzecz których pracuje system Kanban) to, czego potrzebują wtedy, gdy jest im to potrzebne. Nie wystarczy przecież wytworzyć właściwą rzecz, ale trzeba to zrobić w odpowiednim momencie.

Przy czym pamiętać należy o pozostałych dwóch parametrach, a więc efektywności (ang. efficiency) oraz przewidywalności (ang. predictability). Gdyby bowiem system Kanban skupił się na uzyskaniu maksimum skuteczności, zapominając o zapewnieniu równowagi wszystkich trzech parametrów, skutki będą opłakane.

Jeśli coś zostanie zrobione za wszelką cenę, aby przede wszystkim zdążyć na czas, być może punktowo uda się uzyskać wartość. Natomiast kiepskie wykonanie prac skutkować będzie spadkiem jakości rozwiązań, które sprawiać zaczną problemy przy wykonaniu kolejnych działań. W efekcie przewidywalność odnośnie do tego, co jest możliwe i zarazem możliwości planowania lub prognozowania gwałtownie spadną. Ostatecznie uderzy to w samą skuteczność, bo coraz trudniej będzie tak prowadzić pracę nad uzyskiwaniem wartości, by udawało się ją ukończyć wtedy, gdy jest to oczekiwane.

Równie mocno ucierpi na takiej strategii efektywność działań. Robiąc coś bez oglądania się na koszty i jakość, członkowie systemu Kanban nie będą dbać o stan narzędzi, nie będą przejmować się marnotrawstwem materiałów itd. Do tego wszystko, co zostało zrobione byle jak, potem często będzie musiało być poprawiane lub naprawiane, a więc będzie robione nie raz, a dwa razy.

A nawet, jeśli nie trzeba będzie tego przerabiać, marna jakość może negatywnie wpłynąć na koszt wytworzenia kolejnych zmian, których też już nie będzie dało się wykonać dobrze. Straconego czasu i zmarnowanych materiałów nie uda się odzyskać, a z czasem koszty takiego działania mogą przeważyć nad uzyskiwaną wartością.

Efektywny przepływ to taki, w którym środki, możliwości i czas wykorzystywane są w sposób optymalny z punktu widzenia organizacji pracy, obciążenia tą pracą poszczególnych osób, właściwego doboru narzędzi, dopasowania kompetencji do wykonywanych czynności, a także ekonomicznej opłacalności.

Brak efektywności może zatem prowadzić do kreowania marnych rozwiązań albo spowodować, że koszt ich wytworzenia przewyższał będzie uzyskaną wartość.

Dążenie do maksymalizacji efektywności za wszelką cenę nie będzie jednak opłacalne, ponieważ wpłynie to negatywnie na pozostałe parametry procesu: efektywność (ang. effectiveness) i przewidywalność (ang. predictability). W jaki sposób, skoro wydaje się, że efektywność jest mocno powiązana z dbaniem o jakość i dobre wykorzystywanie możliwości, a obie te rzeczy są przecież korzystne?

Faktycznie, wysoka efektywność może pozytywnie wpływać na proces, ale tylko do pewnego momentu. Np. jeśli ograniczamy ilość odpadów, jakie powstają przy produkowaniu czegoś, będzie to opłacalne, dopóki nie zaczniemy za wszelką cenę dążyć do całkowitego wyeliminowania odpadów. Jeśli jednak takiemu celowi podporządkujemy proces, ucierpi na tym skuteczność. Stanie się tak dlatego, że odkładać będziemy w czasie wykonanie pilnych działań tylko po to, by nie doprowadzić do choćby minimalnego zmarnowania materiałów.

Inny scenariusz to oczekiwanie na eksperta lub dostępność najlepiej dopasowanego narzędzia, połączone z brakiem przyzwolenia, by pracę wykonał ktoś o mniejszym doświadczeniu (czyli wolniej) lub niezbyt trafnie dobranym narzędziem. Gdy w końcu optymalnie wykonane przez eksperta rozwiązanie się pojawi, może być za późno, by uznać je za wartościowe.

Jeszcze inny przykład negatywnych skutków nadmiernego skupienia na efektywności to sytuacja zespołu, który tak planuje swoją pracę, by każdy wykonywał to, co potrafi najlepiej. Ponieważ nie istnieje możliwość, żeby w każdym momencie zapotrzebowanie na różne kompetencje odzwierciedlało idealnie rozkład tych kompetencji w zespole i dostępność posiadających je osób, w procesie pojawiają się częste przestoje. Skąd się biorą? Z konieczności oczekiwania na dostępność osób najlepiej przygotowanych do wykonania danej pracy. Można powiedzieć, że zamiast dążyć do zrobienia tego, co jest najbardziej potrzebne, zespół skupia się na robieniu tego, co najlepiej potrafi aktualnie zrobić. To zaś nie ma wiele wspólnego z dbaniem o skuteczność.

Warto zauważyć, że w tym ostatnim przykładzie w zespole pojawia się ponadto konieczność synchronizowania prac i będzie to na tyle złożone, że samo w sobie zacznie godzić w efektywność.

Czy dążenie do nadmiernej efektywności wpłynie negatywnie na przewidywalność? Owszem, choć nie zawsze od razu. Losowa niedostępność eksperta (lub narzędzia) wymuszać będzie zmianę kolejności działań w oczekiwaniu na jego pojawienie się. Podobnie jak dążenie do tego, by nie powstawały żadne odpady wymagać będzie oczekiwania do momentu, aż będzie dało się wykonać pracę tak, by niczego nie zmarnować – bardzo często nie wiadomo, jak długo.

Na koniec uwaga o charakterze językowym: jednym z powodów, dla którego lepiej tłumaczyć effective jako skuteczny niż jako efektywny jest to, że dzięki temu można uniknąć problemu z przełożeniem na polski słówka efficient, które też tłumaczone jest na nasz język jako efektywny. Zdarza się potem, że wiele osób uznaje (błędnie) efficiency i effectiveness za synonimy.

Przewidywalność nie jest tożsama z uzyskaniem pewności odnośnie do tego, jaka będzie przyszłość, ale z możliwościami sporządzania prognoz, które obarczone są akceptowalnym błędem (a mówiąc precyzyjnie, których prawdopodobieństwo potwierdzenia się jest wystarczająco wysokie).

Stabilny i ciągły przepływ jest w naturalny sposób bardziej przewidywalny niż proces, który zatrzymuje się losowo albo taki, w którym praca nie zawsze przepływa w kierunku uzyskania wartości. Co więcej, im przepływ jest stabilniejszy, tym zwykle bywa szybszy, a im jest szybszy, tym mniej czynników może spowodować jego zaburzenie lub zatrzymanie – bo ekspozycja na potencjalne czynniki zaburzające jest krótsza.

Mało tego: jeśli przepływ jest wystarczająco przewidywalny w odbiorze osób, dla których system Kanban kreuje wartość, to kiedy pojawia się pilna potrzebna, potrafią one powstrzymać się od wywierania presji na to, by rozpocząć pracę nad nią natychmiast. Dzięki prognozom i wspomnianej przewidywalności wiedzą, że wystarczy umieścić nową pilną potrzebę na początku kolejki rzeczy do zrobienia, a wtedy w zwykłym (ale przewidywalnym) trybie system Kanban wciągnie ją do procesu i w akceptowalnym terminie przetworzy, dostarczając wartość.

Dla odmiany brak przewidywalności skłaniał będzie do domagania się, by pilnym problemem zająć się natychmiast, skoro nie da się wiarygodnie określić, jak długo trzeba będzie na to czekać. W ten sposób system, który już jest niestabilny, jest destabilizowany jeszcze bardziej.

Wydaje się zatem, że dążenie do maksymalnej przewidywalności będzie zawsze korzystne. Ale tak nie jest, ponieważ wtedy ucierpi zarówno skuteczność (ang. effectiveness) jak i efektywność (ang. efficiency).

Dzieje się tak, bo dla uzyskania maksymalnej przewidywalności członkowie systemu Kanban zaczynają prowadzić coraz kosztowniejsze analizy i przygotowania do każdego działania, jakie podejmują. Dążą przy tym do tego, by po rozpoczęciu prac być na wszystko gotowym. To spowalnia moment zaczęcia tych prac (więc ciężko mówić o skuteczności) i podnosi koszt działania (jest więc nieefektywne).

Co więcej, bardzo często ta maksymalna przewidywalność jest pozorna i opiera się nie na faktycznej zdolności przewidzenia przyszłości, ale na przygotowanych na wszelki wypadek planach obsłużenia każdego prawdopodobnego wariantu rozwoju sytuacji. Większość z nich (a może i wszystkie) nigdy nie zaistnieje, ale czasu i kosztów poniesionych na przygotowanie się na nie odzyskać nie można.

Może też zdarzyć się i tak, że przewidywalność (jeszcze bardziej fasadowa) polega na wykonywaniu poczynionych wcześniej planów niezależnie od ujawniających się co i rusz czynników, które powinny spowodować zmianę tych planów. Następuje wtedy starannie zaplanowana katastrofa, bo to, co zostaje wytworzone w procesie, jest najczęściej pozbawione wartości (jest niewłaściwą rzeczą, zrobioną w nieodpowiednim momencie, ale zgodnie z planem).

Optymalizacja przepływu, a co za tym idzie optymalizacja wartości, którą generuje ten przepływ, uzyskiwana jest dzięki utrzymywaniu w równowadze trzech opisanych wcześniej celów, jakimi są skuteczność, efektywność i przewidywalność przepływu.

Żeby to było możliwe, konieczne jest szybkie reagowanie na wszystko, co wpływa na przebieg procesu, w tym na zmiany w otoczeniu systemu Kanban. Temu służyć mają wizualizacje, temu służą również miary kanbanowe, o których mowa w kolejnych rozdziałach i komentarzach.

Do tego potrzebne jest też aktywne zarządzanie tym, co już znajduje się w przepływie. I nie chodzi tu o zmuszenie członków systemu Kanban do wznowienia prac, jeśli uległy one zatrzymaniu, ale przede wszystkim o dbanie o to, by takie zatrzymanie nie następowało.

System Kanban nie funkcjonuje w próżni i sam też podlega zmianom (choćby dlatego, że tworzą go ludzie), dlatego utrzymanie równowagi między przewidywalnością, efektywnością i skutecznością wymaga dostosowywania się tego systemu do różnych czynników i sytuacji.

Jeśli będzie on całkowicie statyczny albo dostosowania będą zbyt opieszałe lub zachowawcze, na dłuższą metę uzyskiwanie przepływu stanie się utrudnione lub niemożliwe.

To oznacza, że nie da się z góry zaprojektować dobrze działającego systemu Kanban i po prostu używać go w tej ostatecznej formie. System Kanban jest żywym tworem, który podlega ciągłym udoskonaleniom.

W tym aspekcie istnieje pewne podobieństwo między Kanbanem (jako strategią) a empiryczną kontrolą procesu, która używana jest w metodach Agile. Dlatego też Kanban uznawany jest przez wiele osób za strategię działania zwinnego. Nie zawsze jednak jest to uprawnione.

Po pierwsze, Kanban może być zastosowany jako strategia optymalizacji przepływu również w takich procesach, które nie posługują się empiryzmem (a więc nie są zwinne). Z faktu posłużenia się Kanbanem nie wynika wtedy nagłe uzwinnienie procesu.

Po drugie, sposób wprowadzania udoskonaleń w systemie Kanban może, ale wcale nie musi korzystać z empiryzmu. Możliwe jest przecież dokonywanie usprawnień w dowolnym momencie i w dowolnym zakresie, bez zastosowania iteracyjnego sposobu realizacji tych usprawnień i bez wdrażania ich przyrostowo.

Oczywiście w przypadku użycia Kanbana w połączeniu z metodami zwinnymi (np. ze Scrumem) całkowicie naturalne staje się wykorzystanie ich iteracyjności i inkrementalnego podejścia do wprowadzania usprawnień również w systemie Kanban.

Na osobną uwagę zasługuje termin sustainable balance, czego odpowiednikiem w języku polskim jest trwała równowaga. Takie tłumaczenie nie niesie jednak w sobie dodatkowego przekazu, jaki zawarty jest w słówku sustainable, a które wskazuje, że chodzi nie tyle o jednorazowe uzyskanie trwałej równowagi, która potem niezmiennie trwa, ale zdolność do jej uzyskiwania w nieskończoność – odzyskiwania za każdym razem, gdy zostanie utracona w wyniku działania różnych czynników.

Ciężko wyobrazić sobie jakiekolwiek praktyczne ograniczenie w zastosowaniu Kanbana, ale można pokusić się o określenie kryteriów, jakie spełniać musiałby proces, którego nie da się połączyć z tą strategią.

Musiałby to więc być proces, który nie kreuje żadnej wartości i w którym celowo dąży się do tego, by żadne prace nie posuwały się do przodu.

Czy istnieją takie procesy? Każdy sam powinien poszukać odpowiedzi na to pytanie.

Istnieje spora szansa, że deklaracja, iż Kanban nie nadaje się do użycia w konkretnym zespole lub organizacji, dowodzi niezrozumienia tego, czym jest Kanban. Co więcej, da się obronić tezę, że zastosowanie Kanbana z każdym procesem ma szansę przynieść korzyści, a nie spowoduje negatywnych konsekwencji (o ile oczywiście to użycie Kanbana jest świadome i dobrowolne).

Dlatego wiele zespołów sięga po Kanban i łączy wykorzystywane metody ze strategią optymalizacji przepływu. Płynie też z tego wniosek, że Kanbana po prostu opłaca się, a wręcz trzeba znać, bo każdy wcześniej czy później się z nim zetknie.

Kanban wywodzi się ze środowiska IT (to skrót od anglojęzycznego terminu information technology, po polsku: technologia informatyczna). Jego pierwsi użytkownicy wytwarzali oprogramowanie. Nie oznacza to natomiast, że jakkolwiek ograniczony jest do tej domeny. Niewykluczone zresztą, że obecnie popularność Kanbana jest większa poza IT niż wśród zespołów budujących oprogramowanie.

Przy czym zawsze warto mieć na względzie, że wiele zespołów deklaruje posługiwanie się Kanbanem, jednocześnie ograniczając się tylko do stworzenia jakiejś tablicy i zwizualizowania na niej tego, nad czym pracują. A bez dążenia do optymalizacji przepływu i zaimplementowania praktyk kanbanowych nie jest to w ogóle Kanban.

Koniecznie trzeba też pamiętać, że sięgnięcie po Kanban nie implikuje konieczności rezygnacji z używanych metod (procesów, frameworków). Kanban uzupełnia je, dokładając do nich strategię optymalizacji przepływu. Oczywiście wpłynie ona na sposób pracy zespołu, ale właśnie o ten wpływ i wynikające z niego korzyści chodzi.

Wspomniane w wybranym fragmencie praktyki kanbanowe to wizualizacja przepływu pracy, aktywne zarządzanie rzeczami znajdującymi się w przepływie oraz udoskonalanie tego przepływu. Istnieją różne sposoby implementacji tych praktyk i konkretne narzędzia, po jakie można sięgnąć – przy czym ich wybór zależy od specyfiki każdego systemu Kanban i dokonywany powinien być indywidualnie przez jego członków.

Każde z wymienionych tu pojęć (teorii, podejść i zasad postępowania) obrosło na przestrzeni lat różnymi narzędziami i jest z nimi kojarzone. Niestety bywa też często z nimi utożsamiane, co skutkuje przekonaniem, że skoro zespół lub organizacja posługuje się takim czy innym narzędziem, to automatycznie stosuje też kojarzone z nim praktyki i podejścia. Ten automatyzm w praktyce nie ma nigdy miejsca.

Dokładnie z tym samym zjawiskiem można zetknąć się wśród osób deklarujących użycie Kanbana: dla wielu z nich świadczy o tym sam fakt posługiwania się tablicą kanbanową. Tymczasem tablica jest jedynie częścią całej strategii.

Jedna z teorii wymienionych w przytoczonym powyżej fragmencie tekstu jest szczególnie istotna, a mianowicie teoria kolejek (ang. queuing theory). Chodzi przede wszystkim o należące do niej prawo sformułowane przez Johna Little’a. Prawo to powiada, że średnia liczba rzeczy lub klientów w każdym systemie (L) jest równa iloczynowi średniej częstotliwości ich przybywania do systemu (λ) oraz średniego czasu ich przebywania w tym systemie (W):

L ＝ λ × W

Przy pewnych założeniach (dobry ich opis zawarty jest w książce Daniela Vacantiego Actionable Agile Metrics for Predictability) można posłużyć się nieco wygodniejszą formą tego prawa, w myśl której średni czas cyklu (CT) jest wprost proporcjonalny do średniej ilości pracy w toku (WIP), a odwrotnie proporcjonalny do średniej przepustowości (TH):

CT ＝ WIPTH

Czas cyklu (ang. cycle time), ilość pracy w toku (ang. work in progres, w skrócie WIP) oraz przepustowość (ang. throughput) to trzy z czterech podstawowych miar przepływu, które opisane są w dalszej części Przewodnika po Kanbanie (ang. Kanban Guide).

Dlaczego prawo Little’a jest tak istotne? Otóż podpowiada ono, jaki wpływ ma liczba rzeczy, które realizowane są równocześnie, na średni czas ich przejścia przez proces. Średnia przepustowość jest odzwierciedleniem możliwości wytwórczych procesu (albo po prostu systemu Kanban) i jest dość stała w czasie, a w każdym razie nie da się jej gwałtownie zwiększyć. Jeśli więc zaczyna rosnąć liczba rzeczy realizowanych równocześnie, wydłużać się zacznie czas potrzebny na wykonanie prac nad nimi i opóźni się uzyskanie wartości.

Oczywiście jest to prawo wartości średnich, czyli mówi o globalnym wzajemnym wpływie poszczególnych parametrów uwzględnionych w tym prawie, ale nie podpowiada, ile potrwa praca nad jedną konkretną rzeczą.

Trzeba też pamiętać, że poza liczbą rzeczy realizowanych równocześnie na proces wpływa mnóstwo innych czynników. Nie ma więc żadnego automatyzmu, który podpowiadałby, że jeśli zmniejszymy średni WIP to na pewno spadnie średni czas cyklu, ani że zwiększenie WIP‑u ten czas wydłuży. Tak stałoby się jedynie w idealnym procesie, którego funkcjonowanie zależy wyłącznie od trzech parametrów uwzględnionych w prawie Little’a.

Użyteczność tej teorii nie wynika więc z możliwości wyliczenia czegokolwiek za pomocą formuły matematycznej, ale z ujawnienia istotnej zależności pomiędzy kluczowymi parametrami procesu. Wciąganie do procesu kolejnych rzeczy do zrobienia bez ograniczenia ich liczby będzie skutkować tendencją do wydłużania się czasu niezbędnego do ukończenia każdej z tych rzeczy.

Prawo Little’a czyni też widocznym powód, dla którego niezbędne jest kontrolowanie ilości pracy w toku (liczby rzeczy, jakie już znajdują się równocześnie w procesie), a tym samym stworzenie omawianego wcześniej systemu wciągania tej pracy (ang. pull system). Celem jest skrócenie czasu procesowania każdej z realizowanych rzeczy tak, by zminimalizowane zostało ryzyko, że zatrzyma się jej przepływ. Jednocześnie daje to korzyść w postaci szybszego uzyskania wartości (którą przynosi zakończenie prac) oraz podniesienia przewidywalności (bo rośnie stabilność procesu).

Kanban nigdy nie funkcjonuje w próżni, a to oznacza, że wpływ na niego będzie miała zmienność środowiska i samych ludzi, którzy tworzą system Kanban. Nie da się więc dokonać jednej daleko idącej optymalizacji przepływu i od tego momentu cieszyć się na stałe jej skutkami. Nawet gdyby chwilowy stan idealny udało się osiągnąć, bardzo szybko stan ten przeminie.

Dlatego Kanban wymaga nieustannego zabiegania o to, by przepływ utrzymać i by utrzymywać samą zdolność uzyskiwania przepływu. A tam, gdzie to możliwe, wprowadzać należy udoskonalenia. Ten proces nigdy się nie kończy i nie ma żadnego stanu docelowego, który dałoby się z góry zdefiniować.

Udoskonalanie systemu Kanban ma na celu optymalizację sposobu, w jaki uzyskiwana jest wartość, a tym samym optymalizację samej wartości (czyli uzyskanie maksymalnej wartości, jaką w aktualnych warunkach da się wykreować).

Natomiast Kanban ani nie jest jedyną strategią, jaką można się do tego posłużyć, ani nie daje gwarancji, że posługując się nim faktycznie to optimum osiągniemy. I to nawet wtedy, gdy użyjemy Kanbana naprawdę dobrze.

W szczególności sam Kanban nie podpowiada, jak wybierać do zrobienia te rzeczy, które przyniosą wartość. Tym samym często konieczne będzie połączenie Kanbana z innymi strategiami, np. takimi, które sterować będą wspomnianą selekcją.

Nasuwającym się przykładem jest rodzina metod Agile, w tym najbardziej znany framework będący jej przedstawicielem, czyli Scrum. Ale równie dobrze można Kanbana używać w połączeniu np. z Leanem, z którego zresztą historycznie Kanban się wywodzi.

Wspomniana augmentacja (albo suplementacja) nie wymaga nigdy zmiany oryginalnych metod i frameworków, do których Kanban jest dokładany. Wtedy bowiem już nie byłaby to augmentacja, ale raczej modyfikacja lub mutacja, prowadząca do wytworzenia zupełnie nowego podejścia, sposobu pracy, metody czy frameworku.

Możliwość dodania Kanbana, a przede wszystkim praktyk kanbanowych, do różnych metod wynika wprost z faktu, że Kanban jest strategią. Nie narzuca więc żadnych konkretnych zdarzeń procesowych, ról, odpowiedzialności, artefaktów ani innych elementów. Nie wymaga też zmiany żadnej z takich rzeczy, jeśli są one wymagane przez proces, na który Kanban jest nakładany.

Kanban nie wymaga też modyfikacji oryginalnej definicji elementów metod, z którymi jest łączony (np. przedefiniowania ról, artefaktów, zdarzeń itd.). Wpływał będzie na sposób implementacji tych rzeczy, pozostając w zgodzie z ich definicjami. Dlatego np. użycie Kanbana w połączeniu ze Scrumem nie wymaga odejścia od pracy w iteracjach (Sprintach), ale wpłynie istotnie na sposób organizacji działań Zespołu Scrum w ramach takich iteracji.

W literaturze i w rozlicznych materiałach w Internecie łatwo spotkać się z tezami, że użycie Kanbana wyklucza stosowanie takiej czy innej metody (znamiennie najczęściej Kanban bywa stawiany w kontrze do Scruma). Te stwierdzenia są zwykle nieuprawnione, a w przypadku Scruma kompletnie bezsensowne.

Każdy Zespół Scrum, który będzie dążył do podniesienia swej skuteczności, wypracuje w końcu samodzielnie praktyki kanbanowe, nawet jeśli o nich wcześniej nie słyszał. I w drugą stronę: każdy dojrzały system Kanban, który zajmował się będzie rozwojem produktu w złożonym środowisku, zacznie posługiwać się w końcu empiryzmem i procesem podobnym do Scruma, by sobie z niestabilną złożonością radzić.

Szkoda jednak czasu na samodzielne wymyślanie koła i lepiej zapoznać się z dostępnymi już metodami i podejściami, by wybrać spośród nich te, które mogą pozytywnie wpłynąć na skuteczność działania konkretnej organizacji lub zespołu.

Należy pamiętać, że chodzi o przepływ wartości, a nie przepływ pracy jako takiej. Przykładowo, jeśli system Kanban obejmuje rozwój jakiegoś produktu lub usługi, to nośnikiem wartości w tym systemie nie będzie raczej pojedyncze zadanie (konkretna czynność) wykonywane przez jedną lub kilka osób, ale np. wymaganie, problem lub potrzeba, czyli to, z czego konieczność wykonania zadania (czynności) wynikała.

Oczywiście przepływ przez proces wymaga wykonywania różnych prac, ale o zaistnieniu tego przepływu nie powinien świadczyć sam fakt wykonania pracy, tylko przybliżenie się dzięki temu do uzyskania wartości (korzyści).

I tak jeśli np. aby wykreować rzecz wartościową trzeba zrobić sto czynności, to z samego wykonania pięćdziesięciu z nich niekoniecznie wynika wniosek, że uzyskiwanie wartości jest na półmetku. Równie dobrze mogło się jeszcze nawet nie rozpocząć, a czynności, jakie zostały na początku zdefiniowane i zaplanowane, są zbędne i prowadzą w złą stronę.

Natomiast jeśli w wyniku jakiejkolwiek liczby wykonanych zadań rozwiązanie uzyska jakiś określony stan (np. jest już zbudowane i wymaga sprawdzenia, czy poprawnie działa), to faktycznie nastąpiło przybliżenie się do uzyskania wartości.

Sama wiedza o tym, jak zdefiniowany jest przepływ w konkretnym systemie Kanban, nie wystarczy. To, że ludzie wiedzą, jakie coś jest, nie gwarantuje, że rozumieją, dlaczego to coś takie jest. A bardziej precyzyjnie: nie zapewnia, że to zrozumienie u każdego z nich jest takie samo.

Bardzo często zdarza się przecież, że grupa ludzi posiada identyczne informacje, ale wyciągają z ich analizy zupełnie rozbieżne wnioski. Definicja przepływu pracy w systemie Kanban musi więc być stworzona w taki sposób, by ograniczyć ryzyko rozbieżnego interpretowania obowiązujących w systemie zasad, ale też by zmniejszyć do minimum konieczność dokonywania takich indywidualnych interpretacji.

Dlatego też wszelkie zasady (ang. policies) powinny być jawne i na tyle proste, by ich zastosowanie nie wymagało przeprowadzania skomplikowanych analiz. Nie może też tych zasad być zbyt wiele, bo wtedy rośnie ryzyko, że nie wszystkie będą realnie stosowane.

Najlepiej przy tym zadbać, by każda zasada wynikała z konkretnej potrzeby, jaką zidentyfikowali członkowie systemu Kanban lub z jasnego celu, jaki dzięki tej zasadzie chcą oni osiągnąć. Przyjmując, że są to ich własne potrzeby lub cele, a nie zostały narzucone przez kogoś spoza systemu, trzymanie się takich zasad będzie dla każdego czymś naturalnym i oczywistym.

Anglojęzyczny termin workflow w ogóle nie odwołuje się do wartości (ang. value), choć Kanban, w którym workflow jest bardzo istotnym elementem, to strategia optymalizacji przepływu wartości. Skąd więc ta niespójność?

Tak naprawdę żadnej niespójności nie ma. Faktycznie, słowo workflow wywodzi się z połączenia słów flow oraz work (po polsku to przepływ oraz praca), ale nie jest tożsame z frazą flow of work (po polsku byłoby to płynięcie pracy). Nie chodzi w nim o płynięcie pracy, bo praca jest wykonywana i donikąd nie płynie, to nie łódka. Chodzi o przepływ czegoś, nad czym wykonywana jest praca, przez poszczególne etapy, na jakie ta praca jest rozłożona.

Tym samym praca jako taka jest statyczna i w żaden rejs się nie wybiera, ale jednocześnie jest jakiś porządek (kolejność) w jej wykonywaniu tak, by od rozpoczęcia przybliżać się do zakończenia. Np. wytworzenie jakiegoś złożonego przedmiotu wymaga zrealizowania różnych czynności (wykonania pracy) na różnych stanowiskach lub maszynach, ale to nie ta praca płynie, tylko przedmiot przechodzi poprzez kolejne stanowiska. To ten przedmiot jest nośnikiem wartości, a praca stanowi narzędzie, dzięki któremu wartość powoli jest podnoszona w ramach przepływu od rozpoczęcia działań do ich zakończenia.

Dlatego nie należy wyciągać wniosku, że skoro w Kanbanie mamy do czynienia z czymś takim jak workflow, to jego podstawowym elementem musi być opis pracy w postaci zadań (ang. tasks). Nie, nie musi, a nawet nie powinien być, z wyjątkiem mocno teoretycznej sytuacji, gdy sam fakt wykonywania jakiejkolwiek pracy w określonej kolejności jest uznawany za wartość.

A co z polskim tłumaczeniem słowa workflow, czyli terminem przepływ pracy? Nie jest ono najlepsze, bo stanowi jednocześnie przekład frazy flow of work. Spopularyzowane zostało jednak tak bardzo, że nikłe są szanse, by wyparł je jakikolwiek inny termin. Nikt zresztą nie zaproponował lepszego tłumaczenia.

Na szczęście workflow doskonale deklinuje się w języku polskim (workflow, workflowu, workflowem itd.), więc można posłużyć się tym słowem, o ile ktoś nie jest purystą językowym ani nie pisze prac naukowych, w których kwestia terminologii ma kluczowe znaczenie.

Nie chodzi tu o sposób definiowania tych pozostałych (obok definicji workflowu) elementów, ale o sposób ich użycia w konkretnym systemie Kanban.

Np. sposób obliczania czasu cyklu (jednej z miar kanbanowych) zależy wprost od tego, gdzie w definicji workflowu zaczyna się praca nad uzyskaniem wartości i w którym momencie się ona kończy.

Nie ma też żadnej globalnej instrukcji, w jaki sposób czas cyklu mierzyć w każdym systemie Kanban, ale jest jedna definicja tego, czym czas cyklu jest jako miara. W ten sposób, posługując się zarówno definicją miary jak i definicją konkretnego workflowu, da się wartości czasu cyklu ustalić.

Żaden z wymienionych elementów nie jest opcjonalny, jeśli chcemy mówić o posługiwaniu się Kanbanem jako strategią. Szybki rzut oka na listę powinien ujawnić, dlaczego samo stworzenie tablicy kanbanowej nie wystarczy – to realizacja zaledwie jednego z sześciu elementów, o jakie bezwzględnie musimy zadbać.

Skąd bierze się akurat taki zbiór minimalny? Bez niego nie będzie możliwe zarządzanie przepływem:

• Bez określenia, co właściwie przepływać ma przez workflow, nie da się określić żadnego innego elementu definicji workflowu. Skoro definicja ta opisuje proces i obowiązujące w nim zasady, musi być jasne, czego ten proces w ogóle dotyczy.
• Żeby zarządzać przepływem, trzeba wiedzieć, co już znajduje się w tym przepływie, co jeszcze nie zostało wciągnięte do niego, a dla jakich rzeczy przepływ się już zakończył. Dlatego potrzebne są punkty rozpoczynania i kończenia workflowu.
• Żeby zaobserwować przepływ lub zauważyć jego brak i zareagować na to zatrzymanie, musi być możliwe ustalenie stanu, w jakim każda rzecz w procesie się znajduje w danym momencie. W szczególności to pozwoli zidentyfikować początek i koniec tego procesu.
• Aby zbudować system wciągania pracy (ang. pull system) konieczne jest kontrolowanie ilości pracy w toku (ang. work in progress, w skrócie WIP) tak, by liczba rzeczy realizowanych jednocześnie nie była zbyt duża i by możliwy był ich przepływ. Musimy więc ustalić, w jaki sposób będziemy kontrolować WIP. Uwaga: nie chodzi tu o samo sprawdzanie, jaki jest WIP, ale o dynamiczne kontrolowanie go tak, by nie stał się zbyt duży.
• Abyśmy wiedzieli, w jakim faktycznie stanie dana rzecz aktualnie się znajduje, musimy znać warunki przepływu pomiędzy stanami i kolejność, w jakiej te stany występują w procesie.
• Aktywne zarządzanie pracą w toku (WIP‑em), czyli jedna z praktyk kanbanowych, wymaga szybkiego identyfikowania tych rzeczy, których optymalny przepływ jest zagrożony. Można to zrobić porównując czas trwania nieukończonej pracy z prognozą oczekiwanego czasu jej ukończenia (a więc z service level expectation, w skrócie SLE).

Czym dokładnie jest SLE i jak kontrolowany może być WIP wyjaśniają kolejne rozdziały i zawarte w nich komentarze.

W ramach jednego systemu Kanban możliwe jest posługiwanie się jednocześnie różnymi typami jednostek wartości. Przykładowo, jeśli Kanban używany jest jako strategia w Scrumie, Zespół Scrum może potraktować jako jednostki wartości zarówno poszczególne elementy Backlogu Produktu (ang. Product Backlog Items, w skrócie PBI), jak i np. błędy zgłaszane przez użytkowników produktu.

To, że proces dla poszczególnych typów jednostek wartości może być różny, nie oznacza od razu, że nie mogą one być obsługiwane w ramach jednego systemu Kanban. Oczywiście wymaga to takiej definicji workflowu, która uczyni te różnice czytelnymi i zapobiegnie błędom decyzyjnym oraz nieporozumieniom.

W ramach niektórych systemów Kanban jednostki wartości są dzielone na różne klasy obsługi (ang. classes of service), czyli kategorie, które różnią się najczęściej priorytetem (a więc i oczekiwanym czasem realizacji). To powoduje, że występować zaczyna pewna hierarchia ważności lub pilności pomiędzy jednostkami wartości.

Nieuchronnym skutkiem istnienia takich klas obsługi jest uzyskanie szybkiego przepływu niektórych jednostek wartości kosztem jego spowolnienia dla innych. Może to być pożądane i korzystne w specyficznych sytuacjach, ale kłóci się mocno z ideą optymalizacji przepływu. Dlatego też klasy obsługi nie są częścią definicji Kanbana tylko opcjonalną praktyką.

Inną taką praktyką jest definiowanie tzw. szybkiej ścieżki w systemie Kanban (ang. expedite lane), którą może przepływać w ściśle określonych warunkach wybrana jednostka wartości, omijając wszystkie inne, które wcześniej znalazły się w procesie. Oczywiście wymusza to często sztuczne zatrzymanie przepływu tych omijanych jednostek, dlatego użycie szybkiej ścieżki jest niezalecaną praktyką i nie stanowi części definicji Kanbana.

Termin jednostka pracy (ang. work item) odnosi się do jednostki wartości, dlatego nazwa ta może być myląca i prowokować do utożsamiania work itemów po prostu z zadaniami do wykonania. Oznacza on jednak niezmiennie jednostkę wartości, która przyniesie korzyść, jeśli wykonana zostanie praca niezbędna do przejścia tej jednostki przez proces od jego rozpoczęcia do zakończenia.

Nie jest to zapewne najszczęśliwszy wybór nazwy, ale jest ona tak głęboko ugruntowana w historii Kanbana, że istnieje nikłe prawdopodobieństwo możliwości zastąpienia work itemu innym terminem.

W języku polskim pojawia się dodatkowa trudność, ponieważ dwa terminy mocno od siebie różniące się, czyli work item i unit of value nazywane są odpowiednio jednostką pracy i jednostką wartości. Wynika to z przyjęcia, że item to jednostka w polskojęzycznej literaturze dotyczącej Kanbana. Zdecydowanie lepiej byłoby mówić o work itemie jako o elemencie pracy, ale mało kto posługuje się tym terminem.

Dlatego, o ile ktoś nie jest purystą językowym i nie tworzy prac naukowych na temat Kanbana, może lepiej posłużyć się spolonizowanym work itemem, odmieniając go przez przypadki.

Czym właściwie jest punkt rozpoczęcia i zakończenia workflowu? Wydaje się, że chodzi tu o wskazanie stanu (ang. workflow state), od którego proces się rozpoczyna, oraz stanu, na którym proces się kończy. Cóż, niezupełnie tak, a właściwie zupełnie inaczej.

Wyobraźmy sobie proces, w którym zdefiniowane są zaledwie trzy stany jednostek pracy: do zrobienia, w trakcie oraz zrobione. Gdzie tu zaczyna się i kończy workflow?

Jeśli początek byłby tożsamy z pierwszym stanem, w którym wykonuje się jakąkolwiek pracę, to tym początkiem byłby stan w trakcie. Jeśli koniec następowałby w ostatnim stanie, gdzie jakaś praca jest wykonywana, to tym końcem również byłby stan w trakcie. Wychodziłoby więc na to, że workflow zaczyna się i kończy w tym samym miejscu, co nie wydaje się zbyt czytelne.

W rzeczywistości początkiem tego workflowu jest nie stan w trakcie, ale wejście jednostki pracy do tego stanu. A posługując się terminologią kanbanową, jej wciągnięcie (ang. pulling) do tego stanu, lub też jej selekcja (ang. selection) spośród jednostek zgromadzonych w stanie do zrobienia.

Końcem tego workflowu natomiast też nie jest żaden stan, ale wciągnięcie work itemu do stanu zrobione.

I choć mamy faktycznie jeden stan w ramach tego prostego przykładowego workflowu, to punkty rozpoczęcia i kończenia się workflowu nie pokrywają się. Nie mogą się też pokryć w żadnym innym poprawnie zdefiniowanym przepływie pracy.

Czy jest dopuszczalne, że na tablicy kanbanowej pojawią się stany, przez które przechodzi jednostka pracy, a które następują przed rozpoczęciem workflowu w danym systemie Kanban? Albo że znajdzie się na tej tablicy wizualizacja stanów work itemu, przez które przechodzi on już po zakończeniu workflowu? Jasne, że tak, a właściwie jest to nieuniknione.

Nawet ten przykładowy trzystanowy proces powyżej taki właśnie jest. Stan do zrobienia nie jest przecież częścią workflowu, ale to z niego wciągane są work itemy do systemu Kanban i dlatego musi on być zwizualizowany na tablicy kanbanowej. Podobnie jest ze stanem zrobione – nie jest on częścią workflowu, ale do niego trafiają jednostki pracy, dla których ten workflow się zakończył.

Oczywiście takich stanów przed punktem rozpoczęcia workflowu i po jego zakończeniu może być na tablicy kanbanowej więcej. Np. może być na niej zobrazowany tzw. upstream Kanban, czyli inny system Kanban, który generuje jednostki pracy dla systemu Kanban. Dzięki możliwości obserwacji work itemów, które powoli przybliżają się do punktu rozpoczęcia workflowu, członkowie systemu Kanban mogą efektywniej decydować o kolejności ich realizacji albo przygotować się do ich obsługi (np. dokonując niezbędnej dekompozycji zbyt dużych itemów na kilka mniejszych).

Tablica może prezentować również tzw. downstream Kanban, będący kolejnym systemem Kanban, konsumującym te work itemy, dla których przepływ został zakończony (czyli dla którego dany system Kanban jest upstreamowym Kanbanem). Dzięki widoczności tego, co dzieje się z tymi ukończonymi jednostkami pracy, możliwe staje się dokonywanie usprawnień, które pozwolą ulepszyć ten dalszy przepływ (odbywający się już w downstreamowym Kanbanie).

W zapisie tym nie chodzi o zaczynanie workflowu i kończenie go wielokrotnie dla jednego work itemu, ale o możliwość zdefiniowania różnych punktów rozpoczynania i kończenia workflowu dla różnych jednostek pracy.

Najlepiej wyjaśnić to na prostym przykładzie. Jeśli system Kanban obejmuje rozwój jakiegoś produktu, prawie na pewno pojawią się tam dwa typy work itemów: opisy kolejnych potrzeb, jakie produkt ma zaspokoić (lub problemów, jakie ma rozwiązać) oraz zgłoszenia błędów w działaniu produktu (bo nie da się zrobić rozwiązania absolutnie pozbawionego defektów).

Co będzie pierwszą sensowną czynnością przy budowaniu produktu, jaki zaspokoi potrzebę użytkowników? Zapewne prace rozpoczną się od stworzenia koncepcji rozwiązania i wymyślenia, jak je wytworzyć.

Co natomiast będzie pierwszą czynnością w przypadku zgłoszenia błędnego działania produktu? Przede wszystkim reprodukcja problemu, by potwierdzić, że faktycznie on występuje. Dopiero potem nastąpi poszukiwanie rozwiązywania, o ile w ogóle będzie ono niezbędne.

To oznacza, że w zależności od tego, jaki typ itemu zostanie wciągnięty do workflowu, znajdzie się on na początek w różnym stanie. I jest to jak najbardziej poprawne.

Analogicznie, przepływ może kończyć się w różnych punktach, zależnie od typu work itemu, ale też czasami zależnie od warunków, jakie zostaną zdefiniowane w ramach tego workflowu. Znów najłatwiej to wyjaśnić na przykładzie.

Wróćmy na moment do obsługi zgłoszenia błędu. Jak może zakończyć się jego workflow? Błąd może zostać potwierdzony i rozwiązany – wtedy konieczne będzie dokonanie zmian w produkcie i udostępnienie go użytkownikom. Ale może okazać się, że zgłoszony problem wcale nie jest błędem i wynika z niewłaściwego sposobu użytkowania produktu – wtedy workflow zakończy się dużo wcześniej, dostarczeniem użytkownikowi stosownej informacji.

Oczywiście im więcej punktów rozpoczynania i kończenia workflowu zostanie zdefiniowanych, tym mniej przejrzysta stanie się definicja przepływu pracy, a tym samym trudniejsze będzie jej stosowanie. Dlatego należy kierować się tu dążeniem do tworzenia definicji przepływu pracy, które jest wystarczający, ale nie wyczerpujący.

Niezmiennie warto również przy tej okazji przypomnieć starą, a często zapominaną zasadę: żaden proces nie powinien być tworzony do obsługi sytuacji wyjątkowych w tym procesie. Trzymając się jej unikniemy generowania nadmiaru zasad, stanów workflowu i innych jego elementów, których istnienie generowałyby możliwość wystąpienia kolejnych wyjątków.

Aby mówić o jakimkolwiek przepływie związanym z kreowaniem wartości, definicja workflowu musi obejmować przynajmniej jeden stan aktywny – taki, w którym wykonywane są działania podnoszące wartość work itemu.

Nie oznacza to oczywiście, że nie może istnieć workflow, w którym stan work itemów przed rozpoczęciem procesowania i po jego zakończeniu będzie dokładnie taki sam. Jasne, może istnieć, pod warunkiem, że w ramach tego workflowu stan ten ulega zmianie a następnie powraca do stanu wyjściowego. O ile ta tymczasowa zmiana stanu i powrót do punktu wyjścia pozwala uzyskać wartość, tak działający system Kanban ma sens.

Natomiast jeśli work itemy jedynie formalnie zmieniają stan, ale tak naprawdę nic się z nimi nie dzieje, to taki workflow nie ma sensu. Statyczny przepływ to przecież oksymoron.

Równie pozbawionym sensu byłby workflow, w którym wszystkie stany opisują czynności podejmowane przez osoby niebędące członkami systemu Kanban. Taki pseudo-system Kanban służyłby wyłącznie obserwowaniu tego, co dzieje się poza nim, ale sam ten pseudo-system nie wpływałby w ogóle na przebieg realizowanych działań. Bez realnego wpływu na stan jednostek pracy nie da się jednak mówić o stosowaniu strategii czy optymalizowaniu przepływu.

Uwaga: w Kanbanie mowa jest o stanach workflowu (ang. workflow states), a nie krokach (ang. steps), choć nie da się zaprzeczyć, że wiele osób mówi krokach jakby to był synonim stanu. Cóż, to nie do końca poprawne. Kroki sugerują linearność procesu, a przecież przepływ nie musi za każdym razem przejść przez wszystkie stany po kolei. Jeśli spełnione są warunki do pominięcia niektórych stanów i zdefiniowane w systemie zasady (ang. policies) na to pozwalają, stany w procesie mogą być przeskakiwane.

Ale przede wszystkim stan (ang. state) nie jest nazwą przypadkową: chodzi o stan, w jakim znajduje się aktualnie nośnik wartości, czyli work item płynący przez workflow. Być może do zmiany stanu niezbędne jest wykonanie szeregu czynności po kolei (kroków właśnie). Jeśli zaczniemy opisywać workflow za pomocą kroków a nie stanów, stanie się on koszmarnie rozbudowany i detaliczny. Bardzo ciężko będzie taką definicją workflowu się posługiwać.

Dobrą strategią jest postrzeganie stanów workflowu jako kolejnych celów, które trzeba osiągnąć na drodze do uzyskania wartości. I tak przykładowo w procesie obsługi błędu większy sens ma stan potwierdzenie problemu niż analiza zgłoszenia błędu albo reprodukcja błędu. Potwierdzenie problemu to cel, zaś jego analiza lub reprodukcja to właściwie opis czynności i nie musi być jasne, dlaczego są one wykonywane.

Druga ważna uwaga: lepiej unikać definiowania stanów workflowu w sposób, z którego wynika kto konkretnie i jaką pracę ma wykonać. Oczywiście istnieją systemy Kanban, gdzie może mieć to sens, ale w większości przypadków będzie bardzo niekorzystne. Spowoduje bowiem, że członkowie systemu Kanban mogą skupiać się tylko na tym, co znajduje się w stanach związanych z ich specjalnością i posiadanymi kompetencjami.

Przykładowo, jeśli stan nosi nazwę analiza, to niejako narzuca się, że w ramach tego stanu analitycy przeprowadzają analizy. A może należałoby w jej trakcie wykonać jakiś prototyp rozwiązania? I go przetestować? Albo sprawdzić, jak działa aktualne rozwiązanie, zanim weźmiemy się za jego modyfikację? To już nie analiza i wymagane są do wykonania takiej pracy różne kompetencje. Czy dodany zostanie kolejny stan (lub stany), czy też w stanie analiza realizowane będą czynności niezbyt pasujące do jego nazwy?

Takiemu nazywaniu stanów jako opisów czynności bardzo sprzyja traktowanie stanów w procesie jako kroków do wykonania po kolei (problem opisywany powyżej). Natomiast gdy stany definiowane są jako opisy celów, które mają w nich zostać osiągnięte, problem w zasadzie nie ma szans wystąpić. Nie będzie stanu analiza tylko będzie zamiast niego np. ustalenie, co powinno zostać wytworzone (lub po angielsku krótko: solution discovery).

Trzecia istotna rzecz: przepływ nie musi być liniowy (czyli stan po stanie, po kolei), ale w oczywisty sposób powinien zmierzać w jedną stronę – od rozpoczęcia prac nad wytwarzaniem wartości do jej uzyskania. Inaczej mówiąc, przepływ odbywa się od punktu zaczęcia workflowu dla danego itemu, do punktu jego zakończenia.

Jeśli więc definicja workflowu przewidywałaby cofanie się do wcześniejszych stanów, coś z tą definicją jest nie tak. Bo to oznaczałoby, że spodziewane jest oddalanie się od uzyskania wartości – czyli zjawisko fundamentalnie sprzeczne z sensem strategii, jaką jest Kanban.

Gdy wydaje się, że powrót do wcześniejszego stanu jest czymś logicznym, to zapewne tak naprawdę jest to inny stan, nawet jeśli wydaje się identyczny z tym, który zakończony został wcześniej. Nie jest to żaden powrót tylko przejście do kolejnego stanu, a identyczna jest jedynie kondycja work itemu w obu tych odrębnych stanach.

I tu znów odezwie się czkawką definiowanie stanów jako kroków do wykonania, albo spinanie stanów z konkretnymi rodzajami prac i kompetencjami potrzebnymi do ich wykonania. Przykładowo, jeśli system Kanban pracuje nad rozwojem oprogramowania, to będą w nim pracować analitycy, programiści, testerzy, specjaliści UX, eksperci od baz danych itd. Jeśli pierwszy stan procesu to analiza, po jej zakończeniu następuje development, a później test, to co stanie się, jeśli na etapie testów znalezione zostaną błędy?

Błędy trzeba rozwiązać, więc konieczny jest jakiś development, który być może poprzedzony musi być analizą. Da się też zapewne kontynuować testowanie kolejnych obszarów rozwiązania. W myśl użytej definicji workflowu jednostka pracy, której dotyczą te wszystkie czynności, musiałaby się znajdować jednocześnie w trzech różnych stanach, a to nie ma żadnego sensu. A jeśli znajdzie się tylko w jednym, opisanym nazwą czynności, wtedy to, co będzie się z nią dziać, nijak nie będzie pasować do tego, w jaki sposób stan ten został zdefiniowany.

Istnieje oczywiście prymitywne rozwiązane tego problemu: dodać kolejne stany w rodzaju development poprawek czy retest rozwiązania błędu. Taki workflow rozrastał się będzie o kolejne stany za każdym razem, gdy pojawi się nieprzewidziana wcześniej sytuacja…

A co byłoby, gdyby ten workflow zdefiniowany był inaczej i składał się również z trzech stanów: discovery (tu wymyślane jest rozwiązanie), creation (tu rozwiązanie jest budowane) oraz validation (tu potwierdzana zostaje wartość rozwiązania)? Żadna konieczność cofania się nie wystąpi. W pierwszym stanie będzie dużo analiz, może trochę developmentu i testów. W drugim wciąż będą analizy (bo okaże się, że nie wszystko udało się dobrze wymyślić), ale dominować będzie development i test – bo celem jest zbudowanie czegoś, co faktycznie działa. W trzecim stanie dominować będą testy, ale jeśli wykryty zostanie jakiś problem, to przecież tak naprawdę nie wymaga on wymyślania na nowo rozwiązania czy jego zbudowania od zera – niezbędne analizy i development odbędzie się już w trakcie walidacji.

Oczywiście przedstawiony tu model nie jest czymś obowiązkowym w Kanbanie i członkowie każdego systemu Kanban mają swobodę w kształtowaniu stanów i zasad przechodzenia między nimi.

Przy okazji warto wspomnieć, że to cofanie się do poprzednich stanów nie jest bezwzględnie zakazane w Kanbanie. Powód, dla którego nie ma to sensu, został wyjaśniony powyżej – przepływ nie powinien prowadzić do oddalania się od zakończenia prac i uzyskania wartości. Natomiast są sytuacje, w których cofnięcie się do poprzedniego stanu jest jedynie słuszną decyzją: musimy tak zrobić, jeśli odkryjemy, że work item nie spełnia warunków do wciągnięcia do stanu, w którym (błędnie) aktualnie się znalazł. Należy taki błąd niezwłocznie skorygować.

Może też zdarzyć się sytuacja, że co prawda zasady pozwalają wciągnąć item do kolejnego stanu w procesie, ale okazuje się, że i tak będzie on tam na razie zalegał, bo nie ma możliwości pracy nad nim w tym nowym stanie (dlaczego tak może być, nie ma tu znaczenia). Jeśli w ramach tego nowego stanu nic jeszcze nie zostało zrobione, można cofnąć item do stanu poprzedniego. Oczywiście nie można tego zrobić, gdyby jakieś prace w aktualnym (nowym) stanie się już zaczęły – wtedy cofnięcie itemu spowodowałoby, że stan faktyczny rozjechałby się ze stanem deklarowanym na tablicy kanbanowej.

Praca w toku (ang. work in progress, w skrócie WIP) to kolejny termin, który może czasami powodować nieporozumienia. Jakie?

Niektórzy powiedzą, że jeśli praca nad jednostką pracy jest z jakiegoś powodu zablokowana, to wtedy jednostka pracy nie jest już częścią WIP‑u (bo nie następuje dla niej żaden progres).

Inni utrzymują, że tylko te jednostki pracy są częścią WIP‑u, nad którymi aktywnie wykonywana jest aktualnie praca. Jeśli więc znalazły się w one w jakimś stanie pasywnym (oczekując na wciągnięcie do kolejnego stanu aktywnego lub na wykonanie prac przez kogoś spoza systemu Kanban), to z WIP‑u znikają.

Oba podejście opierają się o zbyt dosłowne traktowanie terminu work in progress. Chodzi w nim o postęp w uzyskiwaniu wartości, a nie o literalny postęp prac w danym momencie.

Dlatego tak ważne jest klarowne zdefiniowanie punktów rozpoczęcia workflowu i jego zakończenia: wszystkie work itemy, które minęły już właściwy dla nich punkt rozpoczęcia, stanowią część WIP‑u tak długo, dopóki nie miną właściwego dla nich punktu zakończenia.

Można zetknąć się z kontrargumentem: skoro kontrolowanie WIP‑u ma zapobiegać zalaniu systemu Kanban nadmiarem pracy wykonywanej jednocześnie, to przecież takie work itemy, z którymi aktualnie się nic nie dzieje (choć formalnie prace nad nimi się zaczęły i jeszcze nie ukończyły), nie stanowią problemu. Członkowie systemu Kanban mogą przecież pracować nad pozostałymi itemami, których nie ma wtedy w nadmiarze.

Cóż, to nieporozumienie. Tak, chwilowo część jednostek pracy pasywnie czeka na zajęcie się nimi, ale znajdują się już w przepływie. Jeśli nic się z nimi nie dzieje, bo z jakiegoś powodu są zablokowane, to być może system Kanban pracuje na rzecz usunięcia tej blokady. W takim wypadku WIP jednak wcale nie jest taki mały, czyż nie?

A jeśli nawet system Kanban czeka biernie, aż blokadę usunie ktoś inny, to nie wiadomo, w którym momencie wznowienie przepływu będzie możliwe. W ten sposób w losowym momencie WIP nagle wzrośnie ponad miarę.

Ponadto w sytuacji, gdy work itemy nie są zablokowane, ale przepływ i tak się dla nich zatrzymał, nasuwa się pytanie o przyczynę. Być może zatrzymał się dlatego, że WIP był zbyt duży i członkowie systemu Kanban musieli wybrać, nad czym będą pracować, a co musi poczekać statycznie na swoją kolej. Nieuznawanie tych zaparkowanych work itemów za część WIP‑u w tej sytuacji będzie samooszukiwaniem się i ukrywaniem problemu.

Niektórzy, aby uniknąć nieporozumień, wolą posługiwać się terminem work in proces (po polsku, nieco kulawo: praca w procesie). Dzięki temu chcą podkreślić, że work item już jest w procesie i niezależnie od tego, czy coś się z nim dzieje, stanowi część WIP‑u. Ale to też może być mylące, ponieważ proces jest bardzo szerokim pojęciem. Może przecież chodzić o jakiś proces, który poprzedza rozpoczęcie workflowu w systemie Kanban – work item będzie częścią takiego procesu, ale nie będzie w ogóle znajdował się jeszcze w przepływie i tym samym nie będzie elementem WIP‑u.

Zapewne najlepszym terminem na określenie WIP‑u jest work in flow (po polsku: praca w przepływie), ale używany jest tak rzadko, że wymagałby każdorazowego tłumaczenia, czy chodzi o WIP, czy może o coś innego. Dlatego, pamiętając o tym, jak definiowany jest work in progress, posługujmy się tym ogólnie znanym terminem.

Na koniec istotna uwaga: niektórzy ludzie mylą WIP z limitami WIP, które stanowią możliwą implementację sposobu kontrolowania WIP‑u. WIP będzie istniał tak długo, jak długo w przepływie znajduje się choć jeden work item, niezależnie od tego, czy w systemie Kanban jakiekolwiek limity są zdefiniowane, czy też nie.

Kanban wielu osobom kojarzy się z dwoma rzeczami: tablicą kanbanową i (rzadziej) z limitami WIP. Nieco mniejszej grupie ludzi kojarzy się jeszcze z obowiązkiem ograniczania WIP‑u. Jak to zwykle bywa, takie skojarzenia tylko częściowo odzwierciedlają faktyczne wymagania Kanbana.

Kluczową kwestią jest kontrolowanie WIP‑u tak, by system Kanban był systemem wciągania pracy (ang. pull system), czyli by kolejne jednostki pracy były do niego wciągane (ang. pull) wtedy, gdy spełnione są warunki rozpoczęcia pracy nad nimi, oraz by nie spowodowało to konieczności zatrzymania przepływu tych work itemów, które już stanowią część WIP‑u.

Mowa jest o kontrolowaniu, a nie o limitowaniu, ograniczaniu lub wręcz minimalizacji. Dlaczego? Ponieważ nie chodzi o to, by WIP był za wszelką cenę jak najmniejszy (to zmniejszanie zresztą nie mogłoby trwać w nieskończoność, bo w końcu system Kanban doszedłby do WIP‑u równego jeden). Chodzi o aktywne przeciwdziałanie sytuacji, w której ten WIP jest za wysoki.

A to oznacza, że WIP może się dynamicznie zmieniać i mimo braku limitu wciąż być dostatecznie niski. Z drugiej strony fakt istnienia zdefiniowanego limitu wcale nie gwarantuje, że jeśli WIP go nie przekracza, to nie jest za wyskoki. Wszak limit może być niepoprawnie dobrany i choć istnieje, będzie absolutnie nieskuteczny przy próbie zbudowania systemu wciągania pracy.

Limitowanie lub ograniczanie WIP‑u jest więc jedną z możliwych implementacji sposobu kontrolowania tego WIP‑u, ale Kanban wcale jej nie wymaga. Można tę kontrolę zrealizować w inny sposób, na przykład za pomocą zasad (ang. policies).

Przykład takiej kontroli nie opierającej się o limity WIP: każdego dnia można wciągnąć do WIP‑u tylko tyle nowych itemów, ile udało się tego dnia ukończyć, ale pod warunkiem, że realizacja żadnego z itemów będących aktualnie częścią WIP‑u nie trwa dłużej niż pięć dni.

Brzmi to nieco skomplikowanie, ale jest naprawdę proste. Częstotliwość rozpoczynania pracy jest zsynchronizowana z częstotliwością jej kończenia (co daje możliwość utrzymywania WIP‑u na stałym poziomie). Natomiast jeśli jakiś work item tkwi w procesie zbyt długo, to najpewniej WIP jest już za wysoki i nie należy go dodatkowo podnosić.

Oczywiście przykładowe pięć dni nie jest jakąś wskazówką, którą należałoby się kierować. Dobrym punktem odniesienia przy konstruowaniu takich zasad kontrolowania WIP‑u będzie oczekiwany poziom obsługi (ang. service level expectation), omówiony w kolejnych rozdziałach.

Brak skuteczności w kontrolowaniu WIP‑u spowoduje, że zadziała zależność między czasem cyklu a WIP‑em, którą opisuje prawo Little’a wspomniane w jednym ze wcześniejszych komentarzy. Nadmierny WIP sprawi, że przepływ dla niektórych jednostek pracy spowolni lub zatrzyma się, czyniąc je bardziej podatnymi na wystąpienie utrudnień i blokad. Spadnie też efektywność działania systemu Kanban, bo część wysiłków zamiast na kreowanie wartości pożytkowana będzie na przełączanie się między różnymi work itemami.

W języku polskim mówimy o jawnych zasadach, ale w angielskim terminie explicit policies kryje się też wymóg jednoznaczności tych zasad.

Zasady mogą dotyczyć każdego aspektu funkcjonowania systemu Kanban.

Mamy więc zasady wciągania itemów do kolejnych stanów (ang. pulling policies) – czego specyficznym przykładem jest określenie, kiedy przepływ dla konkretnego itemu może w ogóle się rozpocząć.

Ponieważ Kanban opiera się o wizualizację, mogą istnieć zasady, które ją określają (ang. visualisation policies). Przykładem może być ustalenie zasad prezentowania różnych typów work itemów na tablicy, sposób oznaczania jednostek zablokowanych, pokazywania wieku tych jednostek itd.

Czasami niezbędne jest podejmowanie decyzji odnośnie do tego, jakie jednostki pracy powinny być traktowane priorytetowo, co również może zostać zdefiniowane w formie zasad (ang. prioritization policies). Mogą one np. być użyte w systemie Kanban, który przewiduje tzw. szybką ścieżkę (ang. expedite lane) i determinować, co i kiedy będzie przez nią przepływać.

Innym przykładem zasady jest sposób kontrolowania WIP‑u (ang. WIP controlling policies), który może być zastosowany zamiast typowych, ale nieobowiązkowych limitów WIP.

Oczywiście podane tutaj rodzaje zasad służą jedynie ilustracji. Członkowie systemu Kanban nie są w niczym ograniczeni, jeśli chodzi o definiowanie obowiązujących w nim zasad. Należy jednak pamiętać, że ich nadmiar może spowodować, że przestaną być jednoznaczne, albo że ich zastosowanie będzie zbyt trudne lub nie będą w ogóle zrozumiałe.

Czy możliwe jest używanie Kanbana bez żadnych zasad? Nie, ponieważ muszą istnieć przynajmniej te opisujące reguły wciągania work itemów do kolejnych stanów workflowu. Bez określenia tego nie sposób zarządzać przepływem.

Te zasady najczęściej mają formę warunków, które muszą być spełnione, by wciągnięcie mogło nastąpić, ale wiele systemów Kanban uwzględnia również reguły decydowania o kolejności tego wciągnięcia, jeśli konieczne jest dokonywanie wyboru.

Przykładowo, przy wciąganiu nowego itemu do workflowu może być brany pod uwagę jego priorytet albo szacowana wartość. A przy wciąganiu jednostki pracy już znajdującej się w przepływie do kolejnego stanu kierować można się np. czasem jej przebywania w WIP‑ie tak, by te najstarsze wciągane były najpierw.

Oczekiwany poziom obsługi (ang. service level expectation, w skrócie SLE), to nie alternatywna nazwa na umowę o gwarantowanym poziomie obsługi (ang. service level agreement, w skrócie SLA). Są dwie zasadnicze różnice.

SLE jest oczekiwanym poziomem obsługi, a nie gwarancją zapewnienia określonego jej poziomu. Poza tym SLE jest zobowiązaniem, które członkowie systemu Kanban definiują samodzielnie i przede wszystkim dla siebie, na potrzeby samego systemu Kanban. Natomiast SLA jest zobowiązaniem, które wynika z ustaleń z osobami niebędącymi członkami systemu Kanban, np. z klientami. Bardzo często przy tym SLA jest systemowi Kanban wręcz narzucane przez ustalenia na poziomie organizacji, w której system ten funkcjonuje.

Jeśli istnieje jakikolwiek związek pomiędzy SLA i SLE, to byłby on następujący: SLE nie może być mniej wymagający, niż obowiązujące SLA, bo to oznaczałoby, że oczekiwany (przez członków systemu Kanban) poziom obsługi jest niższy niż ten, który komuś muszą zagwarantować.

A patrząc na to z nieco innej perspektywy, można dopatrzeć się i takiego związku: SLE (oczekiwany poziom obsługi) może być dobrą podstawą do dyskusji o tym, jakie mogłoby być SLA (gwarantowany poziom tej obsługi), aby było ono racjonalne i możliwe do utrzymania.

Prognoza (ang. forecast) to próba przewidzenia przyszłości, która zawsze jest niewiadomą. To oznacza, że SLE, które jest prognozą, nigdy nie może zacząć funkcjonować jako gwarancja, że przyszłość będzie wyglądać w określony sposób (czyli np. jako SLA).

Prognoza musi też składać się z dwóch informacji: prognozowanej wartości i poziomu prawdopodobieństwa potwierdzenia się tej prognozy.

Jeśli np. ktoś poinformuje nas, że coś zostanie ukończone w ciągu trzech tygodni, to tak naprawdę dostarcza jedynie oszacowania czasu wykonania prac. Jest to informacja wyłącznie ilościowa, bo brak danych do oceny jej jakości.

Natomiast informacja, że prawdopodobieństwo zakończenia prac w trzy tygodnie wynosi 50%, jest już prognozą. Wynika z niej, że poziom pewności jest dość niski (szansa 50/50, że będzie to trzy tygodnie), dlatego na pewno pojawi się potrzeba opracowania bardziej wiarygodnej prognozy. I po jej sporządzeniu okaże się, że prawdopodobieństwo ukończenia niezbędnych prac w pięć tygodni wynosi np. 95%.

Przy okazji należy zwrócić uwagę, że ludzie mają skłonność do skupiania się na tej informacji, która jest w ich ocenie ważniejsza. Jeśli dyskutujemy o terminach wykonania jakiejś rzeczy, najbardziej wyczekiwana informacja to czas realizacji. Jeśli podamy go najpierw, a potem dorzucimy do tego informację o prawdopodobieństwie, jest szansa, że rozmówca tej drugiej części nie usłyszy.

Jeśli zamiast tego najpierw powiemy, jak prawdopodobna jest prognoza (której wartości jeszcze nie podaliśmy), to mamy wciąż pełną uwagę rozmówcy.

Dlatego zamiast mówić, że coś uda się zrobić w miesiąc z prawdopodobieństwem 80%, poinformujmy zamiast tego, że istnieje 80‑procentowe prawdopodobieństwo, że prace uda się wykonać w miesiąc lub krócej.

SLE jest prognozą czasu, w jakim jednostka pracy powinna przepłynąć od punktu rozpoczęcia workflowu do punktu zakończenia. Jest to więc prognoza wartości jednej z miar kanbanowych, jaką jest czas cyklu (ang. cycle time).

Prognoza ta nie dotyczy oczywiście pojedynczego work itemu, bo te bywają różne i nad niektórymi w naturalny sposób pracować trzeba dłużej, nad innymi krócej. Nie jest też to prognoza średniego czasu cyklu, bo to oznaczałoby, że może istnieć ogromny rozrzut tego czasu, byleby średnia była na oczekiwanym poziomie. A przecież w Kanbanie chodzi o optymalizację przepływu, czyli poszukiwanie sposobu, by czas cyklu był jak najkrótszy.

SLE jest w istocie określeniem tego, dla jakiego odsetka wszystkich realizowanych work itemów członkowie systemu Kanban spodziewają się czasu cyklu nieprzekraczającego wartości zawartej w prognozie. Brzmi to skomplikowanie, ale w sumie jest proste. Najlepiej wyjaśnić to na przykładzie.

Powiedzmy, że SLE dla konkretnego systemu Kanban jest następujące: 85% / 14 dni. Oznacza to, że członkowie tego systemu będą dążyć do tego, by 85% wszystkich work itemów, jakie wciągnięte zostaną do workflowu, przepłynęły przez niego w czasie 14 dni lub szybciej.

Oczywiście ten zapis jest tożsamy ze stwierdzeniem, iż członkowie systemu Kanban dążyć będą do tego, aby istniało 85‑procentowe prawdopodobieństwo, że work itemy, które wciągane są do workflowu, przepłyną przez niego w 14 dni lub szybciej.

O tym, w jaki sposób określić SLE, przeczytać można w poświęconym tej prognozie rozdziale Przewodnika po Kanbanie (ang. Kanban Guide).

Ponieważ Kanban jako strategia stanowi uzupełnienie różnych procesów i metod (jest ich suplementacją, augmentacją, rozszerzeniem itd.), definicja workflowu często będzie zawierać elementy, które w tych procesach i metodach są wymagane.

Często zdarza się też, że tablica kanbanowa i ogólniej definicja workflowu wręcz budowana jest z wykorzystaniem elementów, które stanowią część nie Kanbana, ale metod, które Kanbanem są uzupełniane. Tak np. dzieje się w wielu Zespołach Scrum, które odzwierciedlają swoją Definicję Ukończenia (ang. Definition of Done) w zasadach sterujących wciąganiem itemów do kolejnych stanów workflowu.

Istnieje wiele praktyk kanbanowych, które nie stanowią integralnej części definicji Kanbana i dlatego nie zostały opisane na niniejszej stronie. Niektóre z opcjonalnych praktyk wiążą się ze sposobem, w jaki definiowany jest workflow.

Przykłady takich praktyk to wspomniane już we wcześniejszych komentarzach klasy serwisu (ang. classes of service) oraz tzw. szybka ścieżka (ang. expedite lane).

Innym przykładem może być grupowanie work itemów na tablicy kanbanowej w ten sposób, że każdy tym przepływa osobnym potokiem (ang. swimlane). Technicznie taki potok wygląda np. jak wiersz na tablicy, której kolumny opisują poszczególne stany workflowu.

Jeszcze innym przykładem praktyki kanbanowej, która nie musi być obowiązkowo używana, jest podział stanów w procesie na część aktywną (czyli taką, w której znajdują się te itemy, które wciąż są w tym stanie przetwarzane), oraz część pasywną (czyli taką, w której znajdują się itemy, dla których procesowanie w tym stanie się zakończyło i które mogą zostać wciągnięte do stanu kolejnego). Taki podział podnosi przejrzystość tablicy kanbanowej i ułatwia zarządzanie przepływem. Oczywiście ten podział nie wprowadza nowych stanów workflowu, więc jeśli np. stan objęty jest limitem WIP, obejmuje on sumę liczby itemów w obu podstanach (aktywnym i pasywnym).

Tablica kanbanowa jest w praktyce sposobem zapisu definicji workflowu w konkretnym systemie Kanban i nie jest czymś opcjonalnym. Nie da się używać Kanbana bez tablicy, choć oczywiście samo jej użycie nie oznacza automatycznie, że stosowany jest Kanban.

Ważna uwaga: tablicę kanbanową, a zarazem i definicję workflowu, tworzą członkowie systemu Kanban, czyli osoby, które w tym systemie będą wykonywać pracę. Nie jest więc poprawną sytuacja, gdy ktoś z zewnątrz narzuca tym osobom definicję workflowu albo gdy jeden z członków systemu Kanban wymusza zastosowanie określonych zasad lub formy wizualizacji na pozostałych osobach.

Może oczywiście być tak, że w organizacji, w której funkcjonuje system Kanban, istnieją różne standardowe praktyki i standardy związane z procesami i sposobem ich wizualizacji, ale powinny one stanowić inspirację przy tworzeniu definicji przepływu pracy, a nie wymuszać konkretne rozwiązania.

Jest to o tyle kluczowe, że bez możliwości swobodnego kształtowania swojej własnej definicji workflowu członkowie systemu Kanban nie mogą dokonywać usprawnień lub adaptacji niezbędnych dla uzyskania i utrzymania przepływu, a potem jego optymalizacji. Tak użyty Kanban będzie fasadowy i najprawdopodobniej nie przyniesie żadnych wymiernych korzyści.

Często zetknąć można się z tablicami kanbanowymi, na których nie do końca da się zidentyfikować, czym są poszczególne work itemy, gdzie zaczyna się i gdzie kończy workflow, na których brak informacji o warunkach przejścia między stanami albo nie jest jasne, czy i w jaki sposób kontrolowany jest WIP.

Żadna z tych rzeczy nie jest opcjonalna na tablicy Kanbanowej, ponadto musi na niej być widoczna prognoza oczekiwanego poziomu obsługi (SLE), którą przyjęli członkowie systemu Kanban i którą powinni kierować się przy podejmowaniu decyzji odnośnie do kolejności działań.

Nie może być zatem tak, że te wszystkie elementy definicji workflowu są zdefiniowanie, ale zapisane gdzieś poza tablicą kanbanową, np. w jakimś dokumencie, do którego nikt i tak nie sięga. Brak nieustannej dostępności i widoczności tych podstawowych elementów definicji workflowu skutkuje z czasem rozbieżnością w rozumieniu zasad wśród członków systemu Kanban. A wtedy trudno o skuteczną realizację którejkolwiek z trzech podstawowych praktyk kanbanowych.

Tablica kanbanowa może zostać uzupełniona o bieżące wskazania miar przepływu – szczególnie użyteczne będzie zwizualizowanie wieku jednostek pracy dla poszczególnych elementów WIP‑u. Przydatne będą też wykresy obrazujące wartości tych miar, np. skumulowany diagram przepływu (ang. cumulative flow diagram) lub wykres starzenia się jednostek pracy (ang. work item aging chart).

Tablica kanbanowa zwykle ma formę tabeli z kolumnami, a czasami również z wierszami grupującymi różne typy jednostek pracy – wiersze te nazywane bywają potokami (ang. swimlanes).

Nie ma natomiast obowiązku definiowania tablicy kanbanowej w takiej formie. Podobnie jak Kanban nie wymaga, by work itemy przepływały przez tablicę z lewej strony na prawą.

To oznacza, że tablica kanbanowa może mieć formę np. diagramu stanów (ang. state diagram) albo schematu blokowego (ang. flowchart) tak długo, jak zwizualizowana w tej formie definicja przepływu pracy będzie poprawna.

Również kierunek przepływu jednostek pracy może być dowolny, bo istotne jest nie to, czy odbywa się on w dół, w górę, w lewo, w prawo czy po łuku, ale czy przepływ poprzez poszczególne stany workflowu prowadzi od rozpoczęcia prac do uzyskania wartości.

Tablica kanbanowa może mieć zarówno formę fizyczną jak i wirtualną (obecnie najczęściej stosowaną). Należy przy tym pamiętać, że system Kanban nie może posiadać jednocześnie kilku konkurujących ze sobą definicji workflowu i wielu tablic kanbanowych. Jeśli więc członkowie systemu Kanban chcieliby posługiwać się jednocześnie fizyczną tablicą i jej elektroniczną reprezentacją, muszą znaleźć sposób na zapewnienie, że zachodzić będzie między nimi skuteczna i niezwłoczna synchronizacja. W praktyce jest to trudne do osiągnięcia i lepszym rozwiązaniem jest użycie wtedy jednej, wirtualnej tablicy.

Z użyciem tablic wirtualnych wiąże się ryzyko, że poszczególne osoby będą posługiwać się różnego rodzaju filtrami, które zawężać będą widok tablicy i znajdujących się na niej jednostek pracy (np. do listy work itemów, z którymi ma jakiś związek konkretna osoba). Samo takie filtrowanie, sortowanie itd. danych na tablicy bywa często przydatne, ale może wpłynąć negatywnie na ocenę sytuacji (np. powodując złe rozumienie, jak duży jest aktualnie WIP).

Dlatego konieczne jest istnienie takiego widoku tablicy, który bezwzględnie pokazuje workflow taki, jakim został on zdefiniowany i cały WIP – bez żadnego filtrowania lub ograniczania widoczności. To również na bazie takiego widoku tablicy wirtualnej członkowie systemu Kanban powinni podejmować wspólne decyzje.

Dobrym pomysłem jest zapisanie zasad obowiązujących w procesie wprost na tablicy. W ten sposób np. zamiast zastanawiać się, kiedy określony work item może być wciągnięty do kolejnego stanu w procesie, można odczytać to wprost z tablicy kanbanowej. Przy okazji w naturalny sposób system Kanban zabezpieczony zostanie przed zdefiniowaniem zbyt wielu zasad, bo po prostu nie będzie się ich racjonalnie dało upchać na tablicy.

Gdzie można zapisać takie zasady wciągania (ang. pulling policies) ze stanu X do stanu Y? Na typowej tablicy w formie tabeli mogą one być umieszczone w nagłówku lub stopce kolumny reprezentującej stan Y. Alternatywnie, mogą to być warunki ukończenia, zapisane w nagłówku lub stopce kolumny reprezentującej stan X. Lub, jeśli jest to czytelne, na linii separującej kolumny stanów X oraz Y.

Jeśli używana jest tablica wirtualna, może pojawić się pokusa, by zamiast zapisywać warunki na tablicy zaimplementować jakiś mechanizm, który je sprawdza automatycznie. I wtedy narzędzie, w którym utrzymywana jest tablica, samo będzie pilnować przestrzegania zasad.

O ile taki mechanizm będzie użyteczny (bo pozwoli pewnie ustrzec się błędów), wciąż należy takie zasady zapisać na samej tablicy. W przeciwnym razie członkowie systemu Kanban mogą zwyczajnie zapomnieć, jakie te zasady są, a wtedy ciężko mówić, że są one jawne i jednoznaczne.

Ten mechanizm automatycznego wymuszania przestrzegania zasad może być też o tyle kłopotliwy, że nie będzie w ogóle elastyczny. Wcześniej czy później narzędzie nie pozwoli zrobić czegoś, co członkowie systemu Kanban będą zrobić chcieli (i do czego zawsze mają prawo). Pojawi się ryzyko, że do czasu uaktualnienia reguł zapisanych w narzędziu tablica nie będzie odzwierciedlała faktycznego stanu poszczególnych work itemów (których po prostu nie będzie dało się przenieść do właściwego dla nich stanu na tablicy).

Dlatego implementując takie mechanizmy automatyzacji i wymuszania czegokolwiek zawsze należy pozostawić możliwość świadomego złamania reguł. Wszak narzędzia mają pomagać ludziom, którzy podejmują decyzje, a nie podejmować te decyzje za nich.

O jakich czynnikach tu mowa? Jednym z nich może być dodanie na tablicy informacji o przyczynie, dla której przepływ zablokowanego work itemu nie jest możliwy. Innym będzie oznaczenie, kto pracuje aktualnie nad określonym work itemem (jeśli takie przypisywanie się do nich jest praktyką w tym konkretnym systemie Kanban). Może to być informacja o zależnościach do innych work itemów, o kliencie, na rzecz którego prace są wykonywane, o nieprzekraczalnym terminie (ang. deadline), jeśli jakiś skojarzony jest z daną jednostką pracy, albo cokolwiek, co wpływa na decyzje podejmowane na bieżąco przez członków systemu Kanban.

Warto przy tym zachować umiar w prezentowaniu na tablicy informacji, które mogą być przydatne, ale nie są kluczowe przy aktywnym zarządzaniu przepływem. Jeśli w trakcie dyskusji konieczne jest sięganie do opisu poszczególnych work itemów i szukanie w nich konkretnej danej, to zapewne ta dana powinna być widoczna od razu. Jeśli dla odmiany widać od razu na tablicy coś, na co nikt i tak nie zwraca uwagi, to lepiej taką informację ukryć.

Dość często stosowane są kolory kart na tablicy kanbanowej do sygnalizowania różnych informacji o work itemach. O ile nie jest to naprawdę jednoznaczne, tablicę kanbanową powinno wyposażyć się wtedy w krótką legendę z wyjaśnieniem, co poszczególne kolory oznaczają. A jeśli jest ich bardzo dużo, zapewne warto poszukać innego (niż za pomocą kodowania kolorami) sposobu wizualizacji niektórych z informacji.

Jednym z typowych błędów, jakie pojawiają się w definicjach workflowu i ich wizualizacjach jest wprowadzenie osobnego stanu (i np. odpowiadającej mu kolumny na tablicy) na te work itemy, których przepływ jest zablokowany. Dlaczego to błąd?

Taki sztuczny stan, do którego przenoszone są itemy, nie jest tak naprawdę stanem workflowu. Znajdujące się w nim work itemy są przecież faktycznie w różnych stanach – takich, z jakich dla zasygnalizowania blokady zostały chwilowo wyciągnięte. Brak widoczności tego faktycznego stanu, w którym przepływ został zablokowany, może skutkować błędami decyzyjnymi odnośnie do sposobu usunięcia blokady.

Dodatkowy problem sprawi to w momencie, gdy WIP kontrolowany jest za pomocą zdefiniowanych dla różnych stanów workflowu limitów WIP. Jaki powinien być limit dla tego sztucznego stanu grupującego zablokowane jednostki pracy? Przecież potencjalnie wszystko, co stanowi WIP w danym momencie, może zostać zablokowane i wtedy wszystko musi być przeniesione do tego pseudo-stanu (więc nie bardzo można ustawić dla niego jakikolwiek sztywny limit). A z drugiej strony, skoro ten stan tak naprawdę jest sztuczny, work itemy znajdujące się w nim powinny wciąż liczyć się do WIP‑u w stanach, z których zostały wyciągnięte…

Jak widać, przez ten nieszczęsny pseudo-stan bardzo szybko zaczyna się rozjeżdżać informacja o WIP‑ie widoczna na tablicy kanbanowej z tym, jaki faktycznie jest WIP w poszczególnych stanach.

Dlatego oznaczenie blokad na tablicy najlepiej robić w ramach stanu, w jakim work itemy aktualnie się znajdują. No, chyba że stan zablokowany jest przewidzianym stanem w procesie, ale dziwaczny byłby to workflow, w którym brak przepływu jest czymś spodziewanym i z góry zaplanowanym.

Ten brak ograniczeń nie oznacza oczywiście, że decyzją członków systemu Kanban mogą pominąć oni niektóre z wymaganych elementów definicji workflowu. Jeśli to zrobią, w praktyce przestaną posługiwać się Kanbanem. Niewykluczone, że taka samodzielnie wykreowana strategia postępowania, inspirowana jedynie Kanbanem, będzie skuteczna, ale istnieje ryzyko, że przyniesie umiarkowane lub nikłe korzyści.

Postulat przejrzystości jest bardzo prosty i należy go rozumieć tak: w każdym momencie tablica kanbanowa odzwierciedla rzeczywisty stan work itemów znajdujących się w przepływie oraz wynik działania zasad stosowanych w tym systemie Kanban. Odkrycie, że tak nie jest, musi skutkować udoskonaleniem definicji workflowu.

Oczywiście nie zawsze jest możliwa aktualizacja stanu work itemów na tablicy w nieskończenie krótkim czasie po tym, gdy ten stan się zmienił. To naturalne, że pojawią się opóźnienia, ale nie powinny one nigdy wynikać z braku dbałości o utrzymanie tablicy kanbanowej. Jeśli jest ona aktualizowana zbyt wolno i korzystające z niej osoby mają świadomość tego faktu, ale nie dążą do wyeliminowania problemu, wtedy szanse na skuteczne utrzymywanie i optymalizację przepływu w takim systemie będą dramatycznie niskie.

Na liście nie wymieniono (ze względu na jej oczywistość) podstawowej formy aktywnego zarządzania pracą w toku, jaką jest efektywne wykonywanie pracy niezbędnej do uzyskania wartości w miarę, jak work item przepływa przez poszczególne stany workflowu. Efektywność oznacza w tym przypadku dobre wykorzystanie możliwości, jakimi dysponują członkowie systemu Kanban (narzędzi, praktyk, materiałów itd.).

Kontrolowanie WIP‑u ma spowodować, że wciągnięte do workflowu zostanie tylko tyle jednostek pracy, dla ilu możliwe jest zapewnienie przepływu. Jeśli liczba work itemów będzie zbyt duża, część z nich zacznie zalegać w stanach, w których aktualnie się znajdują, ponieważ ograniczone możliwości systemu Kanban (dostępność narzędzi, ludzi i materiałów) nie pozwolą pracować nad wszystkim, co stanowi część WIP‑u.

Skutkiem braku kontroli będzie wydłużenie czasu cyklu (tak jak podpowiada to wzmiankowane we wcześniejszych komentarzach prawo Little’a), ale też zmniejszy się przewidywalność, skuteczność i efektywność systemu Kanban.

Im bowiem dłużej trwa przepływ work itemów w nim i im częściej dochodzi do zatrzymania tego przepływu, tym bardziej poszczególne jednostki pracy są podatne na wystąpienie problemów, ograniczeń lub blokad.

Wydłużenie czasu cyklu zmniejszy możliwość reagowania systemu Kanban na nowe potrzeby, bo zajęcie się nimi nie będzie możliwe bez wcześniejszego ukończenia tego, co znajduje się już w WIP‑ie. To prowadzić będzie do ciągłej presji, by mimo już i tak nadmiernego WIP‑u wciągać do workflowu kolejne itemy.

Ponadto obsługa WIP‑u, który jest zbyt duży w stosunku do realnych możliwości systemu Kanban, wymaga nakładów pracy na przełączanie się pomiędzy realizowanymi równocześnie jednostkami pracy. Część wysiłków zamiast na kreowanie wartości pożytkowana jest na samo organizowanie pracy, jej zatrzymywanie, wznawianie itd.

Nieskuteczna kontrola nad WIP‑em może doprowadzić do nagromadzenia się work itemów w jednym lub kilku stanach przepływu, ale to nie jest jedyny scenariusz, który do tego prowadzi. Zdarza się, że WIP nie jest nadmierny, ale skoncentrowany został w jednym obszarze workflowu na skutek nienajlepszych decyzji członków systemu Kanban.

Czasami takie zjawisko jest pochodną nieprzemyślanej optymalizacji przepływu, która skupiła się nadmiernie na udrożnieniu jednego ze stanów workflowu bez wzięcia pod uwagę wpływu zmian na cały system Kanban. Mówimy wtedy o tzw. lokalnej optymalizacji (ang. local optimization).

Zapychanie się niektórych stanów jednostkami pracy (albo doprowadzanie do tego, że w innych stanach nie ma żadnych itemów) może być również spowodowane nieprzemyślanymi zasadami (ang. policies), które w sztuczny sposób hamują przepływ.

Bywa, że nagromadzenie pracy w jednym ze stanów wynika ze spóźnionej reakcji na zablokowany przepływ niektórych jednostek pracy. Jeśli w stanie X ugrzęźnie ze względu na jakąś blokadę maksymalna liczba itemów, jakie mogą w tym stanie jednocześnie się znaleźć w myśl obowiązujących limitów WIP, to zatrzyma to przepływ również w poprzednich stanach.

Mniej oczywistym powodem, dla którego może dochodzić do gromadzenia się itemów w jednym stanie, jest ignorowanie wieku jednostek pracy znajdujących się w WIP‑ie (to jedna z miar przepływu). Zamiast starać się przetwarzać itemy w miarę po kolei, tak jak były one wciągane do workflowu, członkowie systemu Kanban zaczynają niektórym z nich nadawać priorytet, aż w końcu jednostki przepływające szybciej spotkają się w jednym obszarze workflowu z tymi, które płyną nieco wolniej.

O ile kierowanie się priorytetami może być nieuniknione i czasami okazuje się korzystne, jest to w pewnym stopniu sprzeczne z ideą optymalizacji przepływu. Prowadzi do spowolnienia niektórych prac, które potencjalnie mogłyby zostać ukończone szybciej. Z drugiej strony część prac wykonywana jest naprawdę szybko (szybciej, niżby miało to miejsce bez nadania im priorytetu), co jest też pewnym zaburzeniem stabilności systemu Kanban.

Efektem kierowania się głównie priorytetami jest dodatkowo spadek przewidywalności (bo czas cyklu itemów zaczyna zależeć od dodatkowego uznaniowego czynnika, jakim jest właśnie priorytet) oraz pojawienie się długu przepływu (ang. flow debt). Bez wnikania w szczegóły, można ten dług opisać tak: niektóre work itemy płyną szybciej na kredyt (to jest właśnie ten dług przepływu), który potem trzeba spłacić spowolnieniem przepływu innych jednostek pracy.

Systemowym generatorem tego typu problemów są opcjonalne praktyki kanbanowe takie jak definiowanie różnych klas obsługi (ang. classes of service) lub tzw. szybkiej ścieżki (ang. expedite lane), które opierają się o różnicowanie priorytetu poszczególnych work itemów.

Natomiast podobne zjawisko może pojawić się wtedy, gdy work itemy zbyt mocno różnią się wielkością od siebie. Nawet gdyby obowiązywała zasada procesowania ich wedle kolejności, w jakiej zostały rozpoczęte (czyli gdyby kluczowym czynnikiem był wiek takich jednostek pracy), bardzo duże itemy będą w naturalny sposób przepływać wolniej. Może to spowodować, że w końcu dojdzie do nagromadzenia pracy w jednym ze stanów workflowu.

Dlatego warto świadomie dzielić zbyt duże itemy jeszcze nim zostaną one wciągnięte do workflowu.

Czy jest dopuszczalne ich podzielenie, gdy już stanowią część WIP‑u? Oczywiście, że tak, przy czym nieuchronną konsekwencją podziału będzie natychmiastowe zwiększenie WIP‑u (a tak naprawdę ujawnienie, że był on większy, niż wydawało się przed dokonaniem podziału). Nie należy tego unikać, w sztuczny sposób wypychając z workflowu jedną lub więcej takich jednostek pracy, które powstały w wyniku podziału, bo przecież dla nich przepływ już się rozpoczął. Po prostu w przypadku, gdyby okazało się, że WIP jest zbyt wysoki, w ramach kontroli nad nim trzeba doprowadzić jak najszybciej do jego obniżenia.

To stwierdzenie nawiązuje do jednej z miar kanbanowych, czyli do opisanego w jednym z kolejnych rozdziałów wieku jednostki pracy (ang. work item age, w skrócie WIA). Jest to informacja o czasie, jaki minął od wciągnięcia do workflowu konkretnej jednostki pracy, która wciąż znajduje się w WIP‑ie.

Jeśli przepływ jednostki pracy jest możliwy, ale nie następuje z jakiegoś powodu (bo nie wykonywana jest nad tą jednostką praca niezbędna do osiągnięcia kolejnego stanu workflowu), można mówić o zaleganiu tego itemu w aktualnym stanie. Czasami jest to z różnych powodów nieuniknione, ale aktywne zarządzanie WIP‑em polega właśnie między innymi na ograniczaniu i eliminowaniu tego zjawiska.

SLE, czyli oczekiwany poziom obsługi, to prognoza czasu cyklu, który członkowie systemu Kanban chcą zapewnić przynajmniej dla określonego odsetka work itemów. Przykładowo, może mieć to postać prognozy, że czas cyklu dla 75% itemów będzie wynosił dziesięć dni lub mniej.

Analizując listę itemów, które aktualnie znajdują się w przepływie (czyli stanowią WIP), można porównać ich bieżący wiek jednostek pracy (ang. work item age) z wartością czasu cyklu określoną w SLE. Krytycznie pilne staną się zapewne wtedy te itemy, których wiek już przekracza SLE. Nawiązując do przykładu powyżej, będą to itemy, które wciągnięte zostały do workflowu ponad dziesięć dni temu i wciąż nie zostały ukończone. One już wpadły w zbiór tych 25% jednostek pracy, dla których SLE nie udało się i nie uda dotrzymać.

Równie istotne będą te itemy, których wiek zbliża się do wartości SLE – dla nich wciąż możliwe jest dotrzymanie tej prognozy. Jeśli zostanie to zaniedbane, być może okaże się, że po pewnym czasie system Kanban już nie jest w stanie dotrzymywać swego SLE w ogóle.

Poprzez analogię: im wiek jednostek pracy jest niższy (im odleglejszy jest od wartości czasu cyklu ujętej w SLE), tym potencjalnie mniej pilnie należy zająć się takimi itemami. Oczywiście nie da się posłużyć tak prymitywnym algorytmem, bo konieczne jest uwzględnienie szerszego kontekstu:

• jakie możliwości działania mają członkowie systemu Kanban w danym momencie,
• czy work item nie jest zablokowany,
• czy ma zależności do innych itemów i będzie je potencjalnie blokował,
• czy nie jest w jakiś sposób wyjątkowy (np. jest istotnie większy niż pozostałe).

Dobrym narzędziem, które ułatwia tego typu analizy i pomaga w podejmowaniu decyzji, jest wykres starzenia się jednostek pracy (ang. work item aging chart), który prezentuje wszystkie jednostki pracy stanowiące WIP wraz z określeniem ich wieku oraz aktualnego stanu. Oczywiście dobrze skonstruowana tablica kanbanowa również może (a nawet powinna) pokazać te informacje.

Jednostka pracy, nad którą nie da się wykonywać żadnej pracy ze względu na jakieś ograniczenie, jest w oczywisty sposób zablokowana. Dopóki ograniczenie nie zostanie usunięte, nie będzie można przeprowadzić działań niezbędnych do przepływu tego itemu do kolejnego stanu, a tym samym uzyskać wartości, gdy workflow dla niej dobiegnie do końca.

Dużo mniej oczywistym jest, że zablokowany jest też w istocie taki work item, nad którym da się aktywnie pracować, ale dla którego nie da się aktualnie spełnić warunków wciągnięcia do stanu kolejnego. Inaczej mówiąc, część pracy da się wykonać, a części nie.

Uznanie w tej sytuacji, że dopóki jakąś pracę można wykonywać item nie jest zablokowany, byłoby nierozsądne. Jeśli już wiadomo, że po wykonaniu tej pracy nastąpi zderzenie z istniejącą blokadą, niekorzystne będzie odłożenie w czasie działań zmierzających do jej usunięcia. Zamiast bezrefleksyjnie kontynuować robienie tego, co jest możliwe, a dopiero potem zabiegać o odblokowanie przepływu, jak najwcześniej należy podjąć działania zmierzające do utrzymania tego przepływu.

Oczywiście to, czy w opisywanym przypadku work item zostanie formalnie oznaczony jako zablokowany czy nie, zależy od obowiązujących w systemie Kanban zasad (ang. policies).

Czy można uznać za zablokowany w przepływie jakikolwiek item dlatego, że nie ma kto nad nim aktualnie pracować? Nie, ponieważ jego przepływ jest możliwy, a to, że nie zachodzi, wynika wyłącznie ze sposobu organizacji pracy członków systemu Kanban.

Kolejne trudne pytanie: czy wysycenie limitów WIP w stanie X, które uniemożliwia wciągnięcie do niego itemów z poprzedzającego stanu Y, powinno być traktowane jako blokada? Również nie, ponieważ limity nie są obiektywną przyczyną, dla której przepływ nie jest możliwy. Work itemy w stanie Y, o ile spełniają w ogóle kryteria wciągnięcia do stanu X, nie są do niego wciągane z przyczyn procesowych, a nie ze względu na jakąkolwiek blokadę. Członkowie systemu Kanban mogą przecież zmienić ustanowione limity albo wręcz je złamać, jeśli zechcą.

Dokładnie tak samo nie można uznać jednostki pracy za zablokowaną, jeśli obowiązujące zasady wciągania (ang. pulling policies) nie pozwalają na jej przepływ do kolejnego stanu, bo nie spełnione są wymagane do tego warunki, ale da się wykonać pracę, by tę warunki spełnić.

Nieskuteczność w identyfikowaniu zablokowanych jednostek pracy i brak reakcji na takie blokady powodować będzie, że jednostki pracy będą zalegać tych stanach, w jakich aktualnie się znajdują. To może prowadzić do szeregu innych problemów wspomnianych we wcześniejszych komentarzach.

Aktywne zarządzanie pracą w toku powinno mieć miejsce w Kanbanie w każdym momencie, czyli jego częścią jest każda decyzja podejmowana na bieżąco przez członków systemu Kanban indywidualnie lub wspólnie.

Przegląd, o którym mowa w zaznaczonym fragmencie, to tylko jeden z przejawów aktywnego zażądania pracą w toku, a nie całość tej praktyki. Takie przeglądy nie są zresztą wymagane, ale zdecydowanie warto rozważyć ich wprowadzenie.

Przy czym nie chodzi tutaj o sprawdzenie samego procesu, czyli sposobu, w jaki aktywne zarządzanie pracą w toku (WIP‑em) jest realizowane. To również sprawdzenie aktualnie istniejącego WIP‑u na okoliczność tego, czy aktywne zarządzanie nim faktycznie ma miejsce. Inaczej mówiąc, chodzi też o sprawdzenie, czy itemy nie zostały zablokowane, czy nie zalegają w przepływie, czy nie jest ich zbyt wiele, czy nie skumulowały się w jednym stanie workflowu itd. Efektem każdego takiego sprawdzenia musi być podjęcie decyzji odnośnie do tego, którymi itemami i w jaki sposób zajmą się członkowie systemu Kanban.

Kanban nie wymaga pracy w kadencjach (iteracjach, interwałach), ale regularność sprawdzeń ułatwia członkom systemu Kanban identyfikowanie pozytywnych i negatywnych trendów. Częste i regularne przeglądy WIP‑u i sposobu zarządzania nim pozwalają też uniknąć ryzyka, że sprawdzenie odbywać się będzie zbyt rzadko, co skutkować będzie problemami choćby ze skutecznym kontrolowaniem WIP‑u.

Jeśli Kanban nałożony zostanie na iteracyjne metody, wtedy zapewne będzie możliwe wykorzystanie jednego ze zdarzeń takiej metod na potrzeby sprawdzenia skuteczności aktywnego zarządzania pracą w toku.

W Kanbanie nie zostały zdefiniowane żadne kadencje (iteracje lub interwały) ani powiązane z nimi zdarzenia procesowe, które miałyby odbywać się w określonej formie lub określonym czasie. Trzy wymagane praktyki mogą (ale nie muszą) być realizowane w formie różnych zdarzeń, odbywających się regularnie lub w indywidualnie wybranych momentach.

Natomiast Kanban jako strategia często łączony jest z metodami, które są iteracyjne i mają zdefiniowane zdarzenia, w trakcie których dokonuje się różnych przeglądów, synchronizacji wiedzy o stanie spraw itd. Jeśli to możliwe, powinny zostać one uzupełnione praktykami kanbanowymi lub posłużyć jako implementacja tych praktyk.

Przykładowo, jeśli system Kanban powstał z inicjatywy Zespołu Scrum, aktywne zarządzanie pracą w toku może stać się integralną częścią zdarzenia, jakim jest w tej metodzie Daily Scrum. W jego trakcie Developerzy pracujący nad produktem dokonują sprawdzenia, na ile adekwatne są plany osiągnięcia Celu Sprintu (ang. Sprint Goal), nad którym pracują. Na tej podstawie decydują o ewentualnym dostosowaniu tych planów. Jeśli to, co ma pozwolić na osiągnięcie Cel Sprintu, opisane jest work itemami w systemie Kanban, przegląd ich stanu w trakcie Daily Scruma ułatwi Developerom skuteczne planowanie każdego dnia.

Kontrola polega na zapewnieniu, że liczba work itemów wciągniętych (ang. pulled) do przepływu nie będzie zbyt wysoka i nie spowoduje, że niemożliwe stanie się zapewnienie ich optymalnego przepływu. Dlatego ważne jest ujawnienie rzeczywistej liczby itemów w momencie, w którym sprawdzenie jest dokonywane, a nie np. wyliczenie jakiejś ich średniej liczby w dowolnie wybranym okresie.

Zaznaczone zdanie bywa interpretowane jako wymóg stosowania limitów WIP, ale nie jest to obowiązkowa praktyka i możliwe jest stosowanie innych sposobów kontrolowania WIP‑u. Więcej na ten temat przeczytać można w kolejnych komentarzach.

Tablica kanbanowa może być skonstruowana w ten sposób, że istnieje ograniczone miejsce na umieszczanie na niej work itemów w poszczególnych stanach workflowu. Te miejsca to właśnie wspomniane sloty. W ten sposób nie można wciągnąć do workflowu ani do żadnego stanu w nim kolejnych itemów, jeśli wszystkie takie sloty są zajęte.

Możliwe też jest zastosowanie fizycznych tokenów, których w systemie zdefiniowanych jest tylko tyle, ile jednostek pracy może znaleźć się równocześnie w WIP‑ie. Aby wciągnąć nowy work item do workflowu, trzeba przytroczyć do niego jeden z tych tokenów. Jeśli nie jest on aktualnie dostępny, wciągnięcie nie może nastąpić do momentu, aż jakiś token się zwolni.

Warto wspomnieć, że tokeny są najstarszym rozwiązaniem, z jakim można było zetknąć się w Kanbanie, a sama strategia pośrednio wywodzi od nich swą nazwę. Tokeny takie nazywane były sygnałami (ang. signal), bo ich pojawienie się (odpięcie od czegoś, co zostało zrealizowane i opuściło WIP), sygnalizowało możliwość wciągnięcia do WIP‑u nowego work itemu. Tablica, na której wizualizowane były sygnały, nazywana była w języku japońskim 看板 (jest to połączenie słowa znak w znaczeniu sygnału ze słowem tablica) – co wymawia się właśnie jako kanban.

Kontrolowanie WIP‑u za pomocą slotów lub tokenów nie jest bardzo popularne. Częściej można z tym zetknąć się w branżach produkcyjnych, gdzie praca polega na wytwarzaniu np. fizycznych części jakiegoś urządzenia niż przy pracy intelektualnej albo budowaniu produktów wirtualnych takich, jak np. oprogramowanie.

Zarówno tokeny jak i sloty mają też wadę, która może spowodować, że nie będą najlepszym wyborem dla niektórych systemów Kanban. Są bardzo proste w użyciu, ale utrudniają przekroczenie utrzymywanych przez nie limitów, gdyby członkowie systemu Kanban podjęli decyzję, że należy to zrobić. Konieczne jest wytworzenie nowego tokena lub zdefiniowanie dodatkowego slotu (slotów) na tablicy, bo bez tego zwiększenie WIP‑u nie będzie możliwe. A z drugiej strony, jeśli to zwiększenie jest tymczasowe, dodane tokeny lub sloty zaraz trzeba będzie usuwać…

Dlaczego ktokolwiek chciałby przekraczać ustalone limity WIP i czy w ogóle jest to dopuszczalne? Tak, można to zrobić, podobnie jak decyzją członków systemu Kanban mogą być złamane wszystkie ustanowione w nim zasady (ang. policies). Nie może to być zabronione z tej prostej przyczyny, że wszystkie procesy (a więc i zasady w nich obowiązujące) nie są przygotowane do obsługi każdej możliwej sytuacji i trzymanie się ich za wszelką cenę uniemożliwiałoby podjęcie niezbędnych działań, gdy zdarzy się coś niezwykłego.

Gdy więc dojdzie do sytuacji absolutnie wyjątkowej, członkowie systemu Kanban muszą na to adekwatnie zareagować. Absurdem byłoby jednak dostosowywanie procesu tylko po to, by od teraz przewidywał on taką wyjątkową sytuację. Skoro jest ona czymś niezwykłym, proces z definicji nie będzie do niej przystawał, ale też nie powtórzy się ona ponownie (o ile faktycznie jest wyjątkowa), więc zmiana w procesie byłaby niepotrzebną stratą czasu i komplikowałaby sam ten proces (bo po każdym takim zdarzeniu przyrastałaby liczba zasad, dopuszczalnych wyjątków itd.).

A jeśli już mowa o złamaniu obowiązującego limitu WIP, może do niego dojść bardzo łatwo np. wtedy, gdy członkowie systemu Kanban zdecydują o podziale zbyt dużego work itemu na dwa mniejsze. Ten item już znajduje się wtedy w WIP‑ie, więc w wyniku podziału oba wynikowe itemy też będą częścią WIP‑u. Jeśli przed podziałem limity WIP były w pełni wykorzystane, teraz nagle staną się przekroczone. Podniesienie limitów tylko po to, by nie były naruszone, ukryłby jedynie ten fakt i otwierałby przestrzeń do systemowego zwiększenia WIP‑u od tego momentu. Konieczne jest oczywiście jak najszybsze zredukowanie WIP‑u do poziomu przewidzianego limitami – poprzez jak najszybsze ukończenie tego, co w WIP‑ie się już znajduje.

Inny zupełnie naturalny scenariusz, gdy system Kanban nagle zacznie łamać ustalone limity WIP, jest jeszcze prostszy: członkowie systemu Kanban odkrywają, że limity są zbyt wysokie i muszą zostać zmniejszone, bo work itemy zaczynają zalegać w różnych stanach workflowu. A ponieważ aktualnie limity są w pełni wykorzystane, ich obniżenie natychmiast spowoduje, że nowe wartości będą przekroczone. Będzie to jednocześnie sygnał, że teraz trzeba doprowadzić do zmniejszenia WIP‑u do tego niższego poziomu.

Błędem byłoby w tej sytuacji odwrotne działanie, czyli najpierw doprowadzenie do obniżenia WIP‑u do poziomu docelowych limitów WIP, a dopiero potem ich formalne przedefiniowanie. Owszem, w ten sposób system Kanban nigdy nie złamałby obowiązujących limitów – więc wydaje się to rozsądnym działaniem. Niestety stanowi naruszenie jawności i jednoznaczności zasad, w tym przypadku tych dotyczących kontrolowania WIP‑u: formalnie obowiązywałyby limity wyższe (jeszcze nie zmienione) niż te, którymi aktualnie kierują się członkowie systemu Kanban (docelowe).

Przy okazji warto wspomnieć, że limity WIP, jeśli już są wprowadzone, powinny być co do zasady w pełni wykorzystywane. Jeśli z jakiegoś powodu członkowie systemu Kanban nigdy nie wciągają do workflowu tyle jednostek pracy, ile faktycznie może się w nim znaleźć, to znaczy, że te limity w ogóle nie mają wpływu na podejmowanie decyzji o wciągnięciu. Jeśli tak, podstawą do tego jest zapewne co innego. To oznacza, że takie limity WIP nie stanowią faktycznego mechanizmu kontrolowania WIP‑u, a co gorsza, że kontrola ta opiera się o niejasne lub niezdefiniowane zasady.

Limity WIP są skuteczne, jeśli regularnie uwierają członków systemu Kanban. Mają zmuszać ich do aktywnego poszukiwania sposobu ukończenia prac nad tym, co już znajduje się w WIP‑ie, zanim wciągnięte do niego zostaną kolejne jednostki pracy. Nie ma to być ostateczna linia obrony przed zadławieniem systemu Kanban, ale linia pierwsza.

Z drugiej strony limity WIP nie mogą sztucznie zadławiać systemu Kanban, czyli konieczne jest poszukiwanie takiego ich poziomu, by wciąż zmuszały do aktywnego zarządzania pracą w toku, ale nie obniżały skuteczności działania systemu.

Czy limit WIP może być zdefiniowany bez nawiązywania do stanów workflowu albo tablicy kanbanowej? Oczywiście, że tak. Limit może być zdefiniowany globalnie dla całego WIP‑u, niezależnie od tego, w jakich stanach znajdują się poszczególne work itemy, które się na niego składają. Może być też zdefiniowany np. osobno dla każdego typu work itemów, jeśli definicja workflowu je rozróżnia.

Jeśli stosowane są klasy serwisu (ang. classes of services), limity WIP mogą być zdefiniowane osobno dla każdej z nich, np. dopuszczając, by w WIP‑ie w danym momencie znajdowało się maksymalnie pięć jednostek pracy klasy X i nie więcej niż trzy klasy Y.

Podobnie rzecz wygląda w przypadku innej opcjonalnej praktyki, jaką jest tzw. szybka ścieżka (ang. expedite lane): rozsądek podpowiada, by WIP limit dla tej ścieżki wynosił dokładnie jeden, ponieważ służyć ona ma nadaniu priorytetu jednej konkretnej rzeczy nad całą resztą WIP‑u. Jeśliby ścieżką tą przepływał cały szereg work itemów, używana byłaby ona nieustannie, a to w praktyce byłoby tożsame nie tyle z istnieniem jakiegokolwiek expedite lane, co z niejawnym wprowadzeniu klasy serwisu o podwyższonym priorytecie.

Czy można zdefiniować WIP limit w odniesieniu do członków systemu Kanban, czyli ustalić, nad iloma rzeczami na raz każdy z nich może pracować? Cóż, nie jest to zabronione, ale z wielu przyczyn nie ma sensu.

Pierwsza przyczyna to obawa, że tak definiowane limity będą popychać system Kanban w stronę skupienia przede wszystkim na przepływie pracy rozumianej dosłownie (zadaniach do wykonania), a nie na przepływie wartości.

Druga kwestia to trudność z praktycznym zapewnieniem, że taka kontrola WIP‑u w ogóle będzie działać. Przecież ludzie często potrzebują pomocy od współpracowników – bardzo szybko dojdzie więc do sytuacji, w których każdy członek systemu Kanban realnie i tak pracował będzie nad nadmierną liczbą rzeczy na raz, albo mocno utrudniona zostanie wszelka współpraca.

Trzeci problem to kwestia samej wizualizacji aktualnego wysycenia tak zdefiniowanych limitów. Może to wymusić skupienie tablicy na osobach, a nie na stanach workflowu i znajdujących się w nich work itemach. A nawet jeśli do tego nie dojdzie, czytelność tablicy kanbanowej może być niska, bo konieczne będzie oznaczenie na niej, kto nad czym aktualnie pracuje.

Czwarta kwestia wreszcie: jeśli ktokolwiek będzie musiał wziąć nieplanowany urlop albo zachoruje, co stanie się z tymi itemami, nad którymi pracował? Ktoś może je przejąć, ale złamie w ten sposób swój limit WIP. Owszem, łamanie limitów WIP jest dopuszczalne, ale w sytuacjach naprawdę wyjątkowych, a ciężko za takie zdarzenie uznać zupełnie typową (choć nieplanowaną) nieobecność pracownika. Alternatywą byłoby pozostawienie takich itemów, by zalegały w przepływie do czasu, aż komuś zwolni się limit WIP i będzie mógł się nimi zająć. Żadne z tych rozwiązań nie jest tak naprawdę dobre i nie zasługuje na nazwanie optymalizacją przepływu.

Podane w oznaczonym fragmencie przykłady odnoszą się do typowych tablic kanbanowych w formie tabel z kolumnami, które reprezentują stany workflowu. Oczywiście zupełnie poprawnym będzie użycie w tym celu wierszy takiej tabeli albo w ogóle odejście od formy tabelarycznej tablicy.

Czym jest lane na tablicy kanbanowej? W języku polskim nazywa się to zwykle potokiem, a w angielskim funkcjonuje też termin swimlane. Taki potok to przecięcie tablicy wskroś poprzez stany workflowu po to, by płynęły nim zgrupowane wedle jakiegoś klucza jednostki pracy (np. wybrane typy itemów).

Limity WIP zazwyczaj definiowane są osobno dla każdego stanu workflowu, ale to nie zawsze ma sens. Zdarza się, że limit jest jeden (dla całej tablicy, czyli dotyczy WIP‑u jako całości), natomiast o tym, ile jednostek pracy znajduje się aktualnie w każdym ze stanów decydują różne zasady (ang. policies).

Uwaga: jeśli jakiś stan workflowu na tablicy kanbanowej został dla poprawienia czytelności podzielony na część aktywną i pasywną (ta pierwsza grupuje itemy, które są właśnie przetwarzane w tym stanie, ta druga itemy, dla których to przetwarzanie już się zakończyło i czekają na wciągnięcie do stanu kolejnego), to limit WIP, jeśli jest zdefiniowany dla tego stanu, dotoczy jednocześnie obu jego części. Jeśli np. wynosi on cztery, to w części aktywnej i pasywnej jednocześnie nie może znaleźć się więcej niż cztery jednostki pracy.

Warto pamiętać też o tym, że można wprowadzić równocześnie wiele różnych sposobów zdefiniowania limitów WIP, ale trzeba zachować przy tym umiar i zadbać o to, by dało się je łatwo stosować. Jeśli ustalenie czy limity WIP nie są przekroczone będzie problematyczne lub czasochłonne, przestaną one w praktyce działać.

W zaznaczonym zdaniu chodzi oczywiście o efekt skutecznej kontroli WIP‑u, czyli takiej, dzięki której system Kanban chroniony jest przed wciągnięciem (ang. pulling) zbyt dużej liczby jednostek pracy.

Dlatego np. samo zdefiniowanie limitów WIP, jeśli są one użyte jako mechanizm kontroli, nie gwarantuje powstania systemu wciągania pracy (ang. pull system), ponieważ limity te mogą być zbyt wysokie, albo mogą nie być przestrzegane. Gdy przekroczone zostaną możliwości członków systemu Kanban, przepływ zacznie być zaburzony, spowolniony lub nawet zatrzyma się dla niektórych work itemów.

Termin pull system doczekał się w polskojęzycznej literaturze kilku tłumaczeń, z których niektóre są dość karkołomne.

I tak można zetknąć się z systemem ciągnionym, co jest o tyle kłopotliwe, że ciągnienie to termin związany z obróbką np. stali (niekoniecznie pasuje to do Kanbana), ewentualnie z losowaniem liczb, kul, kopert itd. Wciąganie jednostki pracy do przepływu nie polega jednak na jej fizycznym rozciąganiu ani nie powinno opierać się o losowanie – zresztą czasami mówi się też o ich selekcji (ang. selection), a tej dokonujemy zawsze świadomie wedle jakichś kryteriów.

Równie zawadiackim językowo i przy okazji zabawnym tłumaczeniem określenia pull system jest system ssący lub system zasysający. Oczywiście czasownik pull nie ma wiele wspólnego ze ssaniem lub zasysaniem, a widząc napis pull to exit na drzwiach nie zasysamy ich tylko ciągniemy do siebie.

Czasownik pull ma w języku angielskim kilka znaczeń. Aż trzy z nich dobrze pasują do idei optymalizacji przepływu w Kanbanie:

• move steadily in a specified direction or manner, czyli przemieszczać się systematycznie w określonym kierunku – tak, jak jednostki wartości (work itemy) w systemie Kanban powinny przepływać od początkowego punktu workflowu do jego końca,
• excert force on someone or something so as to cause movement towards oneself, czyli wywierać siłę na kogoś lub coś, aby spowodować przemieszczenie w swoją stronę – tak, jak work itemy w systemie Kanban wciągane są do kolejnych stanów workflowu by przybliżyć się do uzyskania wartości,
• retrieve an item of data from the top of a stack, czyli w systemach informatycznych pobrać element danych ze szczytu stosu celem ich przetworzenia – tak, jak w systemie Kanban do workflowu pobierane są kolejne work itemy celem ich przeprocesowania, żeby wykreować wartość.

Najlepszym dosłownym odpowiednikiem w języku polskim byłby zatem najpewniej system ciągnięcia. Natomiast to, co stosunkowo dobrze brzmi w języku angielskim, nieco kuleje przy takim mechanistycznym przekładzie, stąd wybór nieco rozszerzonego w stosunku do oryginału terminu, jakim jest system wciągania pracy.

Rozpoczęcie pracy nad dowolnym work itemem może nastąpić dopiero wtedy, gdy spełnione są ustalone dla konkretnego systemu Kanban warunki, najczęściej mające formę zasad wciągania jednostek pracy (ang. pulling policies), ewentualnie również zasad kontrolowania WIP‑u (ang. WIP controlling policies).

Oczywiście ten proces nie jest automatyczny, a ostateczną decyzyjność odnośnie do tego, czy wciągnięcie powinno nastąpić i co powinno zostać wciągnięte, mają członkowie systemu Kanban. Z faktu, że dokonują oni w istocie wyboru work itemu, jaki zostanie wciągnięty, zamiennie stosowany bywa tutaj czasownik pull lub select (polskie odpowiedniki to wciągać i wybierać).

Sygnał, o którym mowa w zaznaczonym zdaniu, oraz możliwości wykonania pracy (bo tak należałoby przetłumaczyć angielski termin capacity), to informacja która wskazuje, że wciągnięcie nowej jednostki pracy do workflowu może (ale nie musi) nastąpić. Co może być takim sygnałem? Np. spadek WIP‑u poniżej ustalonego limitu albo spełnienie warunków zawartych w obowiązujących zasadach (ang. pulling policies).

Przy czym sygnał ten informuje zawsze jedynie, że praca może zostać rozpoczęta. W praktyce jest mało prawdopodobne, by dało się skonstruować taki system Kanban, w którym sygnał stanowi jednocześnie gwarancję, że pracę będzie też dało się ukończyć.

Dlatego pojawiająca się czasami w różnych miejsca definicja systemu wciągania pracy jako systemu, do którego praca wciągana jest dopiero wtedy, gdy istnieje możliwość jej wykonania, jest błędna. To wciąganie następuje wtedy, gdy rozpoczęcie pracy jest możliwe – o tym, czy możliwe będzie jej ukończenie zdecyduje przyszłość i umiejętności członków systemu Kanban w zakresie aktywnego zarządzania pracą w toku.

Zaznaczony fragment jest o tyle kłopotliwy, że wydaje się pozostawać w pewnej sprzeczności z brakiem wymogu użycia limitów WIP jako sposobu kontrolowania tego WIP‑u. Ta sprzeczność jest o tyle pozorna, że tym razem chodzi po prostu o poziom WIP‑u, który jest uznawany za akceptowalny w konkretnym systemie Kanban. W jaki sposób spowodować, by poziom ten nie był przekraczany, pozostaje w gestii członków tego systemu Kanban.

Pojawienie się sygnału, że można wciągnąć kolejne jednostki pracy do WIP‑u, nie stwarza oczywiście obowiązku, by to zrobić. Tym niemniej, skoro celem istnienia systemu Kanban jest dostarczanie wartości, a ta pojawia się w wyniku wykonania pracy nad work itemami, niewciągnięcie ich do WIP‑u, gdy istnieje taka możliwość, nie wydaje się rozsądną decyzją. Jeśli jakiś czynnik powoduje, że jednak takie wciągnięcie nie powinno nastąpić, być może sposób kontrolowania WIP‑u jest nieprawidłowy, skoro sygnalizuje błędnie tę możliwość.

Tak będzie w szczególności wtedy, gdy limity WIP są zbyt wysokie i członkowie systemu Kanban celowo ich nie wysycają z obawy, że spowoduje to problemy z utrzymaniem przepływu. W praktyce oznacza to, że posługują się oni limitami niższymi, niż te formalnie zdefiniowane. A to powoduje, że zasady wciągania nie są jawne i jednoznaczne. Niezbędnym działaniem w takiej sytuacji jest urealnienie limitów WIP, zastąpienie ich jawnymi zasadami albo zrobienie obu tych rzeczy na raz tak, by kontrola nad WIP‑em przestała generować sprzeczne sygnały o możliwości wciągnięcia itemów do workflowu.

Do złamania ustalonych limitów WIP może dojść w sytuacjach absolutnie wyjątkowych, których obsługi żaden proces i tak nie przewidzi i w związku z rzadkością ich występowania nawet nie powinien przewidywać.

Może też dojść do tego w sytuacjach zupełnie normalnych w ramach aktywnego zarządzania pracą w toku. A dokładniej w dwóch konkretnych przypadkach.

Jeden z nich to obniżenie limitów WIP w sytuacji, gdy są one w pełni wykorzystane, ale w opinii członków systemu Kanban zbyt wysokie. Do czasu obniżenia WIP‑u do nowego poziomu przewidzianego zmienionymi limitami, fakt ich przekroczenia będzie ujawniał konieczność powstrzymywania się od wciągania do workflowu nowych jednostek pracy.

Drugi to podział dużego work itemu na kilka mniejszych już po jego wciągnięciu do WIP‑u. Powoduje to złamanie limitów WIP, bo ujawnia się, że w istocie wciągnięte zostało do przepływu więcej pracy, niż się to początkowo wydawało. Dzięki temu członkowie systemu Kanban widzą, że trzeba doprowadzić do ponownego obniżenia WIP‑u do poziomu opisanego limitami.

Uwaga: złamanie limitów WIP, nawet intencjonalne, nie powinno skutkować ich zmianą (podwyższeniem), ponieważ to ukrywałoby problem, jakim jest nadmierna wielkość WIP‑u. Fakt złamania limitów będzie wywierał presję, by doprowadzić do jak najszybszego zmniejszenia WIP‑u.

Gdyby limity na jakiś czas zostały podniesione, by w pewien sposób uprawomocnić taki zwiększony WIP, istnieje ryzyko, że pozostanie on od tego czasu stale na takim poziomie. Nie będzie bowiem widoczne (w postaci przekroczonych limitów), że jest to sytuacja wyjątkowa. To może doprowadzić do utraty kontroli nad WIP‑em i spowodować, że aktywne zarządzanie pracą w toku będzie nieefektywne lub całkowicie nieskuteczne.

I jeszcze jedna uwaga odnośnie do opcjonalnej praktyki definiowania tzw. szybkiej ścieżki (ang. expedite lane). Każdy work item, który przepływa tą ścieżką i omija inne jednostki pracy znajdujące się w WIP‑ie, efektywnie powodując ich zatrzymanie lub spowolnienie ich przepływu, powinien łamać w widoczny sposób limity WIP.

Zdecydowanie nie jest dobrym pomysłem pozostawianie w limitach WIP celowo przestrzeni na takie itemy, by mogły sobie płynąć szybką ścieżką, bo wtedy ciągle jakieś expedite work items będą z tej możliwości korzystać. A to negatywnie wpłynie na pozostałe jednostki pracy (czyli ich zdecydowaną większość).

Jednocześnie warto wprowadzić dodatkowy limit WIP dla samej szybkiej ścieżki i zapewne nikogo nie zdziwi, że powinien on wynosić dokładnie jeden. Jeśli będzie wyższy, to kontrola WIP‑u będzie mało efektywna, a expedite lane stanie się tak naprawdę kolejną priorytetową klasą serwisu (ang. class of service).

Przy czym te zalecenia nie są zdefiniowane jako część Kanbana, a szybka ścieżka jest praktyką opcjonalną. Najlepiej po nią nie sięgać, jeśli nie jest to niezbędne, ale gdy już jest zdefiniowana, pozostaje w kwestii członków systemu Kanban, w jaki sposób będzie funkcjonować.

Kanban sprzyja dekompozycji tzw. silosów kompetencyjnych, które objawiają się istnieniem podgrupek ludzi o określonych specjalnościach, ewentualnie pojedynczych osób (ekspertów w jakiejś dziedzinie), pomiędzy którymi przerzucana jest praca. Taki sposób zarządzania pracą wymaga sporo koordynacji oraz planowania i prowadzi nieuchronnie do zatrzymywania się przepływu work itemu za każdym razem, gdy silos o kompetencjach niezbędnych do wykonania aktualnie niezbędnych działań jest zajęty innymi jednostkami pracy.

Przy czym wspomniane silosy mogą zostać wzmocnione, jeśli definicja workflowu skonstruowana zostanie tak, by odzwierciedlić to przerzucanie pracy pomiędzy ludźmi o różnych kompetencjach. Dlatego warto definiować stany workflowu tak, by określały one nie co i kto ma zrobić, ale jaki cel ma być w nich osiągnięty. To pozostawia przestrzeń członkom systemu Kanban do elastycznego wykorzystywania kompetencji, jakie posiadają, by cel taki osiągnąć jak najszybciej i jak najefektywniej.

Dojrzałe zespoły, które posługują się Kanbanem, stosują często praktyki takie jak mob‑programming lub swarming, które polegają na skupieniu kilku osób, a czasami i całego zespołu, na tym work itemie, który w tym momencie wymaga najwięcej uwagi.

Osoby posługujące się Scrumem bez wątpienia zauważyć mogą, że wymienione w zaznaczonym zdaniu skupienie oraz zaangażowanie to dwie z pięciu Wartości Scrum. Użycie Kanbana w połączeniu z tą metodą będzie zatem sprzyjać wzmocnieniu tych Wartości, dzięki którym wzrośnie potencjał do uzyskania wymiernych korzyści z działań w Scrumie.

W zaznaczonym stwierdzeniu nie chodzi o to, by definicja workflowu zawierała listę przypadków, kiedy dopuszczalne jest niekontrolowane zwiększenie się WIP‑u. Chodzi o określenie warunków, kiedy przyjęty sposób kontroli WIP‑u może być zastąpiony innym mechanizmem przy podejmowaniu decyzji o wciągnięciu konkretnego work itemu do WIP‑u. Kontrola ta wciąż się więc odbywa.

Przykładem takiego ustalenia jest zastosowanie tzw. szybkiej ścieżki w procesie (ang. expedite lane) w połączeniu z kontrolowaniem WIP‑u za pomocą ustalonych limitów. W systemie Kanban może wtedy obowiązywać reguła, że jednostka pracy przepływająca przez szybką ścieżkę może łamać limity WIP w poszczególnych stanach workflowu, ale wyłącznie o wartość jeden i wyłącznie w jednym stanie na raz.

Efektywnie oznacza to, że każde użycie szybkiej ścieżki jest wyjątkową sytuacją i nie może z niej korzystać więcej niż jeden work item równocześnie. Z drugiej strony wyjątek ten jest przewidziany w definicji workflowu.

Oczekiwany poziom obsługi jest prognozą czasu cyklu (bo tym jest czas przepłynięcia jednostki pracy od początku do końca workflowu) obowiązującą dla każdego pojedynczego work itemu, jaki zostanie wciągnięty do WIP‑u.

Nie jest to natomiast prognoza wartości średniej tego czasu. Nie chodzi też o to, by wstrzelić się dokładnie w ten czas cyklu i by wszystkie work itemy były realizowane dokładnie tak długo, jak określa to SLE. To oczywiste, że część jednostek pracy zostanie ukończona szybciej, a niektóre będą miały czas cyklu przekraczający prognozę z SLE.

Członkowie systemu Kanban muszą zabiegać o to, by każdy work item został ukończony w czasie nie dłuższym niż zawarty w SLE. Ten czas zawsze powinien być tak krótki, jak to możliwe, bo im szybciej coś jest zrobione, tym wcześniej przyniesie to wartość wynikłą z ukończenia prac. Nie mówiąc już o tym, że szybszy przepływ czyni work itemy mniej podatnymi na zaburzenia i nieprzewidziane blokady.

Jeśli SLE zostało sformułowane w ten sposób, że 85% work itemów zostanie ukończonych w osiem dni lub szybciej, to oznacza jednocześnie, że członkowie systemu Kanban prognozują, iż istnieje 85‑procentowe prawdopodobieństwo ukończenia każdego work itemu w takim czasie. Obie formy przedstawiania SLE są poprawne, a która z nich jest wygodniejsza i bardziej zrozumiała, jest kwestią indywidualną. Oczywiście 85% i osiem dni to wartości przykładowe.

Warto przypomnieć dobrą praktykę, wspomnianą już w jednym z wcześniejszych komentarzy, a polegającą na podawaniu prognoz – w tym przypadku SLE – od poinformowania o prawdopodobieństwie, jakie z prognozą się wiąże. To obniża ryzyko, że rozmówca zignoruje tę kluczową część prognozy. Dlatego informując kogokolwiek o SLE należy unikać mówienia, że to osiem dni lub krócej z prawdopodobieństwem 85%. Mówmy zamiast tego, że na 85% praca nad realizacją work itemu potrwa osiem dni lub krócej.

Typowym błędem, jaki popełniany jest przy określeniu SLE, jest oparcie tej prognozy na średnim czasu cyklu wyliczonym dla jakiegoś okresu funkcjonowania systemu Kanban lub zbioru zrealizowanych work itemów. Wartości średnie w istocie są zwodnicze, bo wydają się czymś prawdopodobnym nawet wtedy, kiedy w ogóle nie mogą wystąpić (przykład: na każdej ściance kostki do gry znajduje się średnio 3.5 oczka, ale przecież żadna z tych ścianek nie ma dokładnie tyle oczek i prawdopodobieństwo wyrzucenia takiej wartości kostką jest dokładnie zerowe).

O jakim kalkulowaniu SLE na bazie historycznych czasów cyklu jest tu więc mowa? Chodzi nie o średnią wartość czasu cyklu dla zrealizowanych work itemów, ale o percentyle tego czasu. Czym one są najłatwiej wyjaśnić na przykładzie.

Jeśli dysponujemy wiedzą o czasu cyklu dla stu jednostek pracy, możemy spośród nich wybrać 50% takich, które ukończone zostały najszybciej. Następnie możemy ustalić, jaki był najdłuższy czas cyklu dla tego podzbioru 50% itemów. Powiedzmy, że jest to siedem dni. To oznacza, że 50% work itemów, jakimi dysponujemy, zostało zrealizowanych w czasie siedmiu dni lub krótszym. Można też powiedzieć, że maksymalny czas cyklu dla pięćdziesiątego percentyla wynosi siedem dni.

Przy okazji: ten pięćdziesiąty percentyl, zapisywany często jako 50 percentyl (ang. 50^th percentile) jest zarazem medianą czasu cyklu dla wszystkich stu rozważanych w przykładzie work itemów.

Możemy powtórzyć tę kalkulację dla 70% work itemów, które mają najniższy czas cyklu i wyliczyć w ten sposób 70 percentyl czasu cyklu. Powiedzmy, że otrzymaliśmy wynik dziewięciu dni.

Analogicznie można wyliczyć 85 percentyl (wynoszący przykładowo jedenaście dni) oraz 95 percentyl (przykładowo: dwanaście dni).

Zbierając to w całość:

• 50% work itemów ukończonych zostało w 7 dni lub szybciej (50 percentyl),
• 70% work itemów ukończonych zostało w 9 dni lub szybciej (70 percentyl),
• 85% work itemów ukończonych zostało w 11 dni lub szybciej (85 percentyl),
• 90% work itemów ukończonych zostało w 12 dni lub szybciej (95 percentyl).

Oznacza to jednocześnie, że:

• prawdopodobieństwo ukończenia prac w czasie maksymalnie 7 dni, wynosi 50%,
• prawdopodobieństwo, że będą one ukończone w nie więcej niż 9 dni, to 70%,
• prawdopodobieństwo, że zajmie to dni 11 lub mniej, wynosi 85%,
• prawdopodobieństwo, że najdłużej w 12 dni prace zostaną zakończone, to 95%.

Członkowie systemu Kanban mogą wykorzystać wartość jednego z tych percentyli wprost jako SLE. Mogą też, kierując się uzyskanymi w ten sposób wartościami, przyjąć SLE nieco bardziej ambitne i dążyć do jego dotrzymywania (co jest na pewno pożądane).

Skąd akurat takie percentyle: 50, 70, 85 i 95? Są one stosowane najczęściej, ale nie są w żaden sposób jedynymi, jakimi można się posłużyć.

Warto percentyle wyliczać co jakiś czas (niektóre narzędzia elektroniczne potrafią robić to wręcz na bieżąco) z dwóch powodów. Po pierwsze, jeśli pojawią się zmiany wartości tych percentyli, może to być podstawą do zmiany SLE używanego w definicji workflowu. Po drugie, można śledzić trendy zmian wartości percentyli na przestrzeni czasu: jeśli skojarzone z nimi czasy cyklu spadają, może to wskazywać (choć nie musi) na skuteczne udoskonalenie przepływu. Przez analogię, wzrost tych czasów cyklu może być sygnałem, że przepływ ulega powolnej degradacji.

Bardzo specyficznym i wartym uwagi jest 50 percentyl (lub po prostu mediana czasu cyklu). Nawet, jeśli nie został on wybrany jako SLE (a prawdę mówiąc raczej nierozsądnie byłoby go użyć w tym celu, bo to byłaby prognoza rodzaju 50/50), wiele zespołów korzystających z Kanbana posługuje się nim w uzupełnieniu do SLE.

Do czego go używają? 50 percentyl określa czas, w którym połowa zrealizowanych dotychczas jednostek pracy została ukończona. Jeśli jakikolwiek work item znajduje się w WIP‑ie dłużej, niż czas zawarty w 50 percentylu to znaczy, że już znalazł się w tej połowie rzeczy, których realizacja przebiega najwolniej. To sygnał ostrzegawczy nakazujący zwrócić na ten work item uwagę.

Kolejnym takim sygnałem, tym razem alarmowym, jest zbliżenie wieku jednostki pracy do czasu prognozowanego w obowiązującym SLE.

Sama wiedza o tym, jakie SLE zostało ustalone dla systemu Kanban, nie wystarczy – prognoza ma być widoczna wprost na tablicy Kanbanowej. W jakiej formie zostanie przedstawiona pozostaje w gestii członków systemu Kanban.

Dlaczego to takie ważne? Jednym ze sposobów identyfikacji, na których work itemach skupić powinni się aktualnie członkowie systemu Kanban, jest porównanie wieku tych work itemów właśnie z prognozą czasu cyklu zawartą w SLE.

Brak widoczności SLE i przyjęcie, że każdy wie, co ustalono i co zawiera ta prognoza, prowadzi zwykle do błędów decyzyjnych. Pojawiają się rozbieżności w wiedzy o faktycznym SLE albo realnie nie jest ono do niczego używane. A bez tego nie sposób realizować skutecznie aktywnego zarządzania pracą w toku.

Brak danych do określenia SLE wymusi na członkach systemu Kanban oszacowania tak wartości czasu cyklu, jaki realnie są w stanie zapewnić work itemom, z którymi będą pracować, jak i poziomu niepewności dla tego oszacowania.

Większość osób ma gorsze lub lepsze doświadczenia z szacowaniem czasu wykonania pracy, więc z uzgodnieniem prognozy czasu cyklu zapewne sobie poradzą. Gorzej może być z oceną prawdopodobieństwa dotrzymania tego czasu cyklu. Jak zrobić to najprościej?

Warto skorzystać z tego, że SLE można przedstawić w formie prognozy tego, jaki odsetek work itemów uda się zrealizować w określonym czasie. Zamiast silić się na wyliczenie prawdopodobieństwa, łatwiej będzie przejrzeć oczekujące na realizację jednostki pracy i spróbować oszacować zgrubnie czas realizacji każdego z nich. A następnie, dysponując już takimi szacunkami, wyliczyć z nich poszczególne percentyle (50, 70, 85 i 95). To będzie stanowić dobrą podpowiedź tego, jakiego czasu cyklu i z jakim prawdopodobieństwem można się spodziewać.

Przy czym tak sporządzone SLE będzie bardzo lichą prognozą, obłożoną sporym błędem. Powinno funkcjonować jedynie do czasu, gdy członkowie systemu Kanban zrealizują wystarczająco wiele jednostek pracy, by stało się możliwe wyliczenie SLE na podstawie faktycznie osiągniętych czasów cyklu. O tym, jak wiele danych do tego potrzeba, przeczytać można w kolejnym komentarzu.

Jak dużo historycznych danych potrzeba, by przeprowadzić jakiekolwiek kalkulacje, na bazie których ustalone zostanie SLE?

Wyliczenie różnych percentyli czasu cyklu wymaga ukończenia szeregu work itemów, których czasy cyklu muszą się choć troszkę różnić, żeby było to możliwe. Natomiast wyliczenie wyłącznie 50 percentyla (mediany) jest możliwe w sposób miarodajny, jeśli dysponujemy czasem cyklu dla zaledwie pięciu work itemów, oczywiście o różnych czasach cyklu. Jakim cudem?

Zgodnie z tzw. regułą pięciu, opisaną przez Douglasa Hubbarda, prawdopodobieństwo tego, że mediana wartości w ramach jakiejś populacji mieści się pomiędzy najmniejszą i największą wartością pięciu losowo wybranych elementów tej populacji, wynosi 93.75%. A to oznacza, że możemy z dużym prawdopodobieństwem wyliczyć medianę dla tej populacji dysponując zaledwie jej pięcioma elementami.

Dlatego 50 percentyl może być dobrą podstawą do pierwszego ustalenia SLE już nie na bazie przewidywań, ale w oparciu o dane. W miarę, jak przybywać będzie kolejnych danych (kończone będą kolejne jednostki pracy), możliwe stanie się wyliczenie innych percentyli i użycie ich wartości do dalszych dostosowań SLE.

Problemy powodowane przez utratę równowagi pomiędzy skutecznością, efektywnością i przewidywalnością opisane zostały w jednym z wcześniejszych komentarzy.

Jej utrzymanie, poza optymalizacją przepływu i zarazem samej wartości, którą przepływ ten generuje, skutkuje też dużą stabilnością samego systemu Kanban. To oznacza, że wszelkie prognozy sporządzane na bazie historycznych danych (np. w oparciu o wartości miar kanbanowych) są obarczone mniejszym błędem, niż w sytuacji, gdy równowagi tej brak.

Ta stabilność w połączeniu z przewidywalnością (która zresztą po części wynika ze stabilności właśnie) pozwala chronić system Kanban przez niekorzystnymi wpływami otoczenia. W jaki sposób?

Członkowie systemu Kanban mogą użyć wiedzy o SLE i innych prognoz sporządzonych w oparciu o miary przepływu (np. za pomocą różnych symulacji Monte Carlo) do dostarczenia informacji o spodziewanym czasie realizacji poszczególnych work itemów wraz z oceną ryzyka nietrafności tych przewidywań. To pozwala zarządzać kolejką itemów oczekujących na realizację w taki sposób, by ze sporym marginesem bezpieczeństwa wciągnąć je do workflowu i ukończyć, zanim minie związany z nimi ewentualny nieprzekraczalny termin (ang. deadline).

Klienci lub interesariusze, na rzecz których pracuje system Kanban, nie będą w tej sytuacji naciskać na natychmiastowe rozpoczęcie prac, bo będą widzieć, że bardziej opłaca się umieścić pilne work itemy na początku listy rzeczy do zrobienia i poczekać, aż obsłużone zostaną w standardowym procesie.

Zupełnie inaczej wygląda sytuacja systemu Kanban o niskiej stabilności i tym samym małej przewidywalności. W obawie, że nie uda się dotrzymać terminów, interesariusze wywierają silną presję na zaczynanie pilnej pracy natychmiast, co dodatkowo destabilizuje cały system.

W oznaczonym fragmencie chodzi zarówno o podstawowe miary przepływu, które opisane zostały w kolejnych komentarzach, jak i o ich wizualizację w postaci różnych wykresów i diagramów.

Członkowie systemu Kanban mogą i często powinni sięgnąć po miary i praktyki (np. związane z wizualizacją, sposobem organizacji pracy itd.), które nie są opisane w Przewodniku po Kanbanie (ang. Kanban Guide). Ponadto często metody, frameworki i procesy, które uzupełniane są Kanbanem, wymagają posłużenia się specyficznymi dla nich artefaktami, które mogą jednocześnie stać się częścią definicji workflowu w ramach systemu Kanban. Przykładem takiego artefaktu może być Backlog Sprintu (ang. Sprint Backlog) w Scrumie.

Kanban nie definiuje żadnych zdarzeń procesowych, bo nie definiuje procesu jako takiego. Bardzo często metoda, której uzupełnienie stanowi Kanban, opisuje już zdarzenia, których można użyć do dbania o adekwatność definicji workflowu i jej udoskonalania. Przykładowo, w Scrumie takim zdarzeniem, które może i nawet powinno posłużyć do tego celu, jest Retrospekcja Sprintu (ang. Sprint Retrospective).

Jeśli brak takich zdarzeń, które mogłyby zostać wykorzystane, członkowie systemu Kanban powinni dokonywać przeglądu i dostosowania definicji workflowu regularnie. Ta regularność nie jest formalnym wymogiem, ale stały rytm utrudni odkładanie niezbędnych działań na później. Ich prokrastynacja może doprowadzić do degradacji przepływu lub całkowitego jego ustania, gdy definicja workflowu nie będzie dopasowana do realiów, w jakich funkcjonuje system Kanban.

Regularność dyskusji nad przepływem i definicją workflowu pozwoli też wykorzystać analizy danych (np. miar kanbanowych), ich wykresów oraz wizualizacji i zauważyć trendy (pozytywne lub negatywne), które są lepiej widoczne, jeśli sprawdzeń dokonuje się w stałych interwałach.

Kadencyjność taka pozwoli zarazem uprościć organizację przeglądów, bo członkowie systemu Kanban nie będą się musieli zastanawiać, kiedy, gdzie i w jaki sposób będą się one odbywać. Mogą też przygotować się do nich (np. zbierając dane), dzięki czemu dyskusja stanie się efektywniejsza.

Zmiany w systemie Kanban mogą być wprowadzane w dowolnym momencie i w dowolnym zakresie, ale warto unikać realizowania dużej ich ilości na raz. Może to spowodować, że uzyskane efekty będą znosić się wzajemnie, przez co ciężko będzie o ocenę, które decyzje były słuszne i przyniosły korzyści, a z których należy się wycofać.

Kanban może być używany jako strategia w połączeniu z metodami iteracyjnymi, w których określone są zdarzenia służące dokonywaniu usprawnień. Przykładem mogą być tutaj Scrum, Extreme Programming (XP) czy nieco mniej popularne metody Crystal.

Przy tej okazji warto na moment zatrzymać się na Scrumie i obalić pewien mit związany ze sposobem, w jaki dokonuje się w nim usprawnień procesu. Dedykowanym do tego zdarzeniem jest odbywająca się na końcu iteracji Retrospekcja Sprintu (ang. Sprint Retrospective). Jej wynikiem są konkretne usprawnienia, które wprowadzone zostają w życie w iteracji kolejnej.

Czy to oznacza, że Zespół Scrum posługujący się Kanbanem nie może dokonywać zmian w definicji workflowu oraz w samym systemie Kanban w trakcie iteracji i musi odkładać to do Retrospekcji Sprintu? Oczywiście nie, bo w Scrumie dowolne usprawnienia mogą być realizowane na bieżąco i Zespół Scrum nie jest w tym zakresie niemal w ogóle ograniczony.

Niemal, bo trzech rzeczy zrobić w trakcie Sprintu (czyli iteracji) nie można, gdyż byłyby one sprzeczne z podstawowymi założeniami metody Scrum (aczkolwiek nie są formalnie zabronione, po prostu nie mają w Scrumie sensu):

• Nie można zmienić Celu Sprintu (ang. Sprint Goal) w trakcie trwania iteracji.
• Nie można trwającej iteracji skrócić lub wydłużyć.
• Zespół Scrum nie powinien też zmieniać w trakcie iteracji obowiązującej Definicji Ukończenia (ang. Definition of Done), ponieważ w jej kontekście planowana była ta iteracja.

Jak widać przestrzeń do dokonywania dowolnych usprawnień (np. w sposobie pracy, organizacji działań, używanych narzędziach itd.) jest ogromna. Dlatego opinia, że Scrum mocno utrudnia użycie Kanbana, który traci wtedy swą elastyczność, jest zupełnie nieuzasadniona.

Niektórzy uważają, że Kanban wymaga ewolucyjnego wprowadzania zmian i nie powinno się w nim przeprowadzać jednorazowych zmian o dużej skali, fundamentalnych lub rewolucyjnych. Istnieje też pogląd, że optymalizacja zawsze powinna rozpoczynać się od stanu bieżącego, który stanowić ma punkt wyjścia.

Ewolucyjne działanie i przyjęcie, że aktualny stan spraw nie jest z definicji zły, jest rozsądną strategią, bo redukuje ryzyko pojawienia się obaw i aktywnego oporu przed zmianami. Ale Kanban wcale takiej strategii nie wymaga.

Warto przy tym zauważyć, że samo zastosowanie Kanbana już jest jakąś zmianą, która wpływa na stan spraw, jakie obejmuje system Kanban. To oznacza, że nie da się użyć Kanbana w taki sposób, by absolutnie niczego nie zmienić.

O konieczności wprowadzenia zmian w sposobie funkcjonowania systemu Kanban, w tym w definicji workflowu, decydują wyłącznie członkowie tego systemu. Dotyczy to zarówno zdefiniowania tej zmiany, sposobu jej realizacji jak i wyboru momentu, kiedy ona nastąpi.

Jeśli Kanban jest używany w połączeniu z metodami lub procesami, które ograniczają tę swobodę wprowadzania zmian, sytuacja mocno się komplikuje. Może konieczne być odłożenie wprowadzenia usprawnień w czasie (np. do określonego w tej metodzie lub procesie momentu). Mogą one też okazać się niemożliwe do zrealizowania bez zmiany używanej metody lub procesu.

Czy taka sytuacja jest korzystna? Niekoniecznie, bo Kanban to strategia optymalizacji wartości. Niemożność jej efektywnego zastosowania w połączeniu z jakimś procesem lub metodą jest silnym sygnałem, że coś z tym procesem albo metodą jest nie w porządku. Niewykluczone też, że brak wiedzy i zrozumienia poszczególnych narzędzi (metody, procesu, samego Kanbana) powoduje, że doszukujemy się ograniczeń tam, gdzie ich w istocie nie ma.

Kanban ma ogromny potencjał ujawniania problemów i obszarów, które wymagają usprawnień, ale pod warunkiem, że komukolwiek na tym zależy. Jeśli okaże się, że stosowana metoda z jakiegoś powodu kłóci się z ideą optymalizacji przepływu, to członkowie systemu Kanban muszą dokonać wyboru, jak postąpić w tej sytuacji.

Istnieje wiele miar, którymi można posłużyć się w Kanbanie. Poza czterema podstawowymi miarami przepływu można wymienić np. efektywność przepływu (ang. flow efficiency), czas realizacji (ang. lead time), koszt opóźnienia (ang. cost of delay), efektywność gospodarowania zasobami (ang. resource efficiency) czy dług przepływu (ang. flow debt).

Każda z tych miar daje wgląd w różne aspekty funkcjonowania systemu Kanban i przepływu w nim. Ustalenie wartości niektórych z miar jest kłopotliwe a czasami wręcz kosztowne, dlatego o ich wykorzystaniu decydować muszą indywidualnie członkowie systemu Kanban.

Uwaga: wiele narzędzi elektronicznych, którymi posługują się organizacje, mami użytkowników obietnicą zbierania i prezentowania różnych miar, w tym kanbanowych. Większość z tych narzędzi generuje błędne wartości miar lub nieprawidłowe ich wizualizacje w postaci wykresów i diagramów. Niekoniecznie dlatego, że błędne są same algorytmy (choć i to niestety się zdarza), ale ze względu na niewłaściwą interpretację danych. Skąd bowiem takie narzędzie ma wiedzieć, gdzie np. tak naprawdę zaczyna się i kończy workflow dla poszczególnych work itemów?

Dlatego użycie takich narzędzi musi wiązać się z upewnieniem, że pobierane są poprawne dane i weryfikacją, że ich prezentacja oraz ewentualne przetworzenie w postaci wizualizacji jest robione prawidłowo.

W języku polskim słowo metric tłumaczone powinno być jako miara, ale często można zetknąć się z terminem metryka. Metryką jest np. akt urodzenia, który zdecydowanie niczego nie mierzy. Dlatego mówmy o miarach kanbanowych, a nie o metrykach.

Istnieją dwa rodzaje miar, którymi można się posłużyć (nie tylko w Kanbanie, nie tylko w odniesieniu do przepływu):

• wskaźniki wyprzedzające (ang. leading indicators),
• wskaźniki opóźnione (ang. lagging indicators).

Pierwsza grupa miar (wskaźniki wyprzedzające) opisuje bieżący stan spraw w ten sposób, że posługując się nimi można kontrolować przebieg procesu. Mówiąc inaczej, wskaźniki te pokazują, dokąd aktualnie zmierza proces (stąd nazwa), ale nie przesądzają o dalszym jego przebiegu. Reagując na wartość wskaźników wyprzedzających możemy zmienić ten przebieg i uzyskać oczekiwane rezultaty.

Przykładem takiego wskaźnika może być liczba problemów, jakie zgłaszają co tydzień użytkownicy jakiegoś produktu – jeśli ona rośnie, wskazuje to na pogorszającą się kondycję produktu, ale zwiększenie inwestycji w zapewnienie jakości może ten trend odwrócić.

Druga grupa miar (wskaźniki opóźnione) opisuje to, co się już stało i pozwala zrozumieć skąd się wziął bieżący stan spraw. Nie można tych wskaźników użyć do zmiany przebiegu procesu (bo on już się zakończył), ale można wykorzystać wiedzę o ich wartości do planowania kolejnych działań. Informację otrzymujemy więc z opóźnieniem (stąd nazwa), co nie znaczy, że jest ona bezwartościowa.

Przykładem takiego wskaźnika jest zysk netto firmy na koniec roku rozliczeniowego. Da się go obliczyć dopiero wtedy, gdy rok się zakończy, ale nie da się już zmienić żadnymi działaniami wartości tej miary (to wymagałoby podróży w czasie).

Dobrą strategią jest posługiwanie się w procesie zarówno wskaźnikami wyprzedzającymi, jak i opóźnionymi, a nie tylko jednym ich rodzajem. Te wyprzedzające pomagają w kontrolowaniu procesu, te opóźnione pozwalają sprawdzić, czy osiągnięte zostały spodziewane rezultaty i w jaki sposób się to odbyło.

Cztery podstawowe miary przepływu, które są obowiązkowe w Kanbanie, zostały dobrane w ten sposób, że dwie z nich to wskaźniki wskazujące (WIP i wiek jednostek pracy), a dwie to wskaźniki opóźnione (czas cyklu i przepustowość).

Wartości czterech podstawowych miar przepływu mają być nie tylko zbierane, ale też w praktyce używane do aktywnego zarządzania pracą w toku i udoskonalania przepływu. Jest to tak podstawowy zestaw miar, że uznanie którejkolwiek z nich za nieistotną jest sygnałem braku zrozumienia, jak działa strategia optymalizacji przepływu w Kanbanie.

Czasami pada argument, że w określonym środowisku, w jakim funkcjonuje jakiś system Kanban, nie da się wartości jednej lub kilku z tych miar ustalić, lub nie da się tego robić na bieżąco. Cóż, w tej sytuacji istnieją znikome szanse na jakąkolwiek optymalizację. W jaki sposób miałaby ona nastąpić, jeśli członkowie systemu Kanban nie mogą policzyć work itemów, nad którymi pracują ani określić faktycznej daty rozpoczęcia tych prac i ewentualnej daty ich zakończenia? A to przecież wszystko, czego potrzeba, by ustalić wartość podstawowych miar przepływu.

Praca w toku (ang. work in progress, w skrócie WIP) to zbiór wszystkich work itemów, dla których workflow już się rozpoczął, ale jeszcze się nie zakończył. Odnosząc się do definicji workflowu, to takie itemy, które minęły już początkowy punkt workflowu, a nie osiągnęły jeszcze punktu końcowego.

WIP jest liczbą jednostek pracy (ang. work items) znajdujących się w przepływie w tym momencie. To oznacza, że zmienia się w sposób dynamiczny. Miara ta stanowi więc wskaźnik wyprzedzający (ang. leading indicator) kondycji przepływu. Dzięki sprawdzaniu tego wskaźnika, możliwe jest kontrolowanie WIP‑u tak, by nie rozrósł się nadmiernie.

Jednocześnie średnia wartość WIP‑u jest wskaźnikiem wyprzedzającym dla średniego czasu cyklu (ang. cycle time) w myśl prawa Little’a, które omówione zostało we wcześniejszych komentarzach: im WIP jest większy, tym większe prawdopodobieństwo, że czasy cyklu będą się wydłużać.

WIP jest miarą, która zawsze dotyczy zbioru jednostek pracy (choć okazjonalnie może to być zbiór jednoelementowy). Wartości tej miary nie da się rozpatrywać lub zbierać indywidualnie dla pojedynczych work itemów.

Przepustowość (ang. throughput) wyliczana jest jako liczba jednostek pracy, które osiągnęły punkt końcowy przepływu w wybranej jednostce czasu, np. danego dnia, w tygodniu, w czasie jednej iteracji itd. Czasami przyjmuje się, że przepustowość odzwierciedla możliwości wytwórcze systemu Kanban w jego aktualnej kondycji, przy czym pamiętać należy, że ta przepustowość zależy od wielu czynników i jest zmienna w czasie.

Przepustowość jest wskaźnikiem opóźnionym (ang. lagging indicator) przepływu, ponieważ można użyć informacji o niej do prognozowania terminów realizacji zbioru jednostek pracy.

Średnia przepustowość jest jednym z trzech parametrów przepływu ujętych w prawie Little’a, które omówione zostało we wcześniejszych komentarzach. Występuje w nim zarówno średni czas cyklu (ang. cycle time) jak i średnia przepustowość:

CT ＝ WIPTH

Aby zachować spójność jednostek, średnia przepustowość (TH) musi zostać wyliczona dla długości okresu odpowiadającego jednostce czasu, w której wyrażany jest średni czas cyklu (CT). A po ludzku: jeśli średni czas cyklu wyrażony jest w dniach, to wyliczyć trzeba średnią przepustowość na dzień.

Czasami pojawia się wątpliwość, czym różni się przepustowość średnia z danego okresu od po prostu przepustowości. Wyobraźmy sobie zatem, że rozważamy okres stu dni, z których tylko w co dziesiątym dniu udaje się ukończyć jeden work item.

Jaka będzie przepustowość w tym okresie studniowym? Wyniesie ona dokładnie dziesięć.

Jaka będzie przepustowość w każdym dniu z tego studniowego okresu? Dla dziewięćdziesięciu z tych stu dni przepustowość na dzień wynosi zero, a dla dziesięciu ta przepustowość na dzień wynosi jeden.

A jaka będzie przepustowość średnia w okresie tych stu dni? To średnia z przepustowości dziennej wyliczonej osobno dla każdego dnia, czyli średnio zaledwie jedna dziesiąta work itemu dziennie.

Przepustowość, podobnie jak WIP, jest miarą dotyczącą zawsze zbioru jednostek pracy ukończonych w rozważanym okresie, dlatego wartości tej miary nie da się rozpatrywać lub zbierać indywidualnie dla pojedynczych work itemów.

W poprzednim komentarzu do definicji przepustowości wyjaśniona została różnica pomiędzy przepustowością a średnią wartością przepustowości. O ile wartość średnia może być ułamkiem, o tyle przepustowość zawsze jest liczbą całkowitą, której wartość ustala się poprzez zliczenie jednostek pracy ukończonych w rozważanym okresie.

Przepustowość zawsze musi przy tym być podawana ze wskazaniem, jakiego okresu dotyczy, bo sama liczbowa wartość traci bez tego znaczenie. Przykładowo, jeśli każdego dnia członkowie systemu Kanban są w stanie zakończyć pracę nad jednym work itemem, to przepustowość dzienna wynosi jeden, ale roczna wynosi 365. Natomiast informacja, że przepustowość wynosi 17 jest bezużyteczna.

Wiek jednostki pracy (ang. work item age, w skrócie WIA) informuje o tym, jak długo jednostka pracy stanowi część WIP‑u. Czas ten zaczyna się liczyć w momencie rozpoczęcia pracy nad tą jednostką (czyli gdy przekroczy ona punkt początkowy workflowu).

Wybór jednostki czasu pozostaje w gestii członków systemu Kanban, ale zwykle są to dni. Przy czym wiek wszystkich jednostek pracy w WIP‑ie powinien być wyrażony w takich samych jednostkach, ponieważ podawanie go dla niektórych itemów w minutach, dla innych w godzinach, a jeszcze dla kolejnych w dniach, powodować będzie zamieszanie i utrudni zarządzanie pracą w toku.

Wiek jednostki pracy jest wskaźnikiem wyprzedzającym (ang. leading indicator) czasu cyklu (ang. cycle time) dla tego work itemu, ponieważ w momencie zakończenia pracy nad tym itemem, końcowy wiek staje się właśnie czasem cyklu.

Dodatkowo wiek jednostki pracy w zderzeniu z SLE (oczekiwany poziom obsługi, opisany we wcześniejszych rozdziałach i komentarzach tam zawartych) może być użyty jako wskaźnik wyprzedzający problemów z zapewnieniem efektywnego przepływu konkretnego work itemu. Jeśli taka jednostka pracy zaczyna mieć WIA zbliżony do czasu cyklu zawartego w SLE i wciąż stanowi część WIP‑u, sygnalizuje to poważny problem z przepływem lub jego brak.

Wiek jednostki pracy jest miarą związaną indywidualnie z work itemami – wyłącznie z tymi, które znajdują się obecnie w WIP‑ie (czyli tymi, które minęły już punkt rozpoczęcia workflowu, ale nie osiągnęły jeszcze punktu jego zakończenia). Wiek jednostki czasu zmienia się wraz z upływem czasu, dlatego tej miary nie da się wyliczyć raz i w ten sposób uzyskać jej niezmiennej już wartości.

Dla zbioru wielu jednostek pracy (np. dla całego WIP‑u) można wyliczyć oczywiście średnią wartość tej miary i użyć jej jako wskaźnika wyprzedzającego do oceny, czy aktywne zarządzanie pracą w toku jest efektywne.

Formuła wyliczenia wieku jednostki pracy jest następująca:

WIA ＝ teraz − start + 1

W tym równaniu WIA to oczywiście wiek jednostki czasu, teraz to moment aktualny, a start to moment rozpoczęcia pracy nad work itemem. Zarówno teraz jak i start powinny być podawane z tą samą dokładnością – taką, która pozwoli wyliczyć wiek jednostki pracy w przyjętej jednostce czasu. Przykładowo, jeśli WIA wyrażany jest w dniach, moment aktualny (teraz) to data dzisiejsza, a moment rozpoczęcia (start) to dzień, w którym rozpoczęła się realizacja tej konkretnej jednostki pracy.

Dlaczego dodać trzeba do wyliczonej różnicy czasów jeden? Wynika to z faktu, że wiek jednostki pracy staje się w momencie jej ukończenia czasem cyklu dla tego work itemu. Jeśli więc czas ten podawany byłby np. dniach, każda jednostka pracy, której realizacja rozpoczęła się i zakończyła tego samego dnia, miałaby zerowy czas cyklu albo musiałaby być wyrażona ułamkiem, a to nie jest poprawne (dlaczego, wyjaśnione zostało w kolejnym komentarzu odnoszącym się do definicji tej miary).

Oczywiście można by w takiej sytuacji zacząć stosować godziny zamiast dni jako jednostki czasu, ale problem wciąż wystąpi, jeśli item uda się ukończyć w tej samej godzinie, w której prace nad nim się rozpoczęły. To może użyć minut? Szansa, że cokolwiek uda się rozpocząć i ukończyć w tak krótkim czasie faktycznie nie jest duża, ale pojawi się inny problem. Któż byłby w stanie bez kalkulatora powiedzieć, że 18550 minut to nieco ponad 13 dni?

Dlatego też wiek jednostki pracy w momencie, gdy się ona rozpoczyna, wynosi natychmiast jeden (dzień, godzinę, tydzień – zależnie od stosowanych jednostek czasu). Dzięki temu można posługiwać się jedną spójną jednostką czasu dla wszystkich work itemów i to taką, która dobrana jest w sposób niestwarzający trudności interpretacyjnych.

Uwaga: wzór pozwalający wyliczyć wiek jednostki pracy wymaga obliczenia upływu czasu niezależnie od tego, czy w międzyczasie zdarzyły się święta, weekendy lub inne przerwy od pracy. Inaczej mówiąc, jednostki pracy starzeją się w WIP‑ie niezależnie od tego, czy ktoś nad nimi pracuje, czy nie.

Takie podejście pozwala posługiwać się wartością wieku jednostki pracy bez konieczności pamiętania, ile i jakich okresów należy pominąć. Gdyby spróbować je odliczać, trzeba by nie tylko śledzić kalendarz (święta, weekendy itd.) ale również pomijać np. urlopy osób, które nad danym work itemem pracowały. Realnie nie da się tego zrobić tak, by miara wciąż była jakkolwiek użyteczna. Zamiast tego prosta formuła przedstawiona powyżej pozwala uzyskać czytelną wartość WIA.

Czas cyklu (ang. cycle time) informuje o tym, jak dużo czasu potrzeba było, aby konkretna jednostka pracy przepłynęła od punktu rozpoczęcia workflowu do punktu jego zakończenia. To oznacza, że czas cyklu stanowi ostateczną wartość wieku jednostki pracy (ang. work item age, w skrócie WIA), czyli miary opisanej w poprzednim komentarzu.

Jednostka czasu, w której wyrażany jest czas cyklu, może być dowolnie wybrana przez członków systemu Kanban. Zwykle jednak są to dni, rzadziej godziny lub np. tygodnie. Oczywiście czas cyklu wszystkich work itemów powinien być podawany w tej samej jednostce czasu, aby uniknąć zamieszania.

Czas cyklu jest wskaźnikiem opóźnionym (ang. lagging indicator) przepływu dla konkretnej jednostki pracy. Można też obliczyć średnią wartość czasu cyklu, jego medianę albo różne percentyle dla zbioru wielu jednostek pracy i posłużyć się tymi wartościami jako wskaźnikami opóźnionymi przepływu rozpatrywanego globalnie w całym systemie Kanban.

Prognozowana wartość czasu cyklu stanowi również podstawę oczekiwanego poziom obsługi (ang. service level expectation, w skrócie SLE), co zostało opisane w komentarzach zawartych we wcześniejszych rozdziałach.

Czas cyklu jest miarą związaną indywidualnie z pojedynczym work itemem – wyłącznie takim, który minął już punkt zakończenia workflowu (nie da się tej miary wyliczyć zanim praca nad itemem się nie zakończy). Raz uzyskana wartość czasu cyklu dla konkretnego work itemu nie może już ulec zmianie.

Tu należy wspomnieć, że istnieją procesy, w których jednostki pracy mogą z różnych powodów być przetwarzane więcej niż jeden raz, czyli są wciągane do przepływu ponownie już po tym, jak zostały przeprocesowane. Jak wyliczać czas cyklu dla nich?

Nazwa miary, czyli czas cyklu, stanowi podpowiedź. Jest to czas jednorazowego przejścia przez proces – czyli jednego cyklu. Jeśli tych cykli jest więcej, każdy z nich traktowany jest osobno. To oznacza, że czas cyklu również wyliczany jest osobno dla każdego z takich zakończonych przepływów.

Jeśli narzędzie, jakim posługują się członkowie systemu Kanban do zarządzania workflowem nie pozwala na takie rozróżnianie cyklów, można po prostu sklonować zamknięty już work item na potrzeby każdego kolejnego przepływu.

Formuła wyliczenia czasu cyklu wygląda następująco:

czas cyklu ＝ koniec − start + 1

W tym równaniu koniec to moment zakończenia prac nad work itemem, a start to moment rozpoczęcia pracy nad nim. Tak koniec jak i start powinny być podawane z tą samą dokładnością, dobraną w ten sposób, by dało się wyliczyć czas cyklu w przyjętej jednostce czasu. Przykładowo, jeśli ten czas wyrażany jest w dniach, moment zakończenia (koniec) to dzień, w którym realizacja work itemu została zakończona, a moment rozpoczęcia (start) to dzień, w którym item ten wciągnięty został do WIP‑u.

Czas cyklu nie może nigdy być zerowy, bo wykreowanie wartości wymaga wykonania pracy, a tego nie da się zrobić w zerowym czasie. To oznacza, że w zależności od przyjętej jednostki czasu, zawsze określamy w trakcie ilu takich jednostek czasu praca była wykonywana. Najlepiej wyjaśnić to na przykładzie.

Przyjmijmy, że praca nad jakimś work itemem zajęła dokładnie 195 minut. Gdybyśmy czas cyklu wyrażali w minutach, nie będzie problemu – wynosi on 195 minut. Trochę trudniej będzie wyrazić ten czas w godzinach, bo 195 minut nie dzieli się równo przez 60. Kuszące wydaje się stwierdzenie, że to 3.25 godziny, bo dzięki temu zachowana jest pełna precyzja w określaniu wartości miary. Niestety, takie podejście bardzo szybko okaże się co najmniej kłopotliwe.

Co się stanie, gdy spróbujemy podać czas cyklu dla przykładowego itemu nie w godzinach, ale dniach, trzymając się zasady, że musi być określony z pełną precyzją? Cóż, uzyskamy wtedy ułamek okresowy liczby dni: 0.13541(6) – ten zapis oznacza, że jest tam na końcu nieskończona liczba szóstek. Naturalnym ruchem będzie zaokrąglenie tej wartości np. do 0.14 dnia i tym samym wrzucimy do kosza na śmieci precyzję, która miała uzasadniać ten sposób prezentowania czasu cyklu.

Oczywiście możemy pozostać przy minutach i w nich wyrażać czas cyklu. Pytanie tylko, ile work itemów da się realnie zrealizować w czasie minut lub maksymalnie kilku godzin? Częściej jednak będzie na to potrzeba kilka dni. Nieustannie więc pojawiać się będą naprawdę spore wartości tej miary. Konia z rzędem temu, kto w głowie policzy, ile dni trwała praca nad work itemem, którego czas cyklu wyniósł 46993 minut.

Potencjalnym rozwiązaniem mogłoby być posługiwanie się różnymi jednostkami czasu dla różnych czasów cyklu, w zależności od jego wartości. Tylko że to utrudni sporządzanie wykresów, kalkulowanie wartości średnich itd., a także może prowadzić do błędów decyzyjnych, jeśli wartości miary będą gdzieś podawane bez określenia jednostki czasu.

Wróćmy do przykładu: 195 minut to nieco ponad trzy godziny. A zatem można powiedzieć, że czas cyklu wyrażony w pełnych godzinach wynosi cztery. Nie trzy, bo po trzech godzinach prace nad work itemem wciąż jeszcze trwały. Tak, nie jest to superprecyzyjne, ale ten poziom precyzji naprawdę wystarczy.

A ile wynosić powinien czas cyklu dla przykładowego itemu wyrażony w pełnych dniach? Jeden dzień, bo potrzebna była część tego jednego dnia, by wykonać niezbędne prace. I choć nieco ponad trzy godziny to zdecydowanie mniej niż cały dzień, nie można dokonać zaokrąglenia wartości czasu cyklu w dół, bo wyrażony w dniach musiałby wtedy wynosić zero.

Dlatego też formuła wyliczenia czasu cyklu podana powyżej wymaga dodania wartości jeden. Jest prosta i nie wymaga przeliczenia jednostek czasu, a pozwala zachować wystarczającą precyzję, o ile członkowie systemu Kanban nie zdecydują się na posłużenie zbyt dużą jednostką czasu (np. tygodniami lub miesiącami).

Uwaga: kalkulacja czasu cyklu odbywa się bez pomijania okresów takich jak święta, dni wolne itd. Choć praca nie posuwa się wtedy do przodu (przepływu brak), to jednak czas nieustannie biegnie do przodu i miara musi ten fakt uwzględnić. Takie pomijanie byłoby zresztą technicznie bardzo trudne, bo konieczne byłoby posługiwanie się nie tylko kalendarzem z zaznaczeniem, które dni były robocze, ale również informacją, kto, kiedy nad czym pracował i w jakie dni miał np. urlop.

Dlatego zawsze wyliczamy czas cyklu posługując się datami rozpoczęcia i zakończenia workflowu, nie odliczając nic od wartości otrzymanej wedle formuły zaprezentowanej powyżej.

Punkty rozpoczęcia i zakończenia workflowu determinują, co stanowi część WIP‑u, co oczekuje na wciągnięcie do workflowu, a co już ten workflow opuściło.

W zależności od definicji workflowu i jednostek pracy, jakie mogą się w nim znaleźć, punkty rozpoczynania i kończenia workflowu dla poszczególnych itemów mogą być różne i należy to uwzględnić przy obliczaniu poszczególnych miar. Jest to szczególnie istotne w przypadku zastosowania narzędzi elektronicznych, które zwykle niepoprawnie odgadują, gdzie zaczyna się a gdzie kończy workflow dla różnych jednostek pracy.

Zbieranie podstawowych miar przepływu wydawać się może skomplikowane, ale w istocie jest bardzo proste. W praktyce wystarczy zapisywać w poszczególnych work itemach informację o tym, kiedy zostały wciągnięte do workflowu, a jeśli już go opuściły, kiedy się to stało. Dysponując tylko tymi datami dla każdej jednostki pracy, da się wykalkulować wszystkie cztery obowiązkowe miary przepływu oraz sporządzić ich użyteczne wizualizacje w postaci wykresów i diagramów.

Przyjmując, że jednostką czasu, jaką posługują się członkowie systemu Kanban przy wyliczaniu miar przepływu są dni, wtedy:

• WIP to liczba wszystkich jednostek pracy, które mają w chwili obecnej określoną datę wciągnięcia do workflowu, ale nie mają jeszcze daty jego zakończenia.
• Przepustowość w danym okresie to liczba wszystkich jednostek pracy, które mają określoną datę zakończenia workflowu i data ta należy do okresu, dla którego przepustowość jest liczona.
• Wiek jednostki pracy znajdującej się aktualnie w przepływie to różnica między datą bieżącą i datą wciągnięcia tej jednostki do workflowu, powiększona o wartość jeden.
• Czas cyklu jednostki pracy to różnica między datą zakończenia przepływu dla tej jednostki i datą jej wciągnięcia do workflowu, powiększona o wartość jeden.

Jednym z powodów, dla których te cztery miary nazywane są podstawowymi i są wymagane w Kanbanie jest właśnie prostota ustalania ich wartości. Ciężko przy tym wyobrazić sobie system Kanban, w którym da się aktywnie zarządzać pracą w toku, a w którym nie dałoby się zbierać wartości jednej lub kilku z tych miar.

Przykładem takiej różnie nazywanej miary przepływu jest czas cyklu (ang. cycle time), czyli czas od momentu rozpoczęcia pracy nad jakimś work itemem (wciągnięcia go do workflowu) do momentu zakończenia tej pracy i uzyskania wartości.

W różnych opracowaniach, literaturze i propozycjach implementacji Kanbana można zetknąć się z określeniem czasu cyklu jako czasu przepływu (ang. flow time), czasu w procesie (ang. time in process), czasu procesowego (ang. process time) czy też systemowego czasu realizacji (ang. system lead time).

To samo dotyczy innych miar. Przy czym zwykle nie jest dobrym pomysłem wymyślanie na siłę nazw kolejnych albo posługiwanie się terminami, które nie są dobrze rozpoznawalne w organizacji, gdzie funkcjonuje system Kanban. Dlatego należy to zrobić tylko wtedy, gdy faktycznie służy czemuś i przynosi jakąś korzyść.

Jedną z często powtarzających się wątpliwości jest ta związana z czasem realizacji (ang. lead time): czy jest to to samo, co czas cyklu? By odpowiedzieć, konieczne jest zdefiniowanie, czym jest wspomniany czas realizacji.

Lead time jest czasem od rozpoczęcia do zakończenia jakiegoś procesu. Jeśli absolutnie wszystkie stany tego procesu objęte będą workflowem w konkretnym systemie Kanban, to z punktu widzenia tego systemu lead time i czas cyklu będą tożsamymi miarami. Natomiast jeśli workflow obejmuje tylko część ze stanów całego procesu – wtedy czas cyklu będzie zupełnie czym innym niż czas realizacji.

Najlepiej wyjaśnić to na prostym przykładzie procesu, w którym rozwijany jest jakiś produkt na potrzeby szerokiej grupy użytkowników. Cały taki proces obejmował będzie stany związane ze zbieraniem informacji o potrzebach, wymyślaniem rozwiązań, ich wytwarzaniem a następnie przekazaniem do użycia nowej wersji produktu.

Jeśli system Kanban obejmował będzie tylko stany związane z wytwarzaniem rozwiązań, wtedy czas cyklu i lead time będzie różnie zdefiniowany i będzie się znacząco różnić. Czas cyklu obejmie jedynie czas zbudowania rozwiązań, natomiast czas realizacji obejmował będzie również wymyślenie tych rozwiązań oraz dostarczenie użytkownikom nowych wersji produktu.

Natomiast z punktu widzenia użytkowników lead time będzie jeszcze inaczej postrzegany: dla nich to czas od zgłoszenia potrzeby do momentu otrzymania produktu, który na te potrzeby odpowiada. Inaczej mówiąc to, co członkowie systemu Kanban postrzegają jako lead time, z pespektywy użytkownika jest zaledwie czasem cyklu (cyklu przetwarzania potrzeby, jaką zgłosili).

Uwaga: są osoby, które lead time definiują zupełnie inaczej – jako czas, który upływa od momentu zgłoszenia potrzeby do chwili rozpoczęcia prac nad jej zaspokojeniem. Można powiedzieć, że jest to czas poprzedzający realizację, czego anglojęzycznym odpowiednikiem byłby leading time. Najprawdopodobniej stąd bierze się nieporozumienie.

Przekładając to zdanie na prosty język: zbieranie wartości miar dla samego ich zbierania tylko dlatego, że jest to wymagane, nie ma żadnego sensu. Staną się po prostu cyferkami, z których nic nie wynika i równie dobrze można by je generować losowo.

Miary nabierają sensu, gdy posłużymy się nimi do aktywnego zarządzania pracą w toku (czyli dbania o przepływ) i udoskonalania definicji workflowu oraz optymalizacji przepływu. Z tego powodu wśród czterech podstawowych miar wymaganych w Kanbanie są dwa wskaźniki wyprzedzające (ang. leading indicators), pozwalające kontrolować WIP i jego przepływ, oraz dwa wskaźniki opóźnione (ang. lagging indicators) pozwalające lepiej zrozumieć, jak ten przepływ wyglądał i wprowadzić udoskonalenia.

Oczywiście możliwe jest połączenie informacji dostarczonych przez różne miary, a także posłużenie się ich wizualizacjami (w tym takimi pokazującymi np. trendy zmian), dzięki czemu każda z tych miar może potencjalnie stanowić podstawę do skonstruowania kolejnych wskaźników, czy to wyprzedzających, czy opóźnionych.

Przykładem wizualizacji może być wykres rozrzutu czasu cyklu (ang. cycle time scatterplot chart), obrazujący moment zakończenia prac nad poszczególnymi work itemami i ich czas cyklu. Da się na jego podstawie odczytywać zarówno czas cyklu, jak i uzyskać informacje o jego wartości średniej lub różnych percentylach, a sumując liczbę work itemów ukończonych w jakimś okresie, również przepustowość w tym przedziale dat.

Innym użytecznym narzędziem będzie wykres starzenia się jednostek pracy (ang. work item aging chart), na którym zwizualizowany jest WIP (wszystkie jednostki pracy, jakie go tworzą) z informacją o ich aktualnych stanach workflowu oraz wieku jednostki pracy. Poza tym wiekiem da się ustalić wielkość WIP‑u poprzez policzenie znajdujących się na wykresie jednostek pracy.

Nieco mniej popularny jest wykres przebiegu przepustowości (ang. throughput run chart), który obrazuje, ile jednostek pracy udało się ukończyć każdego dnia. Pozwala to odczytywać przepustowość w poszczególnych dniach lub za dłuższe okresy, gdy zsumowana zostanie liczba ukończonych jednostek pracy z wielu dni.

Najbardziej znany jest skumulowany diagram przepływu (ang. cumulative flow diagram, w skrócie CFD). Przy czym w większości narzędzi jest on tworzony niepoprawnie, a mnóstwo użytkowników nie potrafi go prawidłowo odczytać. Dzieje się tak dlatego, że najczęściej nie wiedzą, co diagram ten tak naprawdę przedstawia. A są to nałożone na siebie wykresy przyrostu liczby jednostek pracy wciąganych do workflowu i opuszczających go po zakończeniu prac. Można też umieścić na diagramie informację o rosnącej liczbie work itemów, które wciągnięte już zostały do kolejnych stanów workflowu, co widoczne jest jako ułożone obok siebie warstwy na diagramie.

Jest to diagram, a nie jeden wykres, bo zawiera na jednym obrazku wiele różnych wykresów nałożonych na siebie. Kumulatywność zawarta w nazwie odnosi się właśnie do faktu obrazowania, jak rośnie liczba jednostek pracy, które już osiągnęły jakiś stan.

Sygnałem, że diagram nie jest sporządzany prawidłowo jest zwykle brak kumulatywności – wtedy jeden z wykresów opada w dół. A przecież nie może tak się stać, bo jeśli jakiś work item wciągnięty już został do stanu X i zaczął w nim być procesowany, to nie da się cofnąć tego faktu bez dysponowania maszyną czasu.

Z diagramu da się odczytać WIP każdego dnia, średnią przepustowość oraz przybliżony średni czas cyklu w wybranym momencie.

O tym jak posługiwać się opisanymi w tym komentarzu wizualizacjami i jak je sporządzać można przeczytać w szczegółach w książce Daniela Vacantiego Actionable Agile Metrics for Predictability.

O tym, jak posługiwać się miarami przepływu i ich typowymi wizualizacjami można przeczytać w szczegółach w książce Daniela Vacantiego Actionable Agile Metrics for Predictability.

Natomiast użytkownicy Scruma i podobnych do niego metod zwinnych na pewno powinni sięgnąć po ebook Daniela Vacantiego i Willa Seele Flow Metrics for Scrum Teams.

Użycie innych miar, niekoniecznie związanych z przepływem, powinno być przemyślane, by uniknąć dwóch typowych problemów: skupienia się na nich kosztem monitorowania podstawowych miar przepływu oraz nadmiernej ilości miar obniżającej możliwość skutecznego zarządzania systemem Kanban.

Istotne jest też dbanie o to, by miary, jakimi posługują się członkowie systemu Kanban, nie były im narzucone. A już katastrofalnym błędem może być sytuacja, w której ktoś spoza systemu Kanban wylicza miary w sposób nieprzejrzysty i oczekuje dostosowania w oparciu o nie sposobu funkcjonowania systemu Kanban.

Jeśli chodzi o użycie miar, to uzyskanie konkretnej ich wartości nigdy nie powinno stanowić celu, jaki stawiają sobie członkowie systemu Kanban. Inaczej mówiąc, nie powinni dokonywać zmian procesu, narzędzi, sposobu komunikacji itd. po to tylko, by uzyskać jakąś wartość liczbową jednej z miar, którą się posługują – bo Kanban służy optymalizacji przepływu, a nie miar. To oznacza, że nawet jeśli system Kanban dąży do uzyskania jakiejś wartości miary, zawsze powinno to wynikać z potrzeby optymalizacji przepływu.

Czy to nie jedno i to samo? Cóż, nie. Jeśli celem będzie po prostu konkretna wartość miary, można ją osiągnąć często kosztem zaburzenia przepływu, obniżenia przewidywalności, efektywności działania itd. A przecież to nie ma sensu, bo nie przyniesie wartości, tylko utrudni jej uzyskiwanie. Sama miara (jej wartość taka czy inna) jest bezużyteczna.

Natomiast jeśli dążenie do konkretnej wartości miary wynikać będzie ze starań o optymalizację przepływu, to członkowie systemu Kanban będą nieustannie monitorować, czy rzeczywiście uzyskują pożądany efekt i będą gotowi do zmiany działań, przedefiniowania tej oczekiwanej wartości miary lub jakiegokolwiek innego postępowania, które uznają za niezbędne.

Niezmienność, o której mowa w zaznaczonym zdaniu, nie oznacza oczywiście, że Kanban jest zdefiniowany raz na zawsze i nigdy nikt nie dokona w nim żadnych zmian. Jak każde narzędzie, tak i Kanban może zostać i z pewnością zostanie w przyszłości udoskonalony.

To zdanie ma przypominać, że Kanban zdefiniowany jest w taki sposób, jak opisuje to Przewodnik po Kanbanie (ang. Kanban Guide). Nie można pozmieniać poszczególnych jego elementów i twierdzić, że to wciąż Kanban. Powstała w ten sposób strategia lub konkretna metoda może okazać się bardzo skuteczna, ale będzie jedynie inspirowana Kanbanem. Nie powinna natomiast być nazywana Kanbanem choćby dlatego, by nie szerzyć jego błędnego zrozumienia (które niestety już jest spore).

Kanban jest strategią na tyle minimalistyczną, że nie istnieje możliwość usunięcia z niego czegokolwiek bez ryzyka, że niemożliwe stanie się jego skuteczne wykorzystanie do optymalizacji przepływu.

Nie ma w Kanbanie żadnych ról, zdarzeń, artefaktów – są jedynie trzy praktyki, skojarzone z nimi cztery podstawowe miary przepływu i absolutnie minimalistyczny zestaw wymogów odnośnie do definicji workflowu, żeby umożliwić zadziałanie tych praktyk. Wszystko ponad to może być kształtowane dowolnie przez członków systemu Kanban.

Jeśli jakaś organizacja lub zespół użyje jedynie wybranych elementów Kanbana, np. stworzy tablicę kanbanową, która nie będzie spełniać wymogów definicji workflowu, to choć niewykluczone, że pozwoli to na skuteczną optymalizację przepływu, nie będzie to Kanban i nie powinno się tej autorskiej strategii lub metody tak nazywać.

Wbrew wielu obiegowym opiniom Kanban może być bez trudu łączony z każdym powszechnie używanym przez różnie organizacje procesem, metodą lub frameworkiem, nie tylko zwinnym, ale również projektowym.

Kanban jest agnostyczny w stosunku do procesów, na które jest nakładany jako strategia – da się go użyć w całości i poprawnie zawsze, gdy procesy te dążą do uzyskiwania wartości i gdy uzyskanie przepływu jest uznawane jako zjawisko pożądane.

W praktyce Kanbana nie dałoby się użyć jedynie w takim procesie, w którym uzyskanie wartości nie byłoby oczekiwane i który dążyłby do zatrzymania realizacji wszelkich działań w stanie, w jakim aktualnie się znajdują. Nie wydaje się jednak bardzo prawdopodobne istnienie procesów o takiej charakterystyce.

Kanban ma korzenie w Japonii (niekoniecznie tylko w systemie produkcyjnym Toyoty) i jest mocno inspirowany Leanem. Natomiast jego twórcy sięgali po różne inne idee, w tym również Teorię Ograniczeń (ang. Theory of Constraints), która jest swoistym anglosaskim odpowiednikiem Leana. O ile niektórzy zaliczają Kanbana do zbioru metod Agile, poprawniejszym byłoby spozycjonowanie go gdzieś pomiędzy Agile a Leanem – jako ich połączenie, przenikanie się. Trzeba też pamiętać, że nie jest to metoda, ale strategia.

Kanban spopularyzowany został przez Davida J. Andersona jako Metoda Kanban (ang. Kanban Method). Jak można wywnioskować z samej nazwy, jest to więcej niż tylko strategia opisana w Przewodniku po Kanbanie (ang. Kanban Guide). W praktyce Kanban opisany w nim i Kanban będący podstawą Metody Kanban jest taki sam, ale Metoda Kanban definiuje szereg elementów, które należy lub można wykorzystać do stworzenia działającego systemu:

• dziewięć wartości,
• trzy tzw. agendy (obszary, w jakich powinien działać Kanban),
• sześć zasad stosowania Metody (w podziale na dwie grupy),
• sześć praktyk,
• osiem kroków do wdrożenia Metody (a tak naprawdę dziewięć, bo jest też krok zerowy),
• dwie opcjonalne role,
• siedem opcjonalnych kadencji (interwałów, w których powtarzane są różne działania).

Co ciekawe, Metoda Kanban wydaje się nie wymagać wprost użycia jakichkolwiek konkretnych miar, co jest w zasadzie jedyną istotną rozbieżnością między Kanbanem w niej zdefiniowanym, a Kanbanem opisanym w Przewodniku po Kanbanie.

Można powiedzieć, że Metoda Kanban jest propozycją implementacji Kanbana, trochę jak Scrum jest propozycją implementacji podejścia Agile. Przy czym wielu propagatorów tej metody bardzo oburza to stwierdzenie, choć dyskusja o powodach bywa trudna.

Trzeba mieć świadomość, że do pewnego stopnia podejście do Kanbana jako strategii oraz Metoda Kanban konkurują ze sobą. Każda organizacja i zespół muszą samodzielnie zdecydować, jakie podejście do Kanbana będzie najlepsze. Propozycji, jak go używać, jest zresztą na rynku idei więcej.

Kanban użyty jako strategia, a nie konkretna metoda, daje największą swobodę łączenia go z różnymi procesami i stosowanymi metodami. Nie definiuje żadnych ograniczeń i wymogów poza absolutnym minimum, bez którego optymalizacja przepływu nie byłaby w ogóle możliwa. Nie definiuje nawet zaleceń i podpowiedzi, jak stosować poszczególne elementy strategii, by nie narzucać tego organizacjom i zespołom. Tego typu podpowiedzi znajdują się oczywiście w komentarzach do poszczególnych fragmentów Przewodnika po Kanbanie, ale nie stanowią one formalnej definicji Kanbana.

Liczba organizacji i zespołów, które stosują Kanban jest bardzo wysoka i rośnie. Przykładowo, State of Agile Report opublikowany w 2022 zawiera informację, że 56% organizacji deklaruje posługiwanie się Kanbanem, co stanowi gwałtowny wzrost w porównaniu do 7% w analogicznym raporcie z 2020. Czy jest to faktycznie Kanban, czy też autorska (i niekoniecznie skuteczna) metoda inspirowana Kanbanem, trudno ocenić.

Z Kanbanem wiąże się też wiele mitów i nieporozumień, czemu sprzyja nienajlepsza wiedza o tym, czym Kanban w istocie jest. Często przekłada się to na przekonanie, że jakiś proces może być nazwany Kanbanem, choć jest skrajnie odległy od zgodności z jego definicją.

Komentarze zawarte na tej stronie mają na celu właśnie obalenie tych mitów i spowodowanie, że Kanban będzie lepiej rozumiany przez osoby posługujące się nim.

Do powstania Przewodnika po Kanbanie (ang. Kanban Guide) przyczyniło się sporo osób, a znamienne jest, jak wiele z nich powiązanych jest z organizacją Scrum.org, której misją jest promowanie profesjonalnie używanego Scruma.

Uważny czytelnik Przewodnika zauważy zresztą wiele analogii w sposobie, jak Kanban zdefiniowany jest w tym dokumencie, a jak opisany jest Scrum w Przewodniku po Scrumie (ang. Scrum Guide). To podobieństwo nie jest przypadkowe, bo twórcom obu dokumentów przyświecała idea stworzenia maksymalnie elastycznych i lekkich ram (strategii w przypadku Kanbana lub procesu w Scrumie), które każda organizacja lub zespół może uzupełnić swoim kontekstem i specyfiką.

Istnieje też Przewodnik po Kanbanie dla Zespołów Scrum (ang. Kanban Guide for Scrum Teams). Rzecz jasna stworzenie systemu Kanban zgodnie z tym, jak opisany on został w Przewodniku po Kanbanie, nie wymaga rezygnacji z poprawnego użycia Scruma, a wręcz podniesie skuteczność stosującego go Zespołu. Aby jednak dodatkowo zachęcić użytkowników Scruma do korzystania z Kanbana, ale też by ułatwić im wprowadzenie praktyk kanbanowych, organizacja Scrum.org opracowała wspomniany Przewodnik po Kanbanie dla Zespołów Scrum, który opisuje Kanban w sposób dostosowany do potrzeb Zespołów Scrum.

Uwzględnione w tym dokumencie zostały oczywiście zdarzenia metody Scrum, a precyzyjniej mówiąc to, w jaki sposób wplatają się one w strategię zarządzania przepływem i które elementy Kanbana mogą pozwolić na większą efektywność realizacji tych zdarzeń. Natomiast to nie są jedyne różnice pomiędzy tymi dwiema definicjami Kanbana.

Kanban Guide for Scrum Teams wymienia cztery wymagane praktyki:

• Visualization of the Workflow
• Limiting Work in Progress (WIP)
• Active management of work items in progress
• Inspecting and adapting the team’s Definition of Workflow

Tymczasem Kanban Guide opisany na niniejszej stronie definiuje o jedną praktykę mniej:

• Defining and visualizing a workflow
• Actively managing items in a workflow
• Improving a workflow

Na pierwszy rzut oka widać, że pierwsza praktyka na obu listach jest dokładnie taka sama i różnica wynika jedynie ze sposobu jej nazwania.

Podobnie rzecz ma się z przedostatnią praktyką na obu listach: w obu przypadkach chodzi o aktywne zarządzanie jednostkami pracy, które stanowią WIP.

Tożsame są również praktyki wymienione na obu listach jako ostatnie. Wersja dedykowana Scrumowi mówi o dokonywaniu sprawdzenia (ang. inspection) i dostosowania (ang. adaptation) definicji workflowu, co stanowi nawiązanie do używanej w Scrumie empirycznej kontroli procesu. Jej filarami są właśnie sprawdzenie i dostosowanie w połączeniu z przejrzystością (ang. transparency). Jest dość oczywiste, że Zespół Scrum będzie posługiwał się empirycznym podejściem również przy usprawnianiu (ang. improving) definicji workflowu, stąd wybór takiej właśnie formy opisu tej praktyki.

Jedyną faktyczną różnicą jest więc ograniczanie ilości pracy w toku (ang. work in progress), które wydzielone zostało jako osobna praktyka, zamiast stanowić część praktyki aktywnego zarządzania pracą w toku. Skąd bierze się ta różnica? To wymaga nieco dłuższego wyjaśnienia.

Scrum posługuje się iteracjami stałej długości (nazywają się one Sprintami), w których bierze udział tylko Zespół Scrum o znanym składzie, niezmiennym w trakcie Sprintu. W czasie Planowania Sprintu (ang. Sprint Planning) wybierane są z Backlogu Produktu (ang. Product Backlog) elementy, które mają zostać zrealizowane przed końcem iteracji.

Ten model działania automatycznie ogranicza WIP w trakcie Sprintu, bo w sztywno określonym czasie grupa kilku osób jest w stanie zrealizować tylko ograniczony zakres prac. Jest to więc system wciągania pracy (ang. pull system), oczywiście pod warunkiem, że Zespół poprawnie posługuje się Scrumem.

Wiele Zespołów Scrum nie ma świadomości, że w jakikolwiek ogranicza WIP, czy tego chce, czy nie (często wręcz odrzucają Kanban w obawie, że to ograniczanie zacznie być wymagane, tak jakby już go nie było…). Z drugiej strony ograniczenie WIP‑u kontenerem, jakim jest Sprint, pomaga w rozwoju produktu, ale niekoniecznie wystarczy dla uzyskania większej skuteczności działań developerskich wewnątrz każdej iteracji.

Jawny wymóg ograniczania WIP‑u w formie osobnej praktyki (komplementarnej z trzema pozostałymi) ma za zadanie doprowadzić do tego, by system wciągania pracy był budowany świadomie (a nie był pochodną stosowania Sprintów i stałego składu Zespołu). Inaczej mówiąc, chodzi o uzyskanie przepływu a następnie jego optymalizację również w obszarze developmentu.

Przy czym użyte słownictwo zdaje się sugerować, że w ramach tej praktyki wymagane jest stosowanie limitów WIP, ale w istocie chodzi o kontrolowanie poziomu WIP‑u (jego świadome ograniczanie do poziomu, który pozwala uzyskać i utrzymywać przepływ). Limity WIP są jednym z możliwych mechanizmów, jakimi Zespół Scrum może się posłużyć, by to osiągnąć.

Kanban Guide for Scrum Teams opisuje tablicę kanbanową, odwołując się przy tym do Backlogu Produktu i jego elementów oraz Definicji Ukończenia (ang. Definition of Done), która może stanowić podstawę do ustalania obowiązujących zasad (ang. policies). Co oczywiste, Kanban Guide opisany na niniejszej stronie nie zawiera takich bezpośrednich referencji do elementów Scruma.

W opisie wymaganych elementów definicji workflowu pojawia się podobna różnica, jak przy liście praktyk: tam, gdzie Kanban Guide wymaga ustalenia zasad kontrolowania WIP‑u, Kanban Guide for Scrum Teams traktuje o zasadach limitowania. Przy czym różnica jest natury językowej, bo nie jest wcale wymagane stosowanie limitów WIP przy łączeniu Scruma z Kanbanem.

Zaskoczeniem może okazać się to, że Kanban Guide for Scrum Teams nie wymienia oczekiwanego poziomu obsługi (ang. service level expectation, w skrócie SLE) na liście obowiązkowych elementów tablicy kanbanowej. Nie znaczy to jednak, że SLE nie stanowi części definicji workflowu – zapis dotyczący tej prognozy znajduje się w rozdziale dotyczącym praktyki aktywnego zarządzania pracą w toku.

Przy czym SLE nie jest wprost nazwane jako wymagany element – Kanban Guide for Scrum Teams generalnie unika definiowania jakichkolwiek twardych wymogów (w tym podobny jest do definicji Scruma). Kryje się za tym przekonanie, że świadomi użytkownicy i tak nie zdecydują się na pominięcie elementów, bez których optymalizacja przepływu będzie niemożliwa.

Natomiast brak wymogu określenia SLE może mieć jeszcze takie uzasadnienie, że każdy Zespół Scrum ma następujący domyślny oczekiwany poziom obsługi: 100% work itemów wciągniętych do procesu w trakcie Planowania Sprintu ukończone zostanie w ramach tej iteracji. Inaczej mówiąc, czas cyklu co do zasady nie powinien być dłuższy niż długość Sprintu i Zespół Scrum ma zabiegać, by tak faktycznie było.

Natomiast wprowadzając w sposób jawny praktyki kanbanowe do Scruma, dobrym pomysłem jest ustanowienie bardziej wymagającego SLE niż to domyślne. W ten sposób Zespół nie będzie pozostawiał sobie przestrzeni do rozciągania na całą iterację prac, które mogłbyby zostać zakończone szybko.

Licencja, o której mowa w cytowanym fragmencie, odnosi się wyłącznie do treści Przewodnika po Kanbanie (ang. Kanban Guide).

Komentarze opublikowane na niniejszej stronie nie stanowią integralnej części Przewodnika i nie zostały opracowane przez jego twórców.

Rafał Markowicz, autor komentarzy, udostępnia je na podstawie licencji Creative Commons Attribution-NoDerivatives 4.0 International.

Powstały dwa oficjalne tłumaczenia Przewodnika po Kanbanie (ang. Kanban Guide) na język polski. Oba dostępne są na oficjalnej stronie twórców Przewodnika.

Istnienie dwóch przekładów może powodować pewne zamieszanie, ponieważ przekazując tę samą treść merytoryczną, mocno różnią się one językowo. Z przyczyn niezależnych od tłumaczy powstały równolegle, a twórcy Przewodnika zdecydowali o opublikowaniu obu wersji. Dlatego nie zostały uspójnione i połączone w jeden dokument.

Wszystkie komentarze opublikowane na niniejszej stronie są zgodne z tłumaczeniem przygotowanym przez Andy’ego Brandta oraz autora komentarzy.

Jednym zdaniem o mnie, czyli autorze komentarzy opublikowanych na tej stronie: Developer, Scrum Master, praktyk Agile, Professional Scrum Trainer w Scrum.org uczący Scruma, innych metod Agile oraz Kanbana.

Jestem wciąż Developerem, choć nie tak aktywnym, jak kiedyś. Jako akredytowany trener Scrum.org prowadzę szkolenia, pomagając uczestnikom nie tyle uzyskać certyfikaty (choć to również), ile przede wszystkim dobrze użyć Scruma i Kanbana. Prowadzę też sporo innych szkoleń w ramach współpracy z Code Sprinters – zachęcam do zerknięcia na listę kursów, jakie prowadzę (a z kodem 10MPRO można zapisać się na moje szkolenia o 10% taniej).

Piszę artykuły na swoim blogu, ale nie tylko. Jestem współautorem książki Jak oswoić Agile – Poradnik praktycznie zwinny oraz Praca Zdalna – Poradnik. Wraz z kolegą opracowałem również omówienie definicji metody Scrum, czyli Scrum Guide 2020 z komentarzami.

Więcej informacji o mnie można znaleźć na tej stronie.

Andy Brandt to przedsiębiorca, doświadczony manager i konsultant. Osoby zajmujące się zarządzaniem produktami i zespołami, a przede wszystkim użytkownicy metod zwinnych, znają Andy’ego, który jest jedną z kluczowych postaci ruchu Agile w Polsce. Był pierwszym akredytowanym trenerem Scrum.org w Polsce i nadal prowadzi szkolenia tej firmy.

Jest autorem między innymi książki Agile w praktyce – podręcznik metod zwinnych oraz współautorem publikacji Scrum Guide 2020 z komentarzami.

Firma Code Sprinters, której założycielem jest Andy, pierwsza w Polsce oferowała szkolenia akredytowane przez Scrum.org i do dziś organizuje wartościowe szkolenia i warsztaty, skupiając profesjonalnych trenerów-praktyków.

Więcej informacji o Andym można znaleźć na tej stronie.

Słownictwo związane z Kanbanem w wielu przypadkach albo nie ma dobrego odpowiednika w języku polskim, albo jest takich konkurujących ze sobą tłumaczeń wiele i ciężko uznać którekolwiek z nich za oficjalnie obowiązujące.

W komentarzach odnoszących się do poszczególnych części Przewodnika po Kanbanie (ang. Kanban Guide) wskazane zostały liczne przykłady tych językowych trudności w odniesieniu do różnych omawianych terminów.

W praktyce osoby korzystające z Kanbana nie silą się na językowy puryzm i posługują się angielskimi określeniami, dokonując ich spolszczenia. Najlepszym tego przykładem jest workflow, ale można też usłyszeć o pull-systemie czy throughpucie.

W treści komentarzy użyte zostały rozliczne terminy i nazwy własne w języku angielskim, a także szereg akronimów. W tabelach poniżej znajduje się ich kompletne zestawienie wraz z tłumaczeniami.