Historia Metody Kanban

Kanban przebył długą drogę do uzyskania statusu istotnej części metodyki Zarządzania Lean, którą jest dzisiaj. Warto zapoznać się z bogatą historią Kanbana, rozpoczynającą się w japońskim okresie Edo.

Wiek XVII - korzenie Kanbana

W 1603 roku w Japonii dobiegł kresu trwający od wieku XIV wyniszczający okres niemal ciągłych konfliktów zbrojnych i niepokojów społecznych. Japonia wkroczyła w etap stabilności i wzrostu gospodarczego. W miarę rozkwitu gospodarki, ulice japońskich miast zapełniały się sklepikami i przedsiębiorstwami konkurującymi o świadomość i uwagę klientów. To na tych ulicach narodził się termin „Kanban”.

Co to znaczy Kanban?

Nazwa Kanban pochodzi od złączenia dwóch japońskich słów: “Kan” (看) – znak i “Ban” (板) – tablica. Podczas gdy japońskie ulice stawały się coraz bardziej zatłoczone, właściciele sklepów zaczęli afiszować swoje usługi spersonalizowanymi szyldami „KanBan”, aby zwrócić uwagę przechodniów i zasygnalizować jaki rodzaj usług świadczą. Wkrótce projektanci znaków Kanban rozpoczęli zaciekłą konkurencję adoptując artystyczne podejście do ich tworzenia, nadając im formy wyróżniające się spośród innych Kanbanów na ulicy. Praktyka ta trwa do dziś w projektowaniu nowoczesnych neonów. Przyglądając się przykładom bogatej kolekcji z tamtych czasów, trafić możemy na przypominający rybę znak Kanban sklepiku rybnego, czy też artystycznie stylizowaną drewnianą fajkę, wykonaną jako Kanban dla sklepu tytoniowego.

Wszystkie oryginalne znaki Kanban miały jedną cechę wspólną – podobnie jak współczesne kartki Kanban, potrafiły jasno i zwięźle zakomunikować swoją treść.

Lata 1940-te: Toyota i Kanban w Produkcji

Produkować tylko to, na co jest zapotrzebowanie; na czas i w wymaganej ilości. Taiichi Ōno

“Wszystko idzie dobrze: Toyota” było przed laty pamiętnym sloganem firmy. Jednak w samej Toyocie nie zawsze produkcja szła gładko.

W latach czterdziestych Toyota nie była gigantem przemysłu motoryzacyjnego, za jakiego uznajemy ją dzisiaj. Po drugiej wojnie światowej japoński przemysł samochodowy znajdował się w stagnacji. Toyota notowała straty, nie mogąc konkurować z żadnym z amerykańskich producentów samochodów. Firma była w tak złej kondycji, że nawet zatrudnienie nowego personelu było poza jej możliwościami. Jednak dyrektor generalny Kiichiro Toyoda podjął się misji by to zmienić. Zdawał sobie sprawę, że dziesięciokrotnej różnicy w produktywności między Toyotą a jej amerykańskimi konkurentami nie można wytłumaczyć wyłącznie brakiem sprzętu – problem był bardziej złożony. Postawił jednak sobie za cel dorównanie im produktywnością w ciągu trzech lat. Mimo, że tak ambitny cel okazał się trudny do zrealizowania, na długie lata wyznaczył firmie kurs oparty na innowacji i optymalizacji organizacji pracy.

Zmiana w kulturze firmy jaka wówczas zaszła, otworzyła nowe drogi zmiany dla Taiichi Ōno, młodego inżyniera przemysłowego, który trafił do Toyota Motor Company w 1943 roku.

Taiichi Ōno, źródło: wikimedia.org

Taiichi Ōno miał silny charakter i szybko awansował w szeregach Toyoty. W 1949 roku został kierownikiem warsztatu mechanicznego, co pozwoliło mu rozpocząć eksperymentowanie z nowymi narzędziami i zasadami organizacji pracy. W roku 1954 awansował na stanowisko dyrektora.

Ōno zidentyfikował i sklasyfikował siedem rodzajów strat (jap. Muda), prowadzących do spadku przepustowości i wydajności systemu.

Siedem rodzajów strat (Muda)

Nadprodukcja była stratą z tego względu, że wymagania klientów mogą się zmieniać w czasie. Jednak utrzymywanie dużego zapasu surowców również przynosi straty. Jedynym rozwiązaniem tego pozornego paradoksu było produkowanie dokładnie tego, co jest potrzebne i tylko wtedy, kiedy tego potrzeba. Wymagało to ograniczenia zapasów do minimum przy jednoczesnym zapewnieniu płynnego i wydajnego przepływu pracy przez cały proces. Podejście to zrodziło nowy problem: jak zasygnalizować, że potrzebny jest nowy produkt? Jak dostarczyć ten sygnał na linię produkcyjną i do dostawców surowców?

Pomocne okazały się sposoby organizacji supermarketów. Ōno odwiedził Stany Zjednoczone w 1956 roku i zaimponowało mu to, jak zarządcy sieci Piggly Wiggly byli w stanie utrzymać odpowiednie ilości każdego produktu na półkach. Po powrocie do Japonii, Ōno wprowadził system papierowych kart do sygnalizowania i śledzenia popytu w swojej fabryce, nazywając go „Kanbanem”.

Do każdego gotowego produktu dołączano karty Kanban, które po sprzedaży wracały na linię produkcyjną. Zespół mógł zacząć pracę nad nowym elementem tylko wtedy, gdy wróciła do niego kartka sygnalizująca zapotrzebowanie na tą część i tylko wtedy, gdy liczba oczekujących kartek osiągnęła określony próg. Kartki dołączane były również do każdego materiału użytego podczas produkcji, dzięki czemu sygnał zapotrzebowania płynął przez cały łańcuch produkcyjny, docierając do dostawców zewnętrznych.

Zasady Kanbana w produkcji, źródło: wikimedia.org

Nowy system zmniejszył ilość magazynowanych surowców, poprawił przepustowość oraz zapewnił przejrzystość procesu. Jego zastosowanie szybko rozprzestrzeniło się na cały dział obróbki maszynowej. W 1963 roku opracowano plan adopcji tego systemu w całej firmie i wkrótce był on stosowany w prawie każdym procesie wewnątrz Toyota.

Dzięki zastosowaniu systemu Kanban, niegdyś operująca ze stratą Toyota stała się globalnym potentatem. Taiichi Ōno awansował przez wyższe szczeble firmy, w 1975 roku zostając wiceprezesem wykonawczym. Jego praca dała początek nie tylko nowemu znaczeniu słowa „Kanban”, położyła także podwaliny pod nowoczesne techniki zarządzania, znane jako System Produkcyjny Toyota.

2003-2008: Kanban w programowaniu

W miarę jak System Produkcyjny Toyoty zyskiwał na popularności i wieści o nim się roznosiły, kierownicy projektów z różnych branż próbowali zastosować jego podstawy w swoich środowiskach.

Największy przełom nastąpił w pracy zespołów programistycznych.

Zarządzanie projektami w oprogramowaniu zaczynało wówczas stopniowo odchodzić od uciążliwych i nieefektywnych procesów takich jak CMMI (kompleksowy model dojrzałości organizacyjnej), w kierunku bardziej lekkiego, „zwinnego” podejścia, jakie zostało sformalizowane w 2001 roku pod szyldem Manifestu Programowania Zwinnego.

Manifest Programowania Zwinnego, źródło: agilemanifesto.org

Manifest i leżące u jego podstaw zasady zawierały ogólne idee, np. “bycie otwartym na zmieniające się wymagania” lub “częste dostarczanie działającego oprogramowania”, nie precyzowały jednak w jaki sposób należy osiągać te cele. W odpowiedzi wyewoluowało kilka różnych systemów zarządzania pracą, ujmujących przekaz Manifestu. Stały się one rdzeniem zwinnego rozwoju oprogramowania w tamtym czasie. Najważniejsze z nich to Scrum, programowanie ekstremalne (XP) i, nieco później, Lean Software Development.

Elementy Scrum, Lean Software Development i Zarządzania Zwinnego wywarły znaczący wpływ na to, czym miała stać się metoda Kanban.

• Scrum
  Zespoły pracujące ze Scrum często używały tablic korkowych z karteczkami historyjek użytkowników, jako promienników informacji. Zwykle działało to tak: podczas planowania Sprintu każda historyjka lub funkcja do zaimplementowania była zapisywana na osobnej fizycznej karteczce. Wszystkie kartki, tworzące rejestr Sprintu, umieszczane były na sporej tablicy gdzieś w biurze, w miejscu dostępnym dla wszystkich. Każdy członek zespołu mógł podejść do tablicy, przyjrzeć się karteczkom i wybrać to zadanie, które chciał wdrożyć. Następnie zabierał kartkę do swojego biurka, a po zakończeniu pracy przekreślał ją i odnosił na tablicę. System był genialny w swojej prostocie. Zapewniał jasny wgląd w postępy, umożliwiał synchronizację pracy wszystkich programistów i poprawiał przepływ zadań, jako że każdy programista mógł wybrać rodzaj zadania, w którym czuł się najlepiej.

• Lean Software Development
  W 2003 r. Mary i Tom Poppendieck opublikowali klasyczną dziś książkę na temat tworzenia oprogramowania “Lean Software Development: An Agile Toolkit”. Książka ta przełożyła zasady produkcji Lean, wywodzącej się z Systemu Produkcyjnego Toyota, na domenę rozwoju oprogramowania - na pracę z wiedzą. Autorzy skoncentrowali się na eliminacji strat, mapowaniu strumienia wartości i systemie pull. W 2007 roku ukazała się następna książka tych samych autorów: “Implementing Lean Software Development: From Concept to Cash”. Autorzy rozwinęli w niej wykorzystanie teorii kolejkowania zadań w celu skrócenia czasu dostarczenia oprogramowania oraz użycie tablic Kanban jako elementu wizualnej przestrzeni roboczej. Ponadto, w 2005 r. Jim Sutton i Peter Middleton opublikowali “Lean Software Strategies”, definiując pięć zasad produkcji Lean do zastosowania przy tworzeniu oprogramowania: definiowanie wartości, mapowanie strumienia wartości, implementacja przepływu zadań, utrzymanie zasady pull w procesie oraz pozostawanie otwartym na możliwości doskonalenia.

• Zwinne Zarządzanie
  Poza Scrum i Lean Software Development, badano również inne koncepcje tego, jak zespoły mogłyby stać się bardziej zwinne. W 2004 roku David Anderson opublikował książkę “Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results”, obejmującą pojęcia takie jak: przepływ, wąskie gardło, kontrola wizualna i diagram skumulowanego przepływu. Wszystkie z nich Anderson włączył później do swojej koncepcji metody Kanban.

W tym samym czasie niektóre zespoły programistyczne, korzystające już z tablic Scrum, przyjęły te nowe techniki i przeorganizowały swoje tablice, wprowadzając kolumny reprezentujące poszczególne etapy pracy, dając w ten sposób początek praktycznym tablicom Kanban.

Połączenie tablic Kanban z elementami Lean Software Development i Zarządzania Zwinnego takimi jak Planowanie Pull, ograniczanie pracy w toku względem zasobów i monitorowanie przepływu, dało początek trendowi rozwijania oprogramowania w stylu Kanban.

Tak zbudowany Kanban dla programistów zyskał akceptację jako system sam w sobie, ponieważ rozwiązywał bolączki, z którymi Scrum nie radził sobie szczególnie dobrze: skrócenie czasu cyklu od zgłoszenia klienta do dostarczenia oprogramowania i zapewnienie ciągłego przepływu pracy.

W klasycznej metodzie Scrum, po zamknięciu sesji planowania Sprintu, rejestr zadań zostaje zamrożony, nie można wprowadzać żadnych zmian. Stan ten trwa zwykle od siedmiu do trzydziestu dni i podczas gdy zespół przechodzi przez listę zadań, zdarza się że okazuje się frustrujący zarówno dla programistów, jak i klientów. Cóż bowiem zrobić w sytuacji awaryjnej, gdy konkretne rozwiązanie musi zostać zaimplementowane “na wczoraj”? Jak podejść do bugów wykrytych w aktywnym produkcie - czy trzeba zmuszać klientów do czekania na ich naprawienie przez około miesiąc? I wreszcie: jak obsłużyć procesy o bardziej dynamicznej naturze, np. marketing stron internetowych czy administracja serwerów?

Kanban, ze swoimi wizualnymi tablicami i koncentracją na przepływie, stał się odpowiedzią na te potrzeby, zapewniając usystematyzowany, czytelny i elastyczny sposób zarządzania pracą.

W czasie gdy zainteresowanie rozwojem oprogramowania w stylu Kanban rosło, kilku pionierów poświęciło się szerzeniu wiedzy o tej metodzie i kształtowaniu jej przyszłości.

• Mary i Tom Poppendieck
  Byli jednymi z pierwszych osób, które przyjęły i rozpowszechniły wiedzę o zastosowaniu koncepcji Systemu Produkcyjnego Toyota do tworzenia oprogramowania i szerzej, do pracy z wiedzą. Przemawiali na licznych konferencjach i publikowali książki na tematy leżące u podstaw Kanbana, tj. mapowanie strumienia wartości, teoria kolejkowania i wizualna przestrzeń robocza.

• Microsoft
  Pierwsze próby wprowadzenia zasad Kanban do tworzenia oprogramowania zostały prawdopodobnie podjęte przez pracowników Microsoft. Dla poprawy produktywności, zespoły programistyczne zaczęły włączać elementy Scrum i Kanban do istniejących modelów “Feature Crew” i “Bug Jail”. W 2004 roku zaowocowało to pierwszym udanym projektem Scrumban.

• David Anderson, Dominica DeGrandis, Corey Ladas i Daniel Vacanti
  W 2005 roku David Anderson pracował w zespole Microsoft XIT Sustained Engineering nad wdrożeniem opisanego w jego książce systemu drum-buffer-rope. W 2007 roku przeniósł się do firmy Corbis z misją ulepszenia i poprawy produktywności ich inżynierii. Tam, wraz z Dominicą DeGrandis, wprowadził system Kanban do przetwarzania żądań zmian. Uwolniło to zespół od ograniczonych czasowo iteracji, pozwoliło zredukować pracę w toku i zrównoważyć wydajność względem popytu. Wiosną 2007 r., Corey Ladas dołączył do Corbis, uruchamiając drugi kanbanowy projekt. Precyzyjnie rzecz ujmując, był to proces Scrumban, zaprojektowany by służyć rozwojowi produktu, nie tylko jego utrzymaniu. Latem 2007 roku do Corbis dołączył Daniel Vacanti i wraz z Corey Ladas rozpoczął prace nad trzecim dużym projektem Kanban, którego celem było zademonstrowanie Kanbana w skali. Podczas tego projektu pojawiła się koncepcja horyzontalnych wierszy na tablicach, wiążących zazębiające się między sobą elementy pracy. W sierpniu, na konferencji Agile 2007, Anderson poprowadził otwarte spotkanie, opowiadając o pomyślnym wdrożeniu Kanban w Corbis, które to wywołało początkowe zainteresowanie tablicami i metodą Kanban.

• Karl Scotland
  Karl Scotland zetknął się z metodą Kanban na konferencji Agile 2007. We wrześniu tego samego roku, jako manager projektu Yahoo! Engineering, Scotland przedstawił swojemu zespołowi metodę Kanban jako rozwiązanie uciążliwie długich Sprintów w metodzie Scrum. Ich zastosowanie odniosło wielki sukces, a Scotland stał się jednym z pierwszych i najlepiej znanych orędowników metody Kanban.

Wszystkie te początkowe sukcesy z Kanbanem poszerzyły grono osób nim zainteresowanych.

W 2008 roku utworzono grupę Yahoo! o nazwie kanbandev. Zapewniała ona pole do dyskusji i dzielenia się wiedzą na temat wykorzystania wirtualnych systemów Kanban w tworzeniu oprogramowania, w krótkim czasie rozrastając się do ponad 1000 członków. Do pionierów grupy, grających wybitne role w procesie popularyzacji metody, należeli: Aaron Sanders, Alan Shalloway, Alisson Vale, Allan Kelly, Chris Shinkle, Corey Ladas, David Joyce, David Laribee, Derick Bailey, Eric Landes, Jeff Patton, Joe Arnold, Karl Scotland, Linda Cook, Matt Wynne, Mattias Skarin i Rob Hathaway.

2009: Kanban nabiera tempa

Prawdziwie złotym rokiem dla Kanbana okazał się 2009.

W styczniu 2009 r., czerpiąc ze swojego doświadczenia w Corbis, Corey Ladas opublikował książkę “Scrumban: Essays on Kanban Systems for Lean Software Development”, w której podjął próbę połączenia Scrum, Lean i Kanban.

Około kwietnia 2009 r. Henrik Kniberg opublikował “Kanban vs. Scrum – a practical guide”. Artykuł w zrozumiały sposób omówił podstawowe zasady Kanban. Dla wielu osób było to miejsce, w którym po raz pierwszy dowiedzieli się o metodzie Kanban.

W maju David Anderson zorganizował konferencję Lean Kanban 2009. Podczas wydarzenia w Mandarin Oriental Hotel w Miami omawiano najnowsze osiągnięcia w zastosowaniu metodyki Lean w tworzeniu oprogramowania.

Po konferencji narodziło się nieformalne stowarzyszenie Limited WIP, którego misją było ujednolicenie i szerzenie wiedzy o metodzie Kanban. Stowarzyszenie zapewniło platformę do agregacji artykułów na temat Kanban, pomagając szerzyć świadomości tej metody.

Latem 2009 roku Jim Benson zaczął publikować artykuły o Osobistym Kanbanie. Wpisy skupiały się na zastosowaniu zasad Kanban do organizacji życia osobistego, co wkrótce stało się samodzielną metodą.

Również w 2009 roku pojawiły się na rynku pierwsze aplikacje webowe do zarządzania projektami i procesami biznesowymi za pomocą metody Kanban, dające podstawy do przyjęcia zasad Kanban poza samą branżą programistyczną. Były to: Agile Zen, Kanban Tool i LeanKit Kanban.

Wczesna wersja aplikacji Kanban Tool, źródło: kanbantool.com

Po roku 2010: Kanban dla każdego

Wraz z wzrostem wiedzy o zastosowaniach Kanban, stało się jasne, że metoda ta sprawdza się nie tylko w tworzeniu oprogramowania, ale w zasadzie w każdym powtarzalnym procesie. Produkcja, sprzedaż, marketing, rekrutacja – każdy proces może skorzystać na Kanbanie. Nawet armia amerykańska była chętna do przyjęcia zasad tej metody. Podczas gdy pojawiało się coraz więcej historii o sukcesach w stosowaniu Kanban, stało się jasne, że należałoby jasno zdefiniować jej podstawowe zasady.

W marcu 2010 roku Henrik Kniberg i Mattias Skarin opublikowali bezpłatną mini książkę “Kanban i Scrum – jak uzyskać najlepsze z obu”, która została przetłumaczona na 14 języków.

W kwietniu 2010 roku David Anderson wydał “Kanban: Successful Evolutionary Change for Your Technology Business”. Mimo, iż skoncentrowana na firmach technologicznych, książka zawarła ogólne wskazówki dotyczące wdrażania i stosowania Kanban.

W 2011 roku Jim Benson i Tonianne DeMaria Barry opublikowali “Personal Kanban”, pokazując, że Kanban może być również z powodzeniem stosowany w przestrzeni osobistej.

Zaczęło pojawiać się też wiele innych książek i artykułów online na temat Kanban, dokumentujących indywidualne doświadczenia z metodą i jej różnymi zastosowaniami.

W końcu w 2016 r. opublikowana została książka “Essential Kanban Condensed” definiująca pięć zasadniczych praktyk metody Kanban:

• Wizualizuj przepływ pracy
• Ogranicz pracę w toku
• Monitoruj i zarządzaj przepływem
• Jasno określ zasady procesu
• Użyj modeli, aby rozpoznać możliwości doskonalenia procesu.

Zespoły nie wdrażające powyższych praktyk wykorzystują zaledwie tablicę Kanban, nie kompletny system Kanban.

By dowiedzieć się więcej o tym jak wykorzystać metodę Kanban w swojej pracy, zapoznaj się z następnym artykułem – Podstawy Kanbana.