Dlaczego Kanban Działa — i Jak Wiedzieć, Czy Twój Zespół Jest Gotów na Niego

Większość zespołów przyjmuje Kanban, ponieważ ktoś przeczytał artykuł na blogu. Mądrzejsze pytanie brzmi, czy problemy, które Kanban rozwiązuje, są rzeczywiście problemami twojego zespołu.

Jest moment, który większość zespołów rozpoznaje, zwykle około czasu, kiedy mają więcej niż osiem lub dziewięciu ludzi. Praca się odbywa — e-maile są wysyłane, funkcje się wysyłają, klienci są zarządzani — ale nikt nie ma jasnego poczucia, co wszyscy robią. Projekty się piętrują. Rzeczy są obiecywane, a potem cicho zapominane. Spędzisz dwadzieścia minut przed każdym spotkaniem, aby dowiedzieć się, gdzie rzeczywiście znajduje się kawałek pracy. Odpowiedź, zwykle, brzmi "gdzieś".

To jest problem, dla którego Kanban został zaprojektowany. Nie problem strategii, lub zatrudniania właściwych ludzi, lub budowania kultury — ale konkretny, mozolny, operacyjny problem znania, co robi twój zespół i co stoi na przeszkodzie.

To jest zaskakująco skromne narzędzie dla czegoś, co przyciągnęło tyle uwagi. Kanban nie rości sobie pretensji do naprawienia twojej organizacji. Po prostu czyta pracę. I okazuje się, że widoczność, stosowana konsekwentnie, zmienia godną uwagi liczbę rzeczy w dół.

Skąd naprawdę pochodzi Kanban

Słowo jest japońskie — oznacza "tablica" lub "billboard" — a system został opracowany przez Toyotę w końcu lat czterdziestych jako sposób na zarządzanie zapasami w ich fabrykach. Ideą było proste: zamiast wytwarzać części na ustalonym harmonogramie, fabryka wytwarzałaby je tylko wtedy, gdy downstream station sygnalizowała, że ich potrzebuje. Fizyczna karta — kanban — podróżowałaby wstecz po linii jako żądanie. Nic nie było zrobione spekulacyjnie. Nic się nie gromadziło niepotrzebnie.

Spostrzeżenie, które miała Toyota, i które zespoły oprogramowania później pożyczyły, to to, że większość nieefektywności w systemie pochodzi nie z ludzi pracujących zbyt wolno, ale z wykonywania złej pracy w złym czasie. Za wiele rzeczy rozpoczętych naraz. Wąskie gardła, o których nikt nie wie, dopóki nie będzie za późno. Praca, która siedzi skończona w jednym miejscu, podczas gdy następny krok jest przytłoczony gdzieindziej.

Developerzy oprogramowania, zwłaszcza w firmach takich jak Microsoft na początku 2000 lat, zaczęli adaptować te idee do pracy kognitywnej. Karty stały się zadaniami. Stacje fabryczne stały się etapami przepływu pracy. I tablica ogólna stała się tablicą — fizyczną na początku, potem cyfrową — gdzie każdy z zespołu mógł widzieć na pierwszy rzut oka, co jest w toku, co czeka i co zostało zrobione.

Co tablica Kanban faktycznie ci pokazuje

Podstawowa tablica Kanban ma trzy kolumny: Do zrobienia, W toku, Gotowe. To wystarczy dla wielu małych zespołów i dobrego miejsca do rozpoczęcia. Ale rzeczywista wartość pojawia się, gdy zaczniesz dostosowywać te etapy do tego, jak twoja praca faktycznie płynie — nie jak chciałbyś, żeby płynęła.

Zespół treści może używać: Pomysł, Krótkie, W projekcie, W przeglądzie, Zaplanowane, Opublikowane. Zespół oprogramowania może rozbić "W toku" na osobne kolumny dla rozwoju, przeglądu kodu i QA. Zespół konsultingowy może śledzić Odkrycie, Propozycję, Aktywne, Czekające na klienta i Zamknięte. Etapy powinny odzwierciedlać rzeczywiste przekazania i rzeczywiste czasy oczekiwania — miejsca, gdzie praca zmienia ręce, lub gdzie siedzi, aż coś innego się stanie.

Zauważ kartę w środkowej kolumnie — raport audytu magazynu, osiem dni, oznaczony jako zablokowany. W systemie bez tablicy to zadanie mogło by siedzieć przez dwa kolejne tygodnie, zanim ktoś zdałby sobie sprawę, że się nie porusza. Ktoś czeka na trzecią stronę. Albo potrzebna jest decyzja od menedżera, który nie wie, że jest blokadą. Tablica czyni blokadę widoczną. To większość pracy.

Reguła, która to sprawia: limity WIP

Jeśli istnieje jedna koncepcja, która oddziela zespoły korzystające z Kanban prawidłowo od zespołów, które mają tylko ładniejszą listę do zrobienia, to limity pracy w toku — limity WIP w skrócie. Ideą jest to, że każda kolumna ma maksymalną liczbę elementów, które mogą być tam jednocześnie. Kiedy kolumna jest pełna, nie możesz dodać więcej pracy, dopóki coś się nie wysuwa.

To czuje się nieintuicyjnie. Czy bycie w stanie umieścić więcej zadań w toku oznacza, że ​​więcej się robi? To nie. Co się naprawdę dzieje, gdy ludzie pracują nad zbyt wieloma rzeczami jednocześnie, to to, że wszystko trwa dłużej. Przełączanie kontekstu jest kosztowne. Niedokończona praca tworzy narzut koordynacji. A kiedy dziesięć rzeczy jest "w toku", bardzo trudno jest stwierdzić, które faktycznie się poruszają, a które po prostu się utknęły, ale nieoznaczone.

Limit WIP wynoszący trzy w kolumnie W toku oznacza, że ​​kiedy czwarta rzecz trafia na czyjś biurko, ktoś z zespołu musi podjąć decyzję: które istniejące zadanie zostaje zakończone najpierw? To wymusza priorytetyzację. To wymusza rozmowę. I tends to produce faster completion of individual items, even if the rate of starting new items slows.

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

Jeśli spędziłeś trochę czasu wokół zespołów oprogramowania lub nowoczesnego myślenia operacyjnego, prawdopodobnie napotkałeś Scrum — ramy, które organizują pracę w stałe dwutygodniowe sprinty, z sesjami planowania, retrospektywami i zdefiniowanymi rolami, takimi jak Mistrz Scrum i Właściciel Produktu. Wiele zespołów traktuje Scrum i Kanban jako konkurujące metodologie i czuje, że muszą wybrać. Rozróżnienie jest faktycznie prostsze.

Wiele zespołów — zwłaszcza tych, które nie są czysto zespołami inżynierii oprogramowania — uważa ceremonię Scrum za ciężką i jego strukturę sprintu za niezręczną do zastosowania do bieżącej pracy operacyjnej. Zespoły marketingowe, zespoły sukcesu klienta, zespoły operacyjne i założyciele zarządzający wszystkim jednocześnie rzadko mają pracę, która wpisuje się schludnie w dwutygodniowe cykle. Model przepływu ciągłego Kanban zwykle bardziej im odpowiada.

To powiedziawszy, wiele zespołów łączy oba podejścia. Używają cykli planowania w stylu sprintu dla rozwoju produktu, jednocześnie prowadząc tablicę Kanban dla pracy operacyjnej i wspierającej, która płynie niezależnie od tego, jaki sprint jesteś. To całkowicie rozsądny hybrydowy.

Trzy pytania, na które twoja tablica powinna odpowiedzieć w trzydzieści sekund

Tablica Kanban jest najbardziej przydatna, gdy możesz się na nią patrzeć i bez rozmowy z kimś, szybko odpowiedzieć na te trzy pytania: Co robi zespół teraz? Gdzie praca się utyka? Czy jest coś, co powinno być zrobione, ale nie zostało rozpoczęte?

Jeśli nie możesz odpowiedzieć na wszystkie trzy w ciągu trzydziestu sekund patrzenia na tablicę, prawdopodobnie nie jest prawidłowo utrzymywana. Najczęstszym trybem awarii jest tablica, gdzie zadania są tworzone, ale nigdy nie przenoszone — staje się cmentarzem dobrych chęci zamiast żywą mapą rzeczywistej pracy. Tablica, która nie jest aktualna, jest gorsza niż brak tablicy, ponieważ tworzy fałszywe poczucie widoczności.

Dyscyplina wymagana do utrzymania tablicy jest rzeczywista. Zadania muszą się poruszać, gdy praca się porusza. Zablokowane przedmioty muszą być oflagowane w momencie, gdy się zatrzymają, a nie dwa tygodnie później. Karty muszą mieć jasnych właścicieli, a właściciele muszą aktualizować swoje karty. Nic z tego nie wymaga dużo czasu — dobrze prowadzona praktyka Kanban może zająć pięć do dziesięciu minut na osobę dziennie — ale wymaga konsekwencji. Zespoły, które najbardziej czerpią korzyści z Kanban, to te, które traktują tablicę jako źródło prawdy, a nie jako ćwiczenie uzupełniającego prowadzenia dokumentacji.

Czego Kanban nie robi

Kanban to nie narzędzie strategii. Nie pomoże ci ustalić, na co pracować — tylko pomoże ti zarządzać tym, na co już postanowiłeś pracować. Jeśli twoja organizacja ma problem z priorytetyzacją, lub problem z niejasnym mandatem, lub "zaczynamy zbyt wiele projektów przed ukończeniem starych" problem zakorzeniony w zachowaniu przywództwa zamiast procesu, tablica Kanban ujawni te problemy, ale ich nie rozwiąże.

To również nie jest substytut dla dobrego zarządzania. Tablica nie zastępuje one-to-ones, lub przemyślane delegowanie, lub jasną komunikację o tym, dlaczego pewna praca jest ważna. Zespoły czasami przyjmują narzędzia procesowe, mając nadzieję, że proces będzie robić relacyjną i organizacyjną pracę, która faktycznie jest pracą menedżera. To nie będzie.

Co to będzie robić, to zmniejszyć otoczenie niepewności, która spowalnia większość zespołów. Pytania "kto pracuje nad czym", "czy to jest zrobione" i "co powinienem podnieść dalej" 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. I dla zespołów, gdzie ten szum jest dominującym problemem, różnica jest znacząca.

Jak zacząć — bez warsztatu trzy dni

Najlepsze implementacje Kanban, które widziałem, zaczynały się małe i ewoluowały. Najgorszymi były te, w których konsultant, dwudniowy wyjazd, i pięknie zaprojektowana tablica, którą nikt nie używał w trzecim tygodniu.

Zacznij z twojego zespołu takim, jaki naprawdę jest, z pracą, którą naprawdę masz. Stwórz trzy kolumny: Backlog, W toku, Zrobione. Spędź trzydzieści minut z twoim zespołem, umieszczając każdy bieżący element pracy na karcie. Zgódź się na jedną regułę: kiedy coś startujesz, idzie na tablicę. Kiedy się porusza, poruszasz kartę. Nie rób nic innego przez dwa tygodnie.

Po dwóch tygodniach spojrz na tablicę razem. Gdzie rzeczy się piętrzyły? Co siedziało w Backlog, co wszyscy powiedzieli, że jest priorytetem? Co poruszało się szybciej niż oczekiwano? Co się utknęło i dlaczego? Użyj tego, co obserwujesz, aby udoskonalić kolumny i dodać konkretność. Może "W toku" musi się podzielić na "W toku" i "Czekające na zewnętrzne". Może potrzebujesz kolumny zwanej "W przeglądzie", ponieważ ten krok ciągle się gubi. Pozwól tablicy ewoluować w odpowiedzi na to, co twoja rzeczywista praca ujawnia, a nie w odpowiedzi na to, co książka metodologii mówi, że powinno wyglądać.

Dłuższa gra: metryki przepływu

Gdy system Kanban działa, generuje dane, które większość zespołów nigdy nie używa. Czas opóźnienia — całkowity czas od momentu utworzenia zadania do jego ukończenia — jest najważniejszy. Jeśli twój średni czas opóźnienia dla typowego zadania wynosi dwanaście dni, a chcesz, żeby był pięć, masz teraz liczbę do pracy i tablicę, która ci pokaże, gdzie te dodatkowe siedem dni idzie.

Czas cyklu mierzy tylko aktywny okres pracy, wyłączając czas, w którym zadanie siedzi w backlogu. Przepustowość mierzy, ile elementów twój zespół ukończy na tydzień. Żadna z tych metryk nie wymaga specjalnego oprogramowania, jeśli jesteś zdyscyplinowany co do zanotowania, kiedy karty są tworzone i kiedy są zamykane. I razem dają ci znacznie bardziej szczerą ideę zdolności twojego zespołu niż jakikolwiek proces planowania oparty na szacunkach.

Większość małych i średnich zespołów nigdy tutaj nie dochodzi. Używają Kanban jako narzędzia widoczności — które jest wartościowe samo w sobie — i nie idą dalej. To jest w porządku. Ale jeśli okaże się, że chcesz zaangażować się interesariuszom na temat tego, kiedy coś będzie zrobione, lub chcesz zrozumieć, dlaczego praca jest trzy razy dłuższa niż oczekiwano, metryki są tam, gdy ich potrzebujesz.