Metodologie tworzenia oprogramowania: Zasady Lean vs Agile

„Lean” i „Agile” to terminy, którymi ostatnio często się posługujemy, często w odniesieniu do metodologii tworzenia oprogramowania, zarządzania projektami lub stylów organizacyjnych.

Ale czy kiedykolwiek zastanawiałeś się:

Co to jest Lean? Co to jest Agile? Czy istnieje różnica?

Merriam-Webster Dictionary definiuje Agile jako „posiadający szybką zaradność i zdolność adaptacji, lub oznaczony przez gotowość do poruszania się z szybką łatwą gracją.”

Lean jest definiowany po prostu jako „szczupły i zdrowy, lub zawierający niewiele lub nie zawierający tłuszczu.”

Bazując na tych definicjach, możemy założyć, że ktoś, kto jest szczupły i ktoś, kto jest zwinny może mieć wiele wspólnych cech. To samo jest prawdą w kontekście rozwoju oprogramowania.

Co to jest Agile? Czym jest Lean?

Agile jest obecnie powszechnie znany w świecie technologii jako zestaw wartości i zasad, którymi należy się kierować przy tworzeniu oprogramowania. „The Agile Manifesto” przedstawia zestaw czterech wartości i 12 zasad. Wydestylowany do sedna, Agile jest dokładnie tym, czym myślisz, że może być. To jest Agile. Metodologia ta faworyzuje elastyczność, komunikację, współpracę i prostotę.

Lean jest mniej zrozumiała i brakuje jej jasnej definicji popartej profesjonalnym konsensusem. Termin „Lean” został pierwotnie ukuty w celu opisania modelu organizacji produkcji opartego na Systemie Produkcyjnym Toyoty, ale jest powszechnie uważany za podramę w ramach parasola Agile rozwoju oprogramowania.

Dzisiaj jest wiele zamieszania wokół tego, czym jest Lean, czym jest Agile, czy są one jednym i tym samym, i która z nich powinna być używana.

Narodziny nowych metodologii tworzenia oprogramowania

Zarówno Lean, jak i Agile zostały opracowane w odpowiedzi na niedociągnięcia istniejących metod opartych na planie, takich jak Waterfall. Stosowane od lat 70-tych, programiści i menedżerowie zajmujący się inżynierią oprogramowania zaczęli dostrzegać nieefektywność metody wodospadowej w latach 90-tych. Przy bardziej dynamicznych rynkach i zaawansowanych technologicznie konsumentach, Waterfall nie był w stanie wystarczająco szybko reagować na potrzeby rynku, zmieniającą się technologię lub dostarczać oprogramowania wolnego od błędów w sposób konsekwentny.

W pogoni za lepszym modelem, twórcy Lean i Agile starali się opracować metodologie z podejściem bardziej skoncentrowanym na kliencie. Nowe metodologie uwzględniały zdolność do adaptacji jako przewagę konkurencyjną, faworyzowały wczesne i ciągłe testowanie oraz wprowadziły element ludzki do zarządzania projektem i jego realizacji.

Zasady Lean vs. Agile

Lean Software Development (LSD) został po raz pierwszy zaproponowany przez dr. Roberta Charette’a jako sposób na budowanie organizacji odpornych na zmiany, które stawały się coraz bardziej zależne od oprogramowania.

Następnie pojawił się „Manifest Agile”, który zawierał 12 zasad Agile Software Development.

Inna autorytatywna praca na temat metodyk rozwoju oprogramowania należy do Mary i Toma Poppendieck, którzy opublikowali Lean Software Development: An Agile Toolkit.

Przedstawiamy porównanie wartości i zasad każdej z nich:

Porównując 12 zasad LSD dr Charette’a i 12 zasad Agile, można zauważyć, że są one uderzająco podobne. Siedem zasad Lean zaproponowanych przez Poppendiecków jest mniej ukierunkowanych, ale mimo to pokrywa się z „The Agile Manifesto” i Lean Software Development Charette’a.

Oto więcej elementów, które mają ze sobą wspólnego:

• Wartość szybkiego reagowania na potrzeby klienta
• Wczesne testowanie
• Iteracyjne podejście do rozwoju
• MVP (Minimum Viable Product) styl rozwoju nad feature heavy
• Współpraca zarówno wewnątrz firmy, jak i z zewnętrznymi interesariuszami

Oś czasu

Zbadaliśmy przełomowe wydarzenia i publikacje, które dały początek tym terminologiom, aby zobaczyć, jak stały się popularne. Zapoznaj się z naszą poniższą osią czasu przedstawiającą postęp i dodaj je do swojej listy lektur, jeśli masz taką ochotę!

Początki Lean i Agile

Jak widać na osi czasu, termin Lean został po raz pierwszy użyty przez Womack et. al. w 1990 r. do opisania Systemu Produkcyjnego Toyoty w ich książce The Machine That Changed The World. Dr Robert Charette później zaadaptował idee Lean opisane we wcześniejszych publikacjach, aby stworzyć „Lean Software Development”.

Termin Agile nie został powszechnie przyjęty do czasu opublikowania „The Agile Manifesto” w 2001 roku. Terminy Agile i Lean zostały stworzone przez zachodnich specjalistów z dziedziny technologii lub naukowców, którzy odnosili się do Systemu Produkcyjnego Toyoty (więcej na ten temat później).

Możemy złapać trochę flaków za mówienie o tym, ale mając to na uwadze, terminy Lean i Agile nie są w rzeczywistości tak ważne. Posiadanie dwóch terminów wywodzących się z tych samych zasad faktycznie przyczynia się do zamieszania w tym temacie. To powiedziawszy, jest to terminologia, którą przyjęła branża, więc idąc naprzód, będziemy nadal ich używać.

Okres czasu jest również kolejnym źródłem zamieszania. Dr Robert Charette przedstawił swoje pomysły na Lean Software Development na początku i w połowie lat 90-tych. Cel taktyczny i 12 zasad jego podejścia Lean Development zostały opisane w 1998 roku w artykule zatytułowanym „Lean Development”, prawie trzy lata przed „The Agile Manifesto”. Świadectwem nakładania się Lean i Agile jest fakt, że artykuł ten został napisany przez Jima Highsmitha, który później stał się jednym z głównych założycieli ruchu Agile. Jednakże artykuł Highsmitha nie był szeroko rozpowszechniony i dopiero w 2003 roku sam Charette napisał bardziej dogłębne wyjaśnienie swojego podejścia do szczupłego rozwoju w raporcie badawczym „Challenging the Fundamental Notions of Software Development.”

W wymianie e-maili z dr. Charette, szybko zaznaczył, że jego koncepcja szczupłego rozwoju była przeznaczona dla poziomu organizacyjnego w dziedzinie oprogramowania:

Moja zrodziła się ze strategicznej i operacyjnej potrzeby poprawy wartości biznesowej/misyjnej IT dla organizacji, a ja podszedłem do tego z perspektywy zarządzania ryzykiem.
-Dr Robert N. Charette

Różni się to nieco od Agile, który został po raz pierwszy zaproponowany jako „lepszy sposób tworzenia oprogramowania”, ale obecnie jest stosowany do różnych projektów i metod zarządzania.

2003 był również rokiem, w którym Poppendieckowie opublikowali Lean Software Development: An Agile Toolkit. Książka ta opisywała siedem zasad Lean Development, które bezpośrednio korelują z siedmioma formami marnotrawstwa w Lean Manufacturing.

Książka Poppendiecków jednocześnie wzmocniła Lean jako metodologię rozwoju oprogramowania i zatarła różnicę pomiędzy Lean i Agile, proponując Lean jako metodę uzupełniającą w ramach Agile. W rzeczywistości, w momencie wydania, książka była sprzedawana jako najnowsza publikacja w ramach The Agile Software Development Series.

Dzisiaj, liczne prace Poppendiecków na ten temat są uważane za niezbędną lekturę dla praktyków rozwoju oprogramowania Lean i „aspirujących do Lean”.

Różnice w zastosowaniu

Według dr Charette’a, jedną z podstawowych różnic pomiędzy Lean i Agile jest to, że Agile jest oddolne, podczas gdy Lean jest odgórne. Jest to widoczne w strukturze end-to-end (E2E) Lean oraz w zasadzie Zobacz Całość zaproponowanej przez Poppendiecków. Poniżej wyjaśniamy te zasady w praktyce mapowania strumienia wartości.

Mapowanie strumienia wartości

Aby zrealizować zasadę Zobacz całość, Poppendieckowie szczegółowo opisują metodę mapowania strumienia wartości w celu ujawnienia działań dodających wartość w stosunku do działań nie dodających wartości w całym procesie rozwoju end-to-end.

Mapowanie strumienia wartości analizuje cykl rozwoju od momentu otrzymania wymagania do momentu dostarczenia go do klienta. Celem jest zidentyfikowanie strat w postaci zalegających zapasów i oczekiwania (opóźnienia w produkcji), a także zbadanie nowych praktyk w celu zmniejszenia produkcji w toku (WIP) i czasu realizacji.

Według Poppendiecków, mapowanie strumienia wartości jest prostym ćwiczeniem, które wymaga jedynie ołówka i kartki papieru. Proces wygląda następująco:

1. Mapuj swój obecny strumień wartości (zaczynając od wymagania i osi czasu działań na drodze do dostawy)
2. Analizuj największą przyczynę marnotrawstwa (Co wstrzymuje Work-in-Progress?)
3. Opracuj plan, aby zmniejszyć to marnotrawstwo o połowę
4. Stwórz przyszłą mapę strumienia wartości

Paradygmat Agile określony w „The Agile Manifesto” faworyzuje krótkie cykle iteracji i częste dostawy w stosunku do holistycznego widoku end-to-end. Koncentracja na E2E jest zatem unikalna dla Lean. W rzeczywistości, to właśnie ze względu na konstrukcję E2E, Lean (a nie Agile) jest częściej stosowany jako struktura organizacyjna i styl zarządzania.

Pogląd end-to-end wymaga udziału całej organizacji w celu wyeliminowania marnotrawstwa. Jest to echo celu, jaki dr Charette wyznaczył dla swojej oryginalnej koncepcji Lean Development:

Lean Development to filozofia, sposób postrzegania i myślenia o IT i jego związku z organizacją, w takim samym stopniu jak podejście do rozwoju.

Lean Kanban Vs. Agile Kanban

Zarówno Lean, jak i Agile przyjęły system TPS Kanban z niewielkimi zmianami. System Kanban Toyoty został zaprojektowany w celu ograniczenia Work-in-Progress.

W przeciwieństwie do tradycyjnego „push manufacturing”, który przesuwa zapasy do następnego etapu procesu, Kanban wciąga nowy materiał do produkcji dopiero wtedy, gdy bieżący element został przetworzony i konieczne jest uzupełnienie komponentów.

Karty Kanban stają się zleceniami uzupełnienia zapasów i są odsyłane do poprzedniego etapu produkcji. W rezultacie minimalizuje się Work-in-Progress i redukuje bezczynność zapasów.

W rozwoju oprogramowania, zamiast przekazywania kart Kanban z jednego etapu produkcji do poprzedniego, używa się tablicy Kanban. Karteczki samoprzylepne są używane, najczęściej do reprezentowania wymagań w toku.

Zgodnie z rozdziałem autorstwa Kaia Petersena w Modern Software Engineering Concepts and Practices: Advanced Approaches, zarówno Agile, jak i Lean wykorzystują listę wymagań o ustalonym priorytecie, z której pobierane są zadania.

W przeciwieństwie do Agile, który wykorzystuje cykle iteracji o ustalonym czasie trwania, aby ograniczyć czas rozwoju i zarządzać tablicą Kanban, Lean ogranicza liczbę zadań dozwolonych w danym czasie. Dzięki temu Lean może spełnić swój podstawowy cel, jakim jest ograniczenie WIP, jednocześnie dokładniej mierząc czas realizacji i identyfikując marnotrawstwo w produkcji. Po zakończeniu zadania, nowe zadanie może zostać przeniesione z listy priorytetów. Podczas gdy Lean wykorzystuje koncepcję ciągłego przepływu, Agile rozpoczyna każdą nową iterację od nowej tablicy.

Niektóre zespoły dostrzegają korzyści płynące z obu podejść i zaczynają stosować metodę hybrydową, znaną jako scrumban.

To tylko dwie z subtelnych różnic w podejściu Lean i Agile do osiągania wspólnych celów. Inny artykuł opublikowany na Codementor omawia więcej zastosowań i aplikacji Lean i Agile.

W praktyce nie ma znaczenia, czy Twój zespół stosuje podejście tzw. To, co jest ważne, to znalezienie odpowiednich praktyk, aby zoptymalizować przepływ pracy i konsekwentnie dostarczać wartość klientom, co obie metodologie uważają za ostateczny cel.

The TPS Connection

Więc co to wszystko ma wspólnego z Toyota Production System? Prawie wszystko. Twórcy zarówno Agile jak i Lean byli pod silnym wpływem TPS, co opisują Womack et. al. w książce The Machine That Changed the World. To better understand the inspiration for Lean and Agile methodologies, we will take a look the manufacturing system developed in Japan between the 1950s-70s, specifically:

• Just-in-Time Manufacturing
• Jidoka (intelligent automation)
• Eight Forms of Waste
• TPS Values

Warning:

The rest of this article contains jargon that you can use to sound scholarly after reading.

Just-in-Time Manufacturing

Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. W tych warunkach Taiichi Ohno i Kiichiro Toyoda postanowili zachować rentowność, eliminując marnotrawstwo w produkcji, skracając czas realizacji zamówień i produkując tylko to, czego potrzebowali klienci, znane również jako produkcja Just-in-Time (JIT).

Aby wyeliminować marnotrawstwo, Ohno postanowił produkować tylko to, co było potrzebne, kiedy było potrzebne i tylko w takiej ilości, w jakiej było potrzebne.

Iteracyjny proces Lean i Agile, który koncentruje się na minimalizacji rozwoju funkcji i maksymalizacji dostarczania aktualizacji, bezpośrednio odzwierciedla produkcję Just-in-Time Toyoty.

Jidoka

Jidoka (自働化) można przetłumaczyć jako automatyzacja z ludzkim dotykiem, czasami określana jako „inteligentna automatyzacja”. Jidoka odgrywa ważną rolę w eliminowaniu marnotrawstwa w produkcji poprzez uczynienie maszyn bardziej niezależnymi, co uwalnia ludzi do odgrywania bardziej aktywnej roli w produkcji i uwalnia ludzką kreatywność.

Jidoka opiera się na inteligentnych maszynach, które zatrzymują się automatycznie, gdy wystąpi nieprawidłowość. Pracownicy mogą wówczas naprawić problem, powstrzymując tym samym przekazywanie wad w dół procesu produkcyjnego.

Jidoka upoważnia również każdego pracownika do zatrzymania linii produkcyjnej w przypadku wykrycia problemu. Zasada ta obejmuje czteroetapowy proces eliminacji marnotrawstwa wadliwych produktów:

1. Wykrywanie nieprawidłowości
2. Zatrzymanie produkcji
3. Naprawienie lub skorygowanie natychmiastowego stanu
4. Dochodzenie do pierwotnej przyczyny i naprawienie sytuacji

Koncepcję Jidoka można dostrzec w Lean i Agile, które koncentrują się na wczesnym i częstym testowaniu w celu wyeliminowania błędów oraz kładą nacisk na konsultacje z klientem w celu określenia bolączek użytkownika.

Marnowanie TPS w kontekście rozwoju oprogramowania

Aby osiągnąć produkcję JIT, Taiichi Ohno nakreślił siedem form marnotrawstwa, które należy wyeliminować. Numer osiem został dodany później. Jeśli przyjrzeć się bliżej wartościom, celom i zasadom Agile i Lean, można zauważyć, że są one zaprojektowane tak, aby chronić przed ośmioma marnotrawstwami TPS. W książce z 2003 roku Lean Software Development: An Agile Toolkit, Poppendieckowie przedstawili marnotrawstwa TPS w kontekście rozwoju oprogramowania.

1. Marnotrawstwo nadprodukcji. Marnotrawstwo nadprodukcji jest jednym z największych powodów, dla których metoda wodospadowa została porzucona. Nadprodukcja jest uważana za dodatkowe kodowanie funkcji, które nie były wymagane i których klient może nie chcieć.

Odbija się to w następujących zasadach:

Agile ⟶ prostota
Charette’s Lean ⟶ minimalizm
Poppendiecks’ Lean ⟶ eliminacja marnotrawstwa

2. Marnotrawstwo czekania. W produkcji JIT, czekanie na bezczynną maszynę lub pracownika jest marnotrawstwem. W rozwoju oprogramowania, marnotrawstwem jest czekanie na zespół z nadmiarem mocy produkcyjnych. Jeśli występują opóźnienia w produkcji, które powodują, że zespół jest w stanie gotowości, lub powodują, że klient czeka na dostawę, mamy do czynienia z marnotrawstwem.

Pasujące zasady są następujące:

Agile ⟶ częste cykle
Lean Charette’a ⟶ ⅓ czasu (cel LSD), 80% rozwiązań dzisiaj
Lean Poppendiecka ⟶ dostarczaj tak szybko, jak to możliwe

3. Marnotrawstwo transportu. W rozwoju oprogramowania, transport jest tłumaczony jako „przełączanie zadań”. Zbyt częste przekazywanie zadań lub pracownicy przydzieleni do wielu zespołów, wymagający nadmiernej wielozadaniowości, są nieefektywne i stanowią marnotrawstwo.

Pasujące zasady:

Agile ⟶ współpraca z interesariuszami, samoorganizujące się zespoły, kultura zaufania, wsparcia i motywacji
Lean Charette’a ⟶ wysiłek zespołowy
Lean ⟶ Poppendiecka wzmacnia zespół

4. Marnotrawstwo nadmiernego przetwarzania. To po prostu dodatkowe procesy, które tak naprawdę nie są potrzebne do dostarczenia wartości klientowi. Podstawowym przykładem jest dokumentacja. Nadmierna dokumentacja dla nieelastycznych procesów nie będzie wartościowa, podobnie jak zbyt szczegółowe podręczniki użytkownika, które można streścić na stronie lub dwóch. Dokumentacja jest czasochłonna, ale oferuje ograniczoną wartość dla użytkownika końcowego.

Pasujące zasady:

Agile ⟶ prostota, działające oprogramowanie jako miara
Charette’s Lean ⟶ minimalizm
Poppendiecks’ Lean ⟶ eliminacja marnotrawstwa

5. Marnotrawstwo zapasów. Marnotrawstwo zapasów to produkcja w toku, w którą zainwestowano, ale która nie ma wartości do czasu ukończenia. Innymi słowy, niekompletne oprogramowanie nie zapewnia żadnej wartości dla użytkownika. Lean i Agile cenią sobie szybkie i częste dostawy, z naciskiem na częste cykle iteracyjne i dostarczanie działającego oprogramowania.

Pasujące zasady:

Agile ⟶ satysfakcja klienta (poprzez wczesne i częste dostawy do klienta)
Charette’a Lean ⟶ 80% rozwiązania już dziś
Poppendiecka Lean ⟶ dostarczaj tak szybko, jak to możliwe

6. Marnotrawstwo ruchu. Marnotrawstwo ruchu to nadmierny wysiłek wymagany do uzyskania informacji lub odpowiedzi na pytania. Jest to powszechne, gdy zespoły nie są zlokalizowane w jednym miejscu, gdy zadania są wykonywane, a wyniki nie są natychmiast udostępniane wszystkim zainteresowanym stronom, lub gdy interesariusze nie są łatwo dostępni w celu konsultacji

Pasujące zasady:

Agile ⟶ współpraca z interesariuszami, komunikacja twarzą w twarz
Charette’s Lean ⟶ partycypacja klienta, wysiłek zespołowy
Poppendiecks’ Lean ⟶ eliminacja marnotrawstwa

7. Marnotrawstwo wad. Podobnie jak w produkcji, wytwarzanie wadliwego lub zawierającego błędy oprogramowania oznacza dla firmy marnotrawstwo inwestycji. Im szybciej wada zostanie wykryta, tym większe prawdopodobieństwo, że marnotrawstwo zostanie ograniczone. Wiele zasad Agile i Lean dąży do powstrzymania marnotrawstwa defektów. Aby zmniejszyć liczbę defektów, wszystkie trzy metodyki kładą nacisk na wczesne i częste testowanie.

Pasujące zasady:

Agile ⟶ techniczna doskonałość, działające oprogramowanie jako miara
Charette’s Lean ⟶ satysfakcja klienta
Poppendiecks’ Lean⟶ wzmocnienie nauki

8. Marnotrawstwo niewykorzystanej kreatywności pracowników. W procesie tworzenia oprogramowania niewykorzystana kreatywność wynika ze sztywnej mapy drogowej i braku współpracy międzyludzkiej. Podobnie jak Jidoka (自働化), Agile i Lean starają się zmaksymalizować ludzką współpracę i innowacyjność, aby uzyskać najlepsze wyniki z technologii.

Pasujące zasady:

Agile ⟶ współpraca z interesariuszami, refleksja zespołowa
Charette’s Lean ⟶ „niepisana” 13 zasada satysfakcji poprzez
pracę
Poppendiecks’ Lean ⟶ wzmocnienie uczenia się

Wartości TPS w metodologii tworzenia oprogramowania

Wiele z podstawowych wartości, które tworzą TPS, jest również odzwierciedlonych w metodologiach Agile i Lean tworzenia oprogramowania.

Kaizen (改善) tłumaczy się jako ciągłe doskonalenie. Dzięki elastycznym, iteracyjnym, skoncentrowanym na kliencie modelom, ciągłe doskonalenie jest prawdopodobnie najważniejszą wartością metodologii Agile i Lean.

Hansei (反省) oznacza autorefleksję. Jako środek do poprawy efektywności, The Agile Manifesto bezpośrednio przyjmuje autorefleksję zespołu jako swoją 12 zasadę. Wprowadzając swój model Lean Development, dr Charette wzywa czytelników do zastanowienia się nad wszystkimi obecnymi założeniami, które dyktują stosowane przez nich procesy, jako pierwszy krok do znalezienia lepszych. Zasada Poppendiecków „amplify learning” może być również uznana za zasadę Hansei.

Szacunek dla ludzi (尊重) jest centralnym elementem wszystkich trzech paradygmatów. Pierwszą wartością „The Agile Manifesto” jest „przedkładanie wartości jednostek i interakcji nad procesy i narzędzia.”

Szacunek dla ludzi pojawia się również w stwierdzeniu dr Charette’a o tym, jak ważne jest, aby jednostki odczuwały satysfakcję z pracy, a także w zasadzie Lean Poppendiecks’a dotyczącej wzmocnienia zespołów. Wartość ta uznaje, że kiedy jednostki są zaangażowane w podejmowanie decyzji i doskonalenie swojego środowiska pracy, są bardziej innowacyjnymi i wydajnymi pracownikami.

Seiri (整理) jest zasadą, która odzwierciedla marnotrawstwo. Seiri dyktuje, że to, co jest niepotrzebne, powinno zostać usunięte. Obejmuje to wszystkie z siedmiu marnotrawstw TPS, dla których zidentyfikowaliśmy już równoległe marnotrawstwo w środowisku rozwoju oprogramowania.

Gengchi Genbutsu (現地現物) dosłownie tłumaczy się jako „rzeczywiste miejsce, rzeczywista rzecz”. W praktyce oznacza to „skontrolować, aby zrozumieć”. Kiedy pojawia się problem w procesie produkcji, menedżer powinien udać się do źródła, aby zrozumieć problem i ustalić, jak go rozwiązać.

W tworzeniu oprogramowania wartość ta przejawia się w nacisku na krótkie cykle iteracji, wczesne testowanie i współpracę z klientami, tak aby inżynierowie oprogramowania mogli budować działające oprogramowanie, którego użytkownicy rzeczywiście chcą.

Podsumowanie

Jak wspomnieliśmy w akapitach otwierających ten wpis, metodologia Lean jest mniej dobrze rozumiana i często jest uważana za praktykę Agile. Lean jest być może mniej dobrze zdefiniowany po prostu z powodu swoich szerszych zastosowań.

Lean ma bardziej bezpośredni związek z Systemem Produkcyjnym Toyoty i został po raz pierwszy zaproponowany jako organizacyjny zestaw metod i praktyk do zarządzania biznesem, a dopiero później zastosowany do tworzenia oprogramowania. Agile, z drugiej strony, został opracowany specjalnie dla rozwoju oprogramowania przez oddanych specjalistów w tej dziedzinie.

Po szczegółowym przedstawieniu wspólnego tła i ogólnych zasad tych dwóch metodologii, można zauważyć, że te dwa paradygmaty mają więcej wspólnego niż różnic.

Jeden z głównych autorów „The Agile Manifesto”, Martin Fowler, który również blisko współpracował z Poppendieckami, podkreślił, że Lean i Agile nie wykluczają się wzajemnie:

Lean i Agile są głęboko splecione w świecie oprogramowania. Nie można tak naprawdę mówić o ich alternatywności…. nie robisz Agile czy Lean, robisz Agile i Lean.

1. 12 zasad Lean Software Development Charette’a zostało właściwie po raz pierwszy opisanych w artykule Jima Highsmitha „Lean Development” w 1998 roku. Zostały one później rozwinięte w artykule Dr. Charette’a „Challenging the Fundamental Notions of Software Development” ︎

.