Powrót do przeszłości: kanban reaktywacja

Chyba większość z nas doświadczyła w świecie projektowym takich problemów, jak rozpoczynanie wielu projektów i zadań oraz ich niekończenie w planowanym czasie, długie cykle realizacji, brak elastyczności wobec zmieniających się wymagań klientów, czy brak sprawnych mechanizmów doskonalenia firmy, procesów, czy projektów. Z drugiej strony obecne warunki biznesowe, z duża złożonością, niepewnością i zmiennością wymagają coraz większej zwinności biznesowej (business agility) i ciągłego doskonalenia. Jeden z kierunków odpowiedzi na te wyzwania i problemy to podejście Kanban.

Od kilku lat Kanban jako metoda usprawniania i metoda realizacji zadań i projektów zdobywa popularność w obszarze IT. Wydawać by się mogło, że to „wynalazek” ostatnich lat. Dla mnie jest to jednak powrót do przeszłości. Pamiętam bowiem wdrożenie systemu ERP w latach 90-tych, a wiec blisko 20 lat temu, w zakładach produkcyjnych dużego koncernu, gdzie do zarządzania przepływem produkcji stosowaliśmy właśnie kanban. Kanban to system fizycznych kart wykorzystywanych w Toyota Production System (TPS) do zarządzania produkcją z wykorzystaniem zasady „pull”.

Obecnie zarówno idea systemu „pull”, jak i same karty kanban znajdują zastosowanie w agile-owym wytwarzaniu oprogramowania, jak i agile-owym zarządzaniu pracami i projektami.

Kanban

Kanban ma 2 podstawowe znaczenia. Pierwsze to: tablica z kartami reprezentującymi zadania do wykonania. Drugie znaczenie – jako Metoda Kanban – to metoda zarządzania zmianami, precyzyjniej: metoda usprawniania procesu i/lub organizacji. Nie jest to natomiast cykl życia lub proces wytwarzania oprogramowania lub zarządzania projektem. W praktyce Kanban to także metoda realizacji zbioru zadań i/lub prac projektowych, więc bardzo często utożsamiany jest ze zbiorem reguł, czy zasad działania. Zanim jednak przedstawię te zasady koniecznie muszę powiedzieć o tzw. pryncypiach Metody Kanban, stanowiących „filozoficzną” podstawę tego podejścia.

Pryncypia Metody Kanban to:

  • Zacznij z tym co masz
  • Respektuj obecną sytuację
  • Zgoda na ciągłe ewolucyjne zmiany
  • Wsparcie przywództwa (ang. leadership) na wszystkich poziomach organizacji.

Natomiast zasady Metody Kanban to:

  • Wizualizacja
  • Limit (Ograniczenie) prac w toku (WIP: Work In Progress)
  • Zarządzanie przepływem (ang. flow)
  • Jasne i jednoznaczne reguły
  • Wprowadzenie pętli zwrotnej (ang. feedback)
  • Wspólne usprawnianie i ciągła ewolucja.

Co powyższe pryncypia i zasady oznaczają w praktyce? Przede wszystkim to, że Kanban jest ewolucyjną metodą usprawniania i wprowadzania zmian i to, że punktem startowym jest odwzorowanie aktualnego procesu, a nie wymyślanie jakiegoś rozwiązania docelowego (czyli stanu „to-be”). Także, to że zmiana i usprawnianie jest procesem ciągłym, trudno więc mówić o „zakończeniu wdrożenia” Kanban. Spośród wcześniej wymienionych zasad najważniejsze są dwie. Są to wizualizacja, czyli po prostu pokazywanie, w możliwie prostej i zrozumiałej dla wszystkich formie, maksymalnie wielu informacji o stanie realizacji zbioru zadań. Druga to ograniczenie prac w toku, czyli określenie ile zadań (tj. właśnie prac w toku – WIP) może być maksymalnie realizowanych na danym etapie procesu. Stosowanie limitów WIP oznacza w praktyce bilansowanie możliwości realizacyjnych wykonawców z napływającym strumieniem zadań (zleceń).

Kanban w działaniu

Jak więc działa system Kanban, jak realizowana jest zasada „pull” i co z ich stosowania wynika zarówno dla opisanych wcześniej problemów biznesowych, jak i dla pracowników i zespołów pracujących wg tej metody oraz dla menedżerów?

Najprościej Kanban w działaniu wyjaśnić przy pomocy powyższego rysunku prezentującego tzw. tablicę kanbanową (Rysunek 1).

Rysunek 1. Przykład tablicy kanbanowej

Po pierwsze pokazuje on aktualną wersję przebiegu procesu: od backlogu (zbioru zadań do realizacji), poprzez development, testowanie i deployment (wdrożenie). Aktualna, gdyż nieco wcześniej mogła ona wyglądać nieco inaczej, np. bez wyodrębnionej kolumny „Done” w Developmencie, dodanej przez zespół jako usprawnienie pozwalające na precyzyjne zidentyfikowanie już zakończonych zadań developerskich. Aktualna, gdyż należy spodziewać się, że ulegnie ona w niedalekiej przyszłości kolejnym zmianom – usprawnieniom. W praktyce stosowania podejścia Kanban jest tak, że jeśli tablica kanbanowa nie ulega zmianie przez 2-3 miesiące, oznacza to, że z pewnością coś jest nie tak z zespołem, który przez ten czas nie zidentyfikował i nie dokonał żadnych usprawnień procesu.

Na rysunku widać także limity WIP określone dla poszczególnych faz procesu, np. limit 3 zadań dla developmentu. Limit ten oznacza, że zespół – w tym przypadku programistów – może pracować nad maksymalnie trzema zadaniami. Określenie poziomu limitu jest dla Kanban bardzo istotne, wykracza jednak poza ramy tego krótkiego artykułu. Limit WIP jest też ściśle powiązany z zasadą „pull” (po polsku „system ssący” prac, co brzmi zdecydowanie gorzej, niż angielski termin „pull”). Pull oznacza bowiem, że praca jest „zasysana/zaciągana” (ang. pull) do danej fazy procesu, np. do testowania, czy developmentu w omawianym przykładzie, wtedy, gdy zespół ma możliwości realizacji tej pracy (tego zadania), tj. gdy liczba realizowanych zadań jest mniejsza niż limit WIP.

W przykładzie na rysunku najpierw Deployment może zrobić pull zadania przetestowanego (znajdującego się w kolumnie Done w Testing). Wtedy zespół testerów będzie miał możliwości realizacyjne (liczba zadań w Testing będzie 1, przy limicie WIP równym 2) i zrobi pull zadania zrobionego przez deweloperów (znajdującego się w kolumnie Done w Development). Taki pull będzie następnie kontynuowany przez deweloperów w odniesieniu do zadań znajdujących się w kolumnie „To Do”. Limit WIP i zasada pull umożliwiają więc z jednej strony zbilansowanie możliwości realizacyjnych z kolejką zadań (popytem na prace), z drugiej zaś eliminują znany nam wszystkim z praktyki projektowej mechanizm push, czyli „wpychania” – najczęściej przez menedżerów – zadań do zespołu ponad jego możliwości realizacyjne. A takie „wpychanie” skutkuje – co z pewnością większość z nas doświadczyła bezpośrednio – wielozadaniowością, wydłużeniem czasu realizacji zadań i projektów, jak i stresem i obniżeniem zadowolenia z pracy.

Tablica kanbanowa na rysunku daje też szereg dodatkowych informacji. Bezpośrednio widać kto realizuje poszczególne zadania („ludziki” i inicjały) oraz z którymi zadaniami wykonawcy maja problemy (czerwone karteczki przyczepione do kart kanbanowych). Bezpośrednio widać też listę zadań do zrobienia (zawartość kolumny backlog), jak i zadania zrealizowane. Razem z informacjami w środkowej części tablicy kanbanowej mamy więc wizualizację stanu projektu w danym momencie – pierwszą zasadę Kanban w praktyce. Natomiast pod poszczególnymi kolumnami – etapami procesu – często przyczepia się inne karteczki, opisujące zasady realizacji prac, np. informacje co zostało przyjęte w procesie jako definicja zakończenia zadania programistycznego.

Tablica kanbanowa daje też informacje o wąskich gardłach, zmusza do zastanowienia się nad cyklem napełniania (ang. replenishment) procesu realizacyjnego oraz nad cyklem wdrażania do produkcji zrealizowanych prac. Te zagadnienia wymagają jednak odrębnego artykułu.

Na koniec warto postawić jeszcze jedno pytanie: a gdzie w tym systemie jest management – kadra zarządzająca?

Moim zdaniem jedna z najważniejszych korzyści Kanban jest to, że jego mechanizmy (opisane powyżej) sprzyjają zarówno samo-organizacji zespołu, jak i wewnętrznej motywacji pracowników, prowadząc w konsekwencji do stanu niemal idealnego z punktu widzenia menedżerów, stanu w którym procesy „same się dzieją”, a produkty niemal „same są wytwarzane”. System pracy Kanban kładzie bowiem nacisk na samoorganizujące się zespoły, dążące do ciągłego usprawniania i doskonalenia. Z drugiej jednak strony dzieki swojej transparentności i stosowaniu kilku stosunkowo prostych narzędzi i mierników, jak Cumulative Flow Diagram (CFD), cykl realizacji (ang. lead time), efektywność przepływu (ang. flow efficiency), czy poziom defektów menedżerowie mają przegląd sytuacji nt. realizacji projektu. Menedżerowie także mogą kształtować budowę systemu Kanban, np. uczestnicząc w określaniu limitów robót w toku, kształtowaniu składu zespołu, przebiegu procesu, jak i zarządzając portfelem projektów firmy oraz relacjami z klientami.

Korzyści biznesowe Kanban

Nadrzędna korzyść systemu Kanban to uzyskanie efektywnego, minimalizującego opór w organizacji mechanizmu wprowadzania zmian i ciągłego doskonalenia rozwiązań organizacyjnych, a tym samym i ich produktów.

Czego jeszcze można spodziewać się jako korzyści systemu Kanban? Praktyczne doświadczenia pokazują, że mogą to być: optymalizacja istniejących procesów, wyższa jakość dostarczanych produktów, poprawa przewidywalności cyklu realizacji zadań (ang. lead time). Zwiększa się też satysfakcja pracowników z pracy, a dodatkowo Kanban stwarza „luz” – rezerwy czasowe, które mogą być wykorzystane przez pracowników jako czas na rozwój, kształcenie, czy po prostu doskonalenie rozwiązań w firmie oraz pomaganie współpracownikom. Luz, czyli rezerwy, umożliwiają także lepsze reagowanie na zmieniające się warunki biznesu i nagłe zapytania i zgłoszenia prac.

Z punktu widzenia menedżerów najważniejsze potencjalne korzyści Kanban to: zwiększona przewidywalność dostarczania rozwiązań i produktów, większa zwinność biznesowa (ang. business agility) oraz właściwy governance nad działaniami firmy.

Na zakończenie: Personal Kanban

I jeszcze jeden, trochę nietypowy aspekt omawianego podejścia: tzw. Personal Kanban. Jest to obecnie niemal ruch związany ze stosowaniem filozofii i zasad Kanban do… poprawienia efektywności pracy na poziomie indywidualnym, do efektywniejszej pracy z wykorzystaniem np. tablic kanbanowych osobistych zadań i limitów prac w toku. Stosuję to podejście do zarządzania niewielką firmą. To już jednak – jak mawiał R. Kipling – jest zupełnie inna historia.