Tym razem chciałbym opowiedzieć Wam fascynującą i inspirującą historię powstania Agile, Lean i całego nowego ruchu zarządzania projektami czy budowania startupów.
Historia ta rozciąga się na przestrzeni ostatnich 100 lat!
Dzięki niej zrozumiecie dlaczego ten wycinek świata wygląda dziś tak, a nie inaczej. Czemu właśnie tak buduje się teraz oprogramowanie, samochody, firmy czy zarządza projektami.
Spis treści
Wstęp
Scrum czy ogólniej metodyki zwinne (Agile) oraz szczupłe (Lean) stają się dzisiaj jednymi z najpopularniejszych metod budowania oprogramowania, firm czy zarządzania różnymi projektami. Podejście to przenika do coraz większej liczby dziedzin od edukacji, projekty rządowe nie związane z oprogramowaniem aż po tak egzotyczne wyzwania jak radzenie sobie z biedą. Sporo osób Agile czy Lean nazywa nową filozofią. Dla mnie są oznaką zdrowego rozsądku. Poprawiają skuteczność, produktywność i ograniczają marnotrawstwo. Przypominają, że rzeczywistość wokół nas się zmienia. Trzeba ją obserwować, uczyć się na błędach i adaptować (reagowanie na zmiany od realizacji założonego planu). W centrum stawiają ludzi, a nie procesy (ludzie i interakcje nad procesami i narzędziami).
Agile i Lean są odpowiedzią na problemy jakie pojawiały się przy zarządzaniu projektami w poprzednim stuleciu. Poniższy diagram obrazuje ostatnie kilkadziesiąt lat. Zmiany zaczęły się jednak dużo wcześniej!
Mistrzowie i czeladnicy czyli co zgubiliśmy
Dawniej przed rewolucją przemysłową gdy nie było jeszcze automatyzacji i masowej produkcji nad każdym elementem procesu twórczego czuwał „mistrz”. Taki rodzaj produkcji charakteryzował się nie tylko tym, że każdy produkt był niepowtarzalny. Mistrz naturalnie poprawiał swój fach. Dążył do tego aby jego produkt stawał się coraz lepszy. Co najważniejsze robił to na każdym etapie produkcji podczas normalnej pracy. Mistrz dążył do doskonałości. Miał też pod sobą czeladników, którzy pomagając mu przez wiele lat uczyli się od niego fachu. Tak wyglądał obraz dawnego rzemiosła i produkcji w dużym uproszczeniu.
Potem przyszła rewolucja przemysłowa. Na przestrzeni dziesiątek lat produkcja masowa, automatyzacja i dążenie do zysku zabiło to “ludzkie” podejście. Pojawiły się taśmy produkcyjne. Człowiek został sprowadzony do roli wykonawcy określonej czynności. Zadania wymagające myślenia przypisywane były menedżerom, których uwolniono od ciężkiej harówki przy wykonywaniu monotonnej pracy. Niestety przy przejściu z jednego systemu do drugiego coś zgubiliśmy. Czeladnicy przestali pracować bezpośrednio ze swoimi mistrzami. Mistrz przestawał kontrolować cały proces produkcji.
Tak w XX wieku narodziły się „patologie” w zarządzaniu projektami.
Model kaskadowy czyli mistrzowie i czeladnicy w XX wieku
Automatyzacja i rewolucja przemysłowa spowodowała, że świat w zastraszającym tempie przyspieszył. Stał się dużo bardziej skomplikowany. Zaczęły pojawiać się złożone produkty jak samochody czy oprogramowanie. Odległość między mistrzami, a czeladnikami zaczęła rosnąć. Pojawiły się formalne procesy (np. model kaskadowy) oraz hierarchie (np. wyższe kierownictwo).
Jednym z tych bardziej znanych formalnych procesów był “model kaskadowy”. Podejście to stało się dominującym sposobem realizacji tych złożonych projektów praktycznie przez cały XX wiek. Model kaskadowy jest w pewnym sensie odzwierciedleniem pierwszych taśm produkcyjnych. Kolejne zdarzenia następują kolejno po sobie i co najważniejsze (i najgorsze jednocześnie) jakość kontrolowana jest na samym końcu gdy produkt jest gotowy i.. koszty poprawek są największe.
Model kaskadowy (błędnie) zakładał, że pracę da się z góry z dużym prawdopodobieństwem przewidzieć. Pojawiała się potrzeba, powstawał plan (tworzony przez “mistrzów”), następnie przystępowano do realizacji planu (przez “czeladników”). Cały proces kończył się sprawdzaniem jakości gotowego produktu i wdrożeniem. Była jedna duża iteracja. Działania i kolejne etapy następowały liniowo jeden po drugim. Model zakładał, że rzeczywistość czyli wymagania się nie zmieniają. Kierownictwo oczekiwało kontroli i przewidywalności więc dostali ją w patologicznej formie. Klienci byli pozbawiani głosu po rozpoczęciu prac czy zakończeniu projektu.
Model ten okazywał się nieskuteczny. Rzeczywistość zawsze okazywała się inna niż planowano. Ludzie nie są dobrzy w przewidywaniu przyszłości czyli planowaniu i szacowaniu zadań. Rozdzielenie przysłowiowych mistrzów od czeladników czyli rozdzielenie procesu planowania od produkcji również okazało się kiepskim pomysłem. Poniższa historia pokazuje jak Agile i Lean stało się próbą powrotu z tej ślepej uliczki.
Ojciec produkcji masowej (Henry Ford, 1903)
Tej postaci przedstawiać nie trzeba. Henry Ford był amerykańskim przemysłowcem, który w 1903 roku założył w Detroit firmę Ford Motor Company.
Zrewolucjonizował system produkcji aut, wprowadzając produkcję masową. Opierał ją o ruchomą taśmę produkcyjną (wcześniej pojazdy stały w miejscu co było mało efektywne) oraz na daleko idącym podziale pracy. Tak daleko, że każdy pracownik wykonywał pracę, której nie dało się już bardziej podzielić. Dzięki temu nie potrzebował wysoko wykwalifikowanych pracowników. Każdy mógł nauczyć się danego zadania w kilka godzin. Oczywiście Fordowi zależało na większej wydajności. Drugim elementem rewolucji Forda były wysokie płace sięgające około 150% ówczesnej płacy rynkowej (czyli jakieś 7 dolarów na dzień). Trzecim elementem była prostota i minimalizacja kadry kierowniczej. W zakładach Forda nie było hierarchii i praktycznie byle robotnik miał kontakt z szefem.
W efekcie tych rewolucyjnych jak na ówczesne czasy zmian Ford szybko pokonał konkurencję. W 1907 roku wprowadził “Forda T” ograniczając produkcję do jednego tylko modelu i jednego koloru (czarnego). Dzięki temu maksymalnie zredukował cenę. Uczynił auto dostępne dla amerykańskich robotników. Do zakończenia produkcji w 1927 wyprodukowano w sumie ponad 15 milionów Fordów T. Powszechna dostępność aut Forda zrewolucjonizowała przy okazji kilka innych obszarów. Ekonomię gdyż pojawiły się kredyty na auta czy układ miasta gdyż ludzie zaczęli zasiedlać przedmieścia.
Ford T i Henry Ford. Źródło: http://media.ford.com
Czemu wspominam akurat o Fordzie?
Nie miał on przecież bezpośredniego wpływu na rozwój Agile czy Lean. Oczywiście, że nie. Ford stał się jednym z najbogatszych ludzi na świecie. Rewolucja jaką wywołał w branży motoryzacynej zainspirowała kilka lat później Toyotę (a konkretnie Kiichiro Toyoda) do zajęcia się właśnie produkcją samochodów. Ta jedna decyzja będzie miała ogromny wpływ na to co nazywamy dzisiaj Agile i Lean. O tym później. Podsumowując być może gdyby nie sukces Forda i inspiracja jaką stał się dla setek przedsiębiorców wliczając Kiichiro Toyodę znane nam dzisiaj metody mogłyby nigdy nie powstać.
Ojciec statystycznej kontroli jakości (Walter Shewhart, 1931)
Shewhart był jednym z prekursorów jakości. W tamtych czasach jakość w przemyśle nie istniała! Sprowadzała się do sprawdzania już gotowych elementów i usuwania tych wadliwych. Wszystkie błędy były poprawiane przez inspektorów jakości stojących na przykład na końcu taśmy produkcyjnej. Nie było jeszcze procesów dbających o jakość już na etapie produkcji.
Shewhart pracował w kultowym Bell Labolatories. Opracował prosty diagram, który dzisiaj znamy jako “karta kontrolna”. Ten diagram i krótki tekst przedstawiał wszystkie podstawowe zasady i czynniki które są zaangażowane w to co dzisiaj znamy jako “proces kontroli jakości” (stąd ojciec statystycznej kontroli jakości).
Czemu o nim wspominam?
Shewhart kilka lat pracował w Bell z niejakim Edwardem Demingiem, który ponad 20 lat później będzie szkolił Japońskich inżynierów na temat jakości. Wśród nich będą inżynierowie ze wspomnianej już Toyoty, którzy zrewolucjonizują potem podejście do jakości przy taśmie produkcyjnej. Już teraz zwróć też uwagę, że retrospektywy w Scrumowych sprintach to nic innego jak próba „ciągłej poprawy jakości pracy swojej i zespołu” (a więc to ta sama dziedzina jaką zajmował się Shewhart – kontrola jakości).
Podwaliny pod System Produkcyjny Toyoty i Lean Production (1929)
Na początku 1900 roku Toyota działała jeszcze w branży tekstylnej. Jej założycielem był Sakichi Toyoda. Wynalazł on krosna z napędem silnikowym oraz mechanizm automatycznego zatrzymania krosna w przypadku zerwania się nici.
Jak to się stało, że Toyota zajęła się samochodami? Wspominałem już o tym przy Fordzie. Syn założyciela Kiichiro Toyoda za namową ojca w 1929 roku wyjechał do USA aby zwiedzać tamtejsze fabryki (pod pretekstem wizyt handlowych). Zainspirowany tym co zobaczył oraz karierą Henry’ego Forda, który w ciągu kilkunastu lat stał się najbogatszym człowiekiem świata zdecydował się ostatecznie w 1930 na przekwalifikowanie Toyota Group na przemysł samochodowy. Warto zaznaczyć tylko, że w tamtych czasach rynek samochodów w Japonii praktycznie nie istniał. Dzisiaj nazwalibyśmy to więc prawdziwą innowacją!
Tak narodziła się Toyota jaką znamy dzisiaj. W ciągu następnych kilkudziesięciu lat Toyota wypracuje swój unikalny i jak się okaże rewolucyjny system produkcji (Toyota Production System = TPS). System ciągłego doskonalenia ludzi, procesów i produktów na każdym etapie produkcji. Toyota podobnie jak wcześniej Ford stanie się inspiracją dla tysięcy firm! Będzie też najważniejszym czynnikiem powstania Agile, Lean i nowego sposobu myślenia o zarządzaniu projektami.
Amerykanin uczy Japończyków i Cykl Deminga (Edward Demin, 1950)
Jak wspomniałem wcześniej Deming pracował kilka lat w Bell Labolatories z Shewhartem, który jest uważany za ojca statystycznej kontroli jakości. Podobnie jak on zajmował się jakością. Zasłynął z opracowania cyklu “Planuj, Wykonuj, Sprawdzaj i działaj” (PDCS = Plan, Do, Check, Act). Ilustrował on podstawową zasadę ciągłego ulepszania (Kaizen). Cykl ten można zastosować do dowolnego rodzaju produkcji. Jak pewnie zauważycie bardzo przypomina sprint w Scrumie (planowanie sprintu, development, prezentacja produktu i retrospektywa). Dzisiaj cykl ten jest znany jako “Cykl Deminga”. Rzeczywiście jest swoistym protoplastą sprintu i ciągłego uczenia się!
Źródło: Wikipedia
W 1947 roku po zakończeniu II wojny światowej Deming wyjechał do Japonii. W czasie tej powojennej odbudowy Ameryka okupowała Japonię. Deming był pierwszym amerykańskim specjalistą przekazującym w sposób metodyczny wiedzę japońskim inżynierom i managerom na temat cyklu PDCA. Jego podstawowym pomysłem było mierzenie jakości produktu i tego co zostało wykonane jeszcze w trakcie produkcji. Miało prowadzić to do “ciągłej poprawy”. Jest uważany za “guru jakości” ponieważ jako jeden z pierwszych w latach 50, zaproponował nowoczesne podejście do jakości produktów wykorzystujące zarządzanie personelem, planowanie, projektowanie wyrobów i monitorowanie procesów.
Czemu wspominam o Demingu?
Pamiętajcie, że w tamtych czasach nikt nie myślał jeszcze o kontrolowaniu jakości w tak „zwinny sposób” czyli jeszcze na etapie produkcji. Kontrola jakości sprowadzała się wtedy do sprawdzania gotowych produktów (czyli to tak jakbyśmy testy oprogramowania zaczęli dopiero po oddaniu go w ręce klientów!). Prace Deminga były więc rewolucyjne. Co więcej Deming miał ogromny wpływ na japońską gospodarkę. Japończycy, którzy stworzyli potem Toyota Production System opierali się w głównej mierze właśnie na jego Cyklu (Deminga). Czyli na idei ciągłego obserwowania produkcji i ciągłego wprowadzania drobnych usprawnień. Dokładnie tak jak dziś robimy to w zespole Scrumowym w kolejnych sprintach.
Inny Amerykanin uczy Japończyków – Quality Control Handbook (Joseph Juran, 1952)
Drugim człowiekiem o którym warto wspomnieć obok Deminga był Joseph M. Juran. Miał okazję uczestniczyć w pracach Shewharta gdzie zdobył doświadczenie w statystycznej kontroli jakości. Pracował w przemyśle m.in. w takich firmach jak Bell Labs i AT&T oraz nauczał na Uniwersytecie w Nowym Yorku o kontroli jakości.
Juran podobnie jak Deming również wyjechał do Japonii aby nauczać japońskich inżynierów. Stało się to jednak w bardzo ciekawy sposób. W 1951 opublikował w USA Quality Control Handbook. Publikacja została zauważona przez Japońską Unię Naukowców i Inżynierów (JUSE = Japanese Union of Scientists and Engineers) i Juran został zaproszony w 1952 roku do Japonii na wygłoszenie serii wykładów. Przybył ostatecznie w 1954 roku. Jego wykłady okazały się dużym sukcesem i Juran pozostał w Japonii, gdzie popularyzował idee jakości. Jednym z jego pomysłów było prowadzenie audycji radiowych poświęconych jakości.
Prace Deminga i Jurana (oraz wielu innych o których historia nie wspomina) w Japonii przynosiły namacalne efekty. Po zakończeniu II wojny światowej Japonia była pod okupacją amerykańską. Nowo podpisana konstytucja była antymilitarystyczna i de facto zakazywała Japonii tworzenia sił zbrojnych. Japonia została tym samym zmuszona do zmiany swojej gospodarki. I to się rzeczywiście udało! Po wojnie Japonia słynęła z niezwykle słabej jakości produktów. Natomiast już w 1970 Japonia i jej produkty zaczynały być postrzeganie jako te o najwyższej jakości. Co ciekawe, w tym samym okresie Ameryka była niezwykle oporna na swoje własne nauki, które dawała Japończykom (rękami Deminga, Jurana i innych). „Myślenie odwrotne” jak nazywane jest czasem Agile czy Lean od początku nie było głównym nurtem. W Ameryce królowało tradycyjne podejście do zarządzania czy produkcji (kaskadowe i systemowe czyli oderwane od ludzi).
Toyota Production System (1956 – 1980)
Doszliśmy do najważniejszego momentu w historii powstania Agile i Lean czyli narodzin Systemu Produkcyjnego Toyoty (TPS). W mojej ocenie nie da się tak naprawdę zrozumieć ducha Agile czy Lean bez poznania podstaw TPS, historii Toyoty i co najważniejsze motywacji jakie za stały z TPS.
Jeśli otworzycie wikipedię lub poszukacie w googlach o TPS dostaniecie sporo suchej teorii, którą ciężko sobie wyobrazić i zrozumieć (jak na obrazku poniżej).
Dom Toyoty czyli główne zasady TPS. Źródło: wikipedia
Spróbuję więc pokrótce wyjaśnić czym jest TPS od strony praktycznej i czemu była to taka rewolucja.
Dlaczego powstał TPS?
Na początek przypomnijcie sobie jak wyglądała produkcja samochodów od czasów Forda przez następne 50 lat. W dużym skrócie była taśma produkcyjna po której przesuwały się samochody, pracownicy sprowadzeni do roli robotników wykonywali bezmyślnie małe powtarzalne czynności. Nie było kontroli jakości. Wady wyłapywano gdy samochód był już gotowy. Tak w dużym uproszczeniu można podsumować pierwsze 50 lat produkcji samochodów.
Toyota zaczęła dostrzegać problemy z takim podejściem. Dlaczego nie kontrolować jakości produkcji jeszcze w trakcie produkcji zamiast czekać do samego końca? Dlaczego z pracowników robi się bezmyślnych robotników skoro to oni najlepiej znają techniczne “bebechy” produkcji i mogą usprawniać swoją pracę. Tak Toyota doszła do swoich rewolucyjnych metod zarządzania zwanych dzisiaj Toyota Production System. W dużym skrócie jest to dążenie do doskonałości procesów i ludzi
Ciągłe doskonalenie ludzi czyli czym jest TPS?
Zamiast biurokracji przymusu Toyota wprowadzała jak to niektórzy nazywają biurokrację możliwości. Każdego pracownika organizacji włączyła do rozwiązywania problemów, poprawy jakości, bezpieczeństwa oraz zmniejszania kosztów na każdym etapie produkcji. Każdemu w organizacji przyświeca jeden cel. Ciągłe dążenie do doskonałości przez eliminację marnotrawstwa i ciągłą naukę. Stąd też często mówi się o TPS jako systemie ludzi myślących (z ang. Thinking People System).
Toyota wyszła ze (słusznego) założenia, że ludzie chcą pracować dobrze. Chcą się uczyć i rozwijać. Tego typu zaufanie powinno być podstawą w każdej firmie. Do ciągłej nauki używała wspomnianego wcześniej cyklu PDCA (cyklu Deminga). Cykl PDCA to swoisty sprint podczas, którego nie tylko pracujemy ale na koniec wyciągamy wnioski, uczymy się czegoś i wprowadzamy drobne usprawnienia. PDCA to sposób myślenia i uczenia się.
Dążenie do nauki ma w Toyocie odzwierciedlenie praktyczne. Przykładowo mistrz (czyli osoba z wieloletnim doświadczeniem w Toyocie zwana sensei) może rozwiązać większość problemów dużo sprawniej niż czeladnicy (robotnicy i kierownicy niższego szczebla). Mimo wszystko pod okiem mistrza zostawia się te problemy właśnie im aby pojawiła się okazja do nauki. Większość firm nie ma wystarczająco dużo “cierpliwości” do takiego podejścia. Rolą kierownictwa (liderów) powinno być zaszczepianie w pracownikach chęci do rozwiązywania problemów, nauki i tym samym do ciągłego doskonalenia.
Ciągłe doskonalenie procesów czyli czym jest TPS?
Drugim elementem TPS obok ludzi są procesy. Jeśli chodzi o doskonalenie procesów to fundamentalnym elementem jest ograniczanie marnotrawstwa. Objawiało się to na przykład dążeniem do braku zapasów (Just-In-Time) przez odpowiednią modyfikację procesu. Innym elementem było rozwiązywanie problemów u źródeł i w momencie ich wystąpienia. W praktyce każdy pracownik w fabryce mógł wstrzymać całą linię produkcyjną gdy dostrzegł jakiś problem (Jidoka). Jest to też świetny sposób na uwidocznienie problemów. Toyota dostrzegła też, że ciągłe doskonalenie nie może się odbywać bez pobrudzenia sobie rąk właśnie w miejscu wystąpienia problemu (co w przypadku Toyoty oznaczało fabrykę). Zasada Genchi genbutsu mówiła „idź i przekonaj się sam”. Toyota bardzo mocno stawiała też na „zarządzanie wizualne”. Jednym z ciekawszych „wynalazków” był system kanban (protoplasta obecnie znanego nam systemu Kanban), który przekazywał informacje w ramach i między procesami na “kartach poleceń”.
Tablica kanban w fabryce Toyoty. Źródło: http://www.toyota-global.com
Linia produkcyjna. Źródło: http://www.toyota-global.com
O co naprawdę chodziło Toyocie?
W każdej firmie mamy więc ludzi i procesy. Tak naprawdę w Toyocie poprawa jakości procesów była tylko pretekstem i okazją do nauki i doskonalenia ludzi (pracowników). Doskonaląc procesy Toyota rozwijała wybitnych myślących ludzi. Toyota zrozumiała coś co można nazwać “prawem systemów produkcyjnych”. Produkcja masowa to stan naturalny. Aby ten naturalny stan poprawiać i usprawniać trzeba nieustannie dostarczać zewnętrznej energii. Tą energią są właśnie myślący ludzie. Co więcej ten naturalny stan ciągle dąży do entropi czyli do chaosu (przykładowo zostawcie swój zespół bez lidera na kilka tygodni, a zobaczycie czym to się skończy). Ludzie muszą więc nieustannie dostarczać energii. Chwasty odrastają, a my musimy je ponownie wyrywać.
Oczywiście wszystko to jest procesem długofalowym, wymagającym czasu i cierpliwości. Inwestycja w ludzi jest inwestycją długofalową nie nastawioną na szybkie zyski. Toyocie chodziło o coś więcej. Chodziło o zmianę sposobu myślenia. Wbudowanie w kulturę firmy ciągłej nauki i szacunku do ludzi. Mówiąc “najpierw tworzymy ludzi, a potem samochody” chodziło o podkreślenie wagi ludzkich zdolności.
Jak na tamte czasy podejście było rewolucyjne. Dziś takim zachowaniem określamy prawdziwych liderów!
Co TPS dało Toyocie?
Ostatecznie Toyota dzięki swoim ideałom z małej firmy wyrosła na jedną największych firm świata. Sukces Toyoty stał się inspiracją dla tysięcy organizacji, które postanowiły wdrożyć potem pewien rodzaj ich sposobu działania. Można śmiało powiedzieć, że Toyota zmieniła świat podobnie jak uczynił to Ford kilkadziesiąt lat później.
Kto stoi za stworzeniem TPS?
Za ojca TPS uważany jest Taiichi Ōno. Podjął on pracę w Toyocie w 1943. W 1954 awansował na stanowisko dyrektora, w 1970 dyrektora wykonawczego, a w 1975 − wiceprezesa firmy. Ōno dużo pracował nad udoskonaleniem Systemu Produkcyjnego Toyoty. Porównywał go do amerykańskiego supermarketu samoobsługowego. W 1956 podczas wizyty w Stanach Zjednoczonych zainspirował się właśnie samoobsługowymi supermaketami (w Japonii ich jeszcze nie było). Konkretnie chodziło o całkowitą swobodę z jaką klienci mają podczas wybierania i kupowania towarów (stąd jednym z elementów TPS jest tzw. „system ssący” gdzie nie ma zapasów tylko towary do produkcji są uzupełniane na bieżąco – ograniczanie marnotrawstwa).
Taiichi Ōno w fabryce Toyoty. Źródło: http://www.toyota-global.com
Co na to inne firmy?
W latach 60. i 70. rozwiązania opracowane przez Toyotę zaczęły być kopiowane przez innych japońskich producentów aut takich jak Hino Motors, Daihatsu, Mazda i Nissan.
Ameryka jednak znów niejako przespała całą Japońską rewolucję 🙂
Przez długie lata TPS nie był zauważony poza Japonią. Nie był też przez długi czas formalnie dokumentowany. Pierwszy artykuł o TPS w języku angielskim ukazał się dopiero w 1977 roku. Został napisany przez czterech managerów Toyoty. Porównali oni w nim wydajność jednej z fabryk Toyoty z wydajnością w trzech innych fabrykach w USA, Szwecji i Niemczech. Wydajność w Toyocie była najwyższa! I to mimo tego, że podejście Toyoty (np. z dawaniem każdemu pracownikowi możliwości zatrzymania całej (sic!) linii produkcyjnej) kłóciło się z powszechnym wtedy dążeniem do masowej produkcji i zwiększania wydajności.
Jak to się ma do Agile, Scruma czy Lean?
Jeśli miałeś okazję liznąć Agile czy Scruma to już na pierwszy rzut oka poczujesz tam ducha TPS:
- Toyota dążyła do ciągłej poprawy jakości tak samo jak robi to obecnie każdy zespół Scrumowy
- „Ludzie i interakcje przed procesami i narzędziami” (rzuć okiem na Manifest Agile) dokładnie tak jak Toyota stawiała w pierwszej kolejności na (samodzielnie myślących) ludzi.
- „Reagowanie na zmiany przed realizacją założonego planu” dokładnie tak jak Toyota stawiała na reagowanie (adaptowanie się) na zmiany dzięki stosowaniu cyklu PDCA (wykonaj, sprawdź, popraw, zaplanuj).
- Zaufanie i szacunek do ludzi jest dzisiaj podstawą dobrych zespołów. Tak samo było w Toyocie.
- Sprint Scrumowy to rodzaj cyklu Deminga czyli akceptacja tego, że rzeczywistość się zmienia i trzeba się adaptować
- W Scrumie podobnie jak w Toyocie dąży się do jak największej wizualizacji procesów (Backlog, Kanban, Burn Down Chart itp.) tak aby ewentualne problemy były jak najszybciej widoczne.
- O Lean chyba nie muszę wspominać. „Szczupła” produkcja Just-In-Time i ograniczanie marnotrawstwa to nic innego jak Lean.
Dla mnie to niesamowite, że tak dużo elementów na przestrzeni dziesiątek lat przeniknęło do całkowicie nowych dziedzin.
Ojcowie chrześni Scruma – The New New Product Development Game (Hirotaka Takeuchi and Ikujiro Nonaka, 1986)
Wchodzimy powoli w historię najnowszą.
W 1986 roku w Harvard Business Review ukazał się artykuł “The New New Product Development Game” napisany przez dwóch japońskich profesorów Hirotaka Takeuchi i Ikujiro Nonaka. Przyjrzeli się oni kilku zespołom i projektom z najbardziej wydajnych światowych firm jak Honda, Fuji-Xerox, 3M, Hawlett-Packard i innych.
Udowadniali w nim, że stary sposób tworzenia nowych produktów (nie chodziło tylko o oprogramowanie) czyli wprowadzony przez NASA system kaskadowy był wadliwy.
Okazało się, że te najwydajniejsze zespoły wykorzystywały proces nakładających się czynności, który był szybszy i elastyczniejszy. Do tego zespoły były autonomiczne, uzupełniały się i samodzielnie podejmowały decyzje. Kierownictwo pełniło bardziej role służebną, niczego nie nakazywało tylko ułatwiało zadania i usuwało przeszkody. Japońscy profesorowie porównali te zespoły do drużyny rugby i stwierdzili, że najlepsze z nich pracowały jak rugbyści w młynie (ang. scrum)
Ten konkretny artykuł 7 lat później wpadł w ręce Jeffa Sutherlanda (współtwórcę Scruma) rodząc metodologię Scrum 🙂
Pierwsza strona ze wspomnianego artykułu (źródło: Harvard Business Review)
Narodziny szczupłego zarządzania – Lean Management (1990)
Opisany wyżej Produkcyjny System Toyoty nazywany jest często „produkcją szczupłą” (Lean Production) podkreślając, że chodzi o przemysł. Lean Management oznacza więc “szczupłe zarządzanie” czyli jest przeniesieniem koncepcji TPS z produkcji (przemysłu) do zarządzania.
Przełomowym wydarzeniem dla popularyzacji szczupłego zarządzania było opublikowanie w 1990 przez grupę badaczy związanych z Massachusetts Institute of Technology (MIT) Jamesa Womacka, Daniela Jonesa i Daniela Roosa książki The Machine That Changed the World (Maszyna, która zmieniła świat).
Powstała ona na podstawie gruntownych badań prowadzonych przez MIT pt. International Motor Vehicle Program od 1980 roku. IMVP jest największym w historii badaniem rynku samochodowego. Badanie trwa do dziś 🙂
We wspomnianej książce w dużym skrócie przedstawione są dwa fundamentalnie różne systemy biznesowe szczupły (lean) i masowy właśnie na przykładzie rynku samochodowego.
Okładka książki
Narodziny Scruma (Jeff Sutherland, 1993)
Jak pisałem wyżej dopiero po 7 latach w ręce Jeffa Sutherlanda wpadł artykuł z 1986 “The New New Product Development Game”. W 1986 artykuł ten narobił trochę szumu ale znów w USA (gdzie królowała metoda kaskadowa z planowaniem etapowym, wykresami gantta itp.) nie był on praktycznie wykorzystywany.
Jeff pracował w firmie Easel poszukując sposobu na organizację swojego zespołu. Mimo, że artykuł dotyczył produkcji, a nie tworzenia oprogramowania Jeff wraz zespołem postanowili skorzystać z nowej metody. Okazała się na tyle fascynująca, że poświęcił się całkowicie jej ulepszaniu. Tak formalnie narodziła się metoda Scrum.
Nie będę tutaj opowiadał jak działa Scrum gdyż na ten temat jest niezliczona liczba książek i artykułów. Powiem tylko, że jest to zwinna (adaptacyjna) metodyka zarządzania projektami. Tak samo jak w Toyocie istotą TPS był nowy sposób myślenia tak samo jest w Scrumie. Nie da się używać scruma nie zmieniając swojego podejścia na lekkie, zwinne, adaptacyjne czy iteracyjne. Generalnie Scrum ma swoje korzenie w myśleniu i postępowaniu Japończyków.
Obecnie Jeff nadal czynnie bierze udział w życiu Scruma. W 2006 założył firmę szkoleniową Scrum.inc. Możecie go oczywiście śledzić w social media.
Jeff Sutherland, Źródło: https://www.scruminc.com
Scrum. Źródło: wikipedia
Umiejętności Jeffa nie są niespodzianką 🙂 (źródło: LinkedIn)
Formalizacja Scruma (Ken Schwaber, 1995)
Scrum został sformalizowany jako metoda produkcji oprogramowania przez Kena Schwabera w 1995 roku. Jeff Sutherland wraz z Ken Schwaberem na konferencji Association for Computing Machinery (ACM) przedstawili artykuł “SCRUM Development Process”, w którym opisali nowy sposób budowy oprogramowania.
Opis Scruma ze wspomnianego artykułu
Powstanie Extreme Programming (Kent Beck, 1999)
Programowanie ekstremalne (XP) jest zwinną metodą programowania. XP korzysta z wielu różnych technik, które wspólnie dają solidną wartość. Do najważniejszych należy iteracyjność, testy jednostkowe, programowanie parami czy ciągły kontakt z klientem. Wspólnie ze Scrumem, XP jest kolejną cegiełką do wszystkiego co nazywamy Agile.
Pierwsze podsumowanie filozofii Toyoty – Droga Toyoty (2001)
Pamiętacie jak opowiadałem o Toyocie. Większość z ich metod przez dziesiątki lat nie była kompleksowo dokumentowana. Dopiero w 2001 Toyota po raz pierwszy podsumowała swoją filozofię i zasady w publikacji „The Toyota Way 2001”. W 2004 roku Jeffrey Liker jako pierwszy omówił te zasady w swojej książce „The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer”. Jest również wydanie polskie tej książki i zachęcam do poczytania.
Okładka ksiązki
Narodziny Agile – Manifest Agile (2001)
W okolicach 2000 roku zaczyna się boom na Agilę i Scrum. W 2001 r. w ośrodku wypoczynkowym Snowbird, w USA (stan Utah), zbiera się grupa zwolenników nowego podejścia do wytwarzania oprogramowania, które jest alternatywą dla tradycyjnego podejścia opartego na modelu kaskadowym. W efekcie zostaje opracowany tzw. Manifesto for Agile Software Development (z ang. Manifest zwinnego tworzenia oprogramowania), który stanowi deklarację podstawowych wartości i zasad agile. Pierwsza część manifestu to cztery krótkie stwierdzenia, które w sposób prosty i jasny oddają filozofię zwinności. Oczywiście za tymi czterema stwierdzeniami kryje się dużo dużo więcej (o czym czytasz w tym artykule).
Manifest Agile (źródło: http://agilemanifesto.org/iso/pl/)
Pierwsza książka o Scrum (2001)
W 2001 Ken Schwaber i Mike Beedle wydają pierwszą i obecnie kultową już książkę o Agile Software Development with Scrum 🙂
Lean Software Development (2003)
Jest to odchudzone wytwarzanie oprogramowania i jest adaptacją Systemu Produkcyjnego Toyoty dla środowiska informatycznego. Jak całe Lean skupia się na ograniczaniu marnotrawstwa. Metoda nie zyskała (jeszcze) takiej popularności jak Scrum czy Agile. Być może dlatego, że Agile, Scrum i XP dają już ogromną wartość i same w sobie adaptują w pewien sposób System Produkcyjny Toyoty.
W każdym razie za twórców tego pojęcia uważa się Mary Poppendieck i Toma Poppendiecka, którzy w książce „Lean Software Development: An Agile Toolkit” przedstawili m.in. 7 głównych zasad odchudzonego zarządzania i zestaw 22 technik wspierających podejście.
Szczupłe i zwinne budowanie firm – Customer Development (Steve Blank, 2003)
Steve Blank rozwinął koncepcję Customer Development, która stała się kamieniem węgielnym pod całą koncepcję i ruch Lean Startup. Chodzi o to, że przedsiębiorcy często są pod tak wielkim wrażeniem genialności swoich pomysłów, że myślą, że wystarczy zbudować produkt, a klienci przyjdą sami.
Founderzy skupiają się więc na budowaniu produktu (product development) zapominając o klientach (customer development). Nie rozmawiają z klientami i budują przez to produkty, których nikt nie potrzebuje. Robią product development przed customer developmentem.
Customer Development najprościej zrozumieć na przykładach:
1. Jeśli jesteś programistą i zakładasz firmę pierwszą rzeczą na jakiej powinieneś się skupić nie jest programowanie (product development) lecz weryfikacja czy to co chcesz budować będzie komuś potrzebne. Zweryfikować to możesz tylko próbując sprzedawać czyli rozmawiając, ze swoimi klientami (customer development). Pisałem o tym tutaj: http://www.marcinmuras.com/informatyczne-eldorado-czesc-4-10-porad-dla-programistow-zakladajacych-wlasny-startup/
2. Analogicznie jest z każdym innym podejście do budowania firmy. Pierwszą rzeczą powinna być weryfikacja pomysłu tak aby sprawdzić czy firma, która zamierzamy tworzyć rozwiązuje jakiś realny problem. Czyli czy to co zamierzasz robić jest komuś potrzebne. O tym pisałem tutaj: http://www.marcinmuras.com/60-najwazniejszych-lekcji-czyli-czego-nauczylem-sie-w-ostatnich-latach-budujac-firme/
Podsumowując Customer Development jest próbą zbalansowania product i customer developmentu podczas budowy startupu. Proponuje metodę poznawania klientów i opracowania rentownego modelu biznesowego (którego poszukiwanie jest długim procesem)
Kanban w wytwarzaniu oprogramowania (2010)
Kanban stosowany był już na początku lat 50-tych w Toyocie. Służył on jako „system ssący” dając sygnał kiedy należy uzupełnić zaopatrzenie na linii produkcyjnej (było to widać fizycznie na podstawie ilości kart na tablicy). Idea zaczerpnięta była z amerykańskich supermarketów gdzie klienci sami mogli brać z towary półek. Brak towarów był jasnym (fizycznie widocznym) sygnałem aby uzupełnić zapasy.
W wytwarzaniu oprogramowania idea Kanban pozostała nie zmieniona. Ma ona wizualizować kolejne etapy procesu wytwarzania oprogramowania oraz ograniczać ilość pracy „w toku”.
Tablicę Kanban przy wytwarzaniu oprogramowania po raz pierwszy przedstawił David J. Anderson w książce Kanban: Successful Evolutionary Change for Your Technology Business
Okładka książki
Przykład tablicy Kanban (źródło: https://www.atlassian.com)
Lean Startup (Eric Ries, 2011)
Jak wspomniałem wcześniej Lean Startup narodził się jako rozwinięcie koncepcji Customer Development i Toyota Production System (TPS). Jak pamiętacie Toyocie chodziło o ciągłą naukę przez cykle nauki. W Scrumie również chodzi o naukę i adaptację dzięki sprintom.
Lean Startup ma podobną koncepcję. Startup według Erica to organizacja stworzona w celu wykreowania nowego produktu lub usługi w otoczeniu wielkiej niepewności. Ta niepewność powoduje, że do momentu znalezienia rentownego modelu biznesowego najważniejszym procesem w firmie jest proces nauki (czyli jak najszybsze przechodzenie cyklów budowa, mierzenie wyników, nauka). Nauka ta nie może się jednak odbywać w oderwaniu od klientów czyli bez customer developmentu. Proces nauki bazuje jednak na metodach naukowych m.in. na mierzeniu odpowiednich wskaźników tak aby stale zmniejszać tą niepewność. Metodę Lean Startup miałem okazję stosować m.in. podczas rozwijania UpMenu 🙂
Zachęcam do przeczytania tej kultowej pozycji szczególnie jeśli planujesz własny biznes!
Okładka książki „Lean Startup”
Podsumowanie
Agile i Lean, które dzisiaj uważamy za rewolucyjne swoje korzenie mają w koncepcjach stworzonych przez Toyotę kilkadziesiąt lat wcześniej. Natomiast kamieniami węgielnymi pod koncepcje Toyoty miał Ford, Deming i prace nad kontrolą jakości 100 lat temu.
Agile i Lean jest odpowiedzią na błędy i problemy jakie w XX w. przyniosła nam rewolucja przemysłowa. Pod drodze na rzecz masowości i formalnych procesów zatraciliśmy ludzkie podejście do zarządzania projektami i produkcji. Agile i Lean próbuje te błędy naprawić.
Jednak jeśli przyjrzymy się tym koncepcjom głębiej to okażą się po prostu zdrowym rozsądkiem. To co dzisiaj nazywamy zwinnością (Agile) czy szczupłym podejściem (Lean) tak naprawdę czujemy gdzieś głęboko:
- Wiara i szacunek do ludzi
- Zaufanie do zespołu
- Autonomia i samoorganizacja
- Ciągła nauka i doskonalenie
- Wyciąganie wniosków i podejście adaptacyjne
- Ograniczanie marnotrawstwa i robienie tego co najważniejsze
To przecież cechy, które przypisujemy prawdziwym profesjonalistom i liderom!
Gdzieś po drodze przemysł i zespoły zgubiły te wartości. One są natomiast uniwersalne bez względu na to czy budujemy firmę, oprogramowanie, samochody czy cokolwiek innego. To wszystko musieliśmy po prostu odkryć na nowo.
