Dlaczego Kanban działa — i jak sprawdzić, czy Twój zespół jest na niego gotowy

Większość zespołów wdraża Kanban, bo ktoś przeczytał artykuł na blogu. Mądrzejsze pytanie brzmi: czy problemy, które rozwiązuje Kanban, to rzeczywiście problemy Twojego zespołu?

Jest taki moment, który zna większość zespołów — zwykle wtedy, gdy ludzi jest więcej niż ośmiu czy dziewięciu. Praca idzie do przodu: wysyłane są e-maile, wychodzą kolejne funkcje, klienci są obsłużeni — ale nikt nie ma jasnego obrazu tego, czym zajmują się pozostali. Projekty się piętrzą. Obietnice składane są i po cichu zapominane. Przed każdym spotkaniem tracisz dwadzieścia minut na ustalanie, na jakim etapie naprawdę jest dane zadanie. Odpowiedź zazwyczaj brzmi: „gdzieś w toku”.

Właśnie ten problem miał rozwiązać Kanban. Nie problem ustalania strategii, zatrudniania odpowiednich ludzi czy budowania kultury organizacyjnej, lecz konkretny, uciążliwy problem operacyjny: wiedzieć, nad czym pracuje zespół i co mu w tym przeszkadza.

To zaskakująco skromne narzędzie jak na tyle zainteresowania, jakie wzbudziło. Kanban nie twierdzi, że naprawi Twoją organizację. Po prostu uwidacznia pracę. A okazuje się, że widoczność, stosowana konsekwentnie, zmienia zdumiewająco wiele rzeczy w dalszej perspektywie.

Skąd naprawdę wziął się Kanban

To słowo japońskie — oznacza „tablicę” lub „szyld” — a system opracowała Toyota pod koniec lat 40. XX wieku, aby zarządzać zapasami w swoich zakładach produkcyjnych. Pomysł był prosty: zamiast produkować części według sztywnego harmonogramu, fabryka wytwarzała je tylko wtedy, gdy kolejne stanowisko sygnalizowało, że ich potrzebuje. Fizyczna karta — kanban — wędrowała w górę linii jako zamówienie. Nic nie powstawało na zapas. Nic niepotrzebnie się nie piętrzyło.

Toyota doszła do wniosku, który później przejęły zespoły programistyczne: większość nieefektywności w systemie bierze się nie stąd, że ludzie pracują zbyt wolno, lecz stąd, że w złym momencie wykonuje się niewłaściwą pracę. Zbyt wiele rozpoczętych spraw naraz. Wąskie gardła, których nikt nie zauważa, dopóki nie jest za późno. Praca, która leży ukończona w jednym miejscu, podczas gdy kolejny etap tonie w zadaniach gdzie indziej.

Programiści, zwłaszcza w firmach takich jak Microsoft na początku lat 2000., zaczęli adaptować te idee do pracy umysłowej. Karty stały się zadaniami. Stanowiska fabryczne — etapami przepływu pracy. A tablica z szyldem zamieniła się w tablicę zadań — najpierw fizyczną, potem cyfrową — na której każdy członek zespołu mógł jednym rzutem oka zobaczyć, co jest w toku, co czeka, a co zostało zrobione.

Co naprawdę pokazuje tablica Kanban

Podstawowa tablica Kanban ma trzy kolumny: Do zrobienia, W toku i Gotowe. Dla wielu małych zespołów to wystarczy i jest dobrym punktem wyjścia. Prawdziwa wartość pojawia się jednak, gdy zaczniesz dostosowywać te etapy do tego, jak praca faktycznie płynie — a nie do tego, jak chciałbyś, żeby płynęła.

Zespół contentowy może używać etapów: Pomysł, Brief, W pisaniu, W recenzji, Zaplanowane, Opublikowane. Zespół programistów może rozbić „W toku” na osobne kolumny: development, code review i QA. Zespół doradczy może śledzić etapy: Rozpoznanie, Oferta, Aktywne, Oczekiwanie na klienta i Zamknięte. Etapy powinny odzwierciedlać rzeczywiste przekazania pracy i rzeczywiste czasy oczekiwania — miejsca, w których praca przechodzi z rąk do rąk albo czeka, aż wydarzy się coś innego.

Zwróć uwagę na kartę w środkowej kolumnie — raport z audytu magazynu, który po ośmiu dniach jest oznaczony jako zablokowany. W systemie bez tablicy to zadanie mogłoby przeleżeć kolejne dwa tygodnie, zanim ktokolwiek zauważyłby, że stoi w miejscu. Ktoś czeka na stronę trzecią. Albo potrzebna jest decyzja kierownika, który nie wie, że to on jest wąskim gardłem. Tablica uwidacznia blokadę. I to jest większość pracy.

Zasada, która sprawia, że to działa: limity WIP

Jeśli istnieje jedno pojęcie, które odróżnia zespoły stosujące Kanban prawidłowo od tych, które mają po prostu ładniejszą listę zadań, to są to limity pracy w toku — w skrócie limity WIP. Chodzi o to, że każda kolumna ma maksymalną liczbę elementów, które mogą się w niej znajdować jednocześnie. Gdy kolumna jest pełna, nie można dodać kolejnej pracy, dopóki coś z niej nie wyjdzie.

To wydaje się sprzeczne z intuicją. Przecież możliwość rozpoczęcia większej liczby zadań oznacza, że więcej zostanie zrobione? Nie. Gdy ludzie pracują nad zbyt wieloma rzeczami naraz, w rzeczywistości wszystko trwa dłużej. Przełączanie kontekstu jest kosztowne. Praca w połowie skończona generuje dodatkowy narzut koordynacyjny. A gdy „w toku” jest dziesięć spraw, bardzo trudno ocenić, które naprawdę posuwają się naprzód, a które po prostu utknęły, tylko nikt tego nie zaznaczył.

Limit WIP równy trzy w kolumnie „W toku” oznacza, że gdy czwarte zadanie trafia na czyjeś biurko, ktoś w zespole musi podjąć decyzję: które z istniejących zadań zostanie dokończone w pierwszej kolejności? Wymusza to ustalanie priorytetów. Wymusza rozmowę. I zwykle prowadzi do szybszego kończenia poszczególnych zadań, nawet jeśli tempo rozpoczynania nowych spada.

Kanban czy Scrum: pytanie, które zespoły zadają zawsze

Jeśli miałeś do czynienia z zespołami programistycznymi albo nowoczesnym zarządzaniem operacjami, pewnie spotkałeś się ze Scrumem — frameworkiem, który organizuje pracę w sztywne dwutygodniowe sprinty, ze spotkaniami planistycznymi, retrospektywami i zdefiniowanymi rolami, takimi jak Scrum Master i Product Owner. Wiele zespołów traktuje Scrum i Kanban jako konkurencyjne metodyki i uważa, że musi wybierać. W rzeczywistości różnica jest prostsza.

Wiele zespołów — zwłaszcza tych, które nie są czysto programistyczne — uważa ceremoniał Scrumu za ciężki, a jego sztywną strukturę sprintów za niewygodną w zastosowaniu do bieżącej pracy operacyjnej. Zespoły marketingu, obsługi klienta (customer success) i operacji, a także założyciele zajmujący się wszystkim naraz, rzadko mają pracę, która zgrabnie mieści się w dwutygodniowych cyklach. Model ciągłego przepływu w Kanbanie zazwyczaj lepiej się u nich sprawdza.

To powiedziawszy, wiele zespołów łączy oba podejścia. Używają cykli planowania w stylu sprintów do rozwoju produktu, a jednocześnie prowadzą tablicę Kanban dla pracy operacyjnej i wsparcia, które napływają niezależnie od tego, w którym sprincie akurat jesteście. To całkowicie rozsądny model hybrydowy.

Trzy pytania, na które Twoja tablica powinna odpowiadać w trzydzieści sekund

Tablica Kanban jest najbardziej użyteczna wtedy, gdy możesz na nią spojrzeć i bez rozmowy z kimkolwiek szybko odpowiedzieć na trzy pytania: Czym zespół zajmuje się w tej chwili? Gdzie praca się zacina? Czy jest coś, co powinno zostać zrobione, a nie zostało rozpoczęte?

Jeśli nie potrafisz odpowiedzieć na wszystkie trzy w ciągu trzydziestu sekund od spojrzenia na tablicę, prawdopodobnie nie jest ona właściwie prowadzona. Najczęstszy scenariusz porażki to tablica, na której zadania są tworzone, ale nigdy nie przesuwane — staje się cmentarzem dobrych intencji, a nie żywą mapą rzeczywistej pracy. Nieaktualna tablica jest gorsza niż jej brak, bo daje fałszywe poczucie przejrzystości.

Dyscyplina potrzebna do prowadzenia tablicy jest realna. Zadania trzeba przesuwać, gdy przesuwa się praca. Zablokowane elementy należy oznaczać w chwili, gdy utkną, a nie dwa tygodnie później. Karty muszą mieć jasnych właścicieli, a właściciele muszą je aktualizować. Nic z tego nie wymaga dużo czasu — dobrze prowadzona praktyka Kanban może zajmować pięć do dziesięciu minut dziennie na osobę — ale wymaga konsekwencji. Najwięcej z Kanbanu korzystają zespoły, które traktują tablicę jako źródło prawdy, a nie jako dodatkowe ćwiczenie w prowadzeniu dokumentacji.

Czego Kanban nie robi

Kanban nie jest narzędziem strategicznym. Nie pomoże Ci zdecydować, czym się zająć — pomaga tylko zarządzać tym, co już postanowiłeś robić. Jeśli Twoja organizacja ma problem z ustalaniem priorytetów, niejasnym mandatem albo z tym, że „zaczynamy za dużo projektów, zanim skończymy stare” — a źródłem jest zachowanie kadry kierowniczej, nie proces — tablica Kanban te problemy ujawni, ale ich nie rozwiąże.

Nie zastępuje też dobrego zarządzania. Tablica nie zastąpi rozmów indywidualnych, przemyślanego delegowania ani jasnego komunikowania, dlaczego dana praca jest ważna. Zespoły czasem wdrażają narzędzia procesowe w nadziei, że proces wykona pracę relacyjną i organizacyjną, która tak naprawdę należy do menedżera. Nie wykona.

Co natomiast zrobi, to ograniczy ogólną niepewność, która spowalnia większość zespołów. Pytania „kto nad czym pracuje”, „czy to jest już zrobione” i „co mam wziąć jako następne” generują ogromne ilości komunikacji o niskiej wartości w organizacjach, które nie mają wspólnego, widocznego systemu. Kanban eliminuje większość tego szumu. A dla zespołów, w których ten szum jest głównym problemem, różnica jest znacząca.

Jak zacząć — bez trzydniowych warsztatów

Najlepsze wdrożenia Kanbana, jakie widziałem, zaczynały się od małej skali i ewoluowały. Najgorsze angażowały konsultanta, dwudniowy wyjazd integracyjny i pięknie zaprojektowaną tablicę, której nikt nie używał już w trzecim tygodniu.

Zacznij od zespołu takiego, jaki jest, i pracy, którą faktycznie masz. Utwórz trzy kolumny: Backlog, W toku, Gotowe. Poświęć z zespołem trzydzieści minut na przeniesienie każdego bieżącego zadania na kartę. Ustalcie jedną zasadę: gdy zaczynasz coś robić, trafia to na tablicę. Gdy to się posuwa, przesuwasz kartę. Przez dwa tygodnie nie rób nic więcej.

Po dwóch tygodniach przyjrzyjcie się tablicy razem. Gdzie praca się piętrzyła? Co zostało w Backlogu, choć wszyscy mówili, że to priorytet? Co poszło szybciej, niż się spodziewano? Co utknęło i dlaczego? Wykorzystaj te obserwacje, aby dopracować kolumny i dodać konkretu. Może „W toku” trzeba rozdzielić na „W toku” i „Oczekiwanie na stronę zewnętrzną”. Może potrzebujesz kolumny „W recenzji”, bo ten krok ciągle gdzieś ginie. Pozwól tablicy ewoluować w odpowiedzi na to, co pokazuje Wasza rzeczywista praca, a nie na to, jak według podręcznika metodyki powinna wyglądać.

Gra na dłuższą metę: metryki przepływu

Gdy system Kanban już działa, generuje dane, z których większość zespołów nigdy nie korzysta. Najważniejszy jest lead time — całkowity czas od utworzenia zadania do jego ukończenia. Jeśli średni lead time typowego zadania wynosi dwanaście dni, a chcesz, by wynosił pięć, masz teraz liczbę, do której możesz dążyć, i tablicę, która pokaże, gdzie giną te dodatkowe siedem dni.

Cycle time mierzy tylko okres aktywnej pracy, z pominięciem czasu, który zadanie spędza w backlogu. Przepustowość (throughput) mierzy, ile elementów zespół kończy w tygodniu. Żadna z tych metryk nie wymaga specjalnego oprogramowania, jeśli konsekwentnie odnotowujesz, kiedy karty powstają i kiedy są zamykane. Razem dają znacznie bardziej rzetelny obraz możliwości zespołu niż jakikolwiek proces planowania oparty na szacunkach.

Większość małych i średnich zespołów nigdy do tego nie dochodzi. Używają Kanbana jako narzędzia przejrzystości — co samo w sobie jest cenne — i nie idą dalej. To w porządku. Ale jeśli zechcesz składać interesariuszom zobowiązania co do terminu zakończenia czegoś albo zrozumieć, dlaczego część pracy trwa trzy razy dłużej, niż zakładano, metryki będą na Ciebie czekać.