Szał na Agile – tak, „szał” to słowo, które wydaje mi się w tym przypadku całkiem odpowiednie – trwa na świecie od kilku dobrych lat (jeśli nie od jakiejś dekady). Komu ten wyraz nic nie mówi, ten obowiązkowo musi zaktualizować swoją wiedzę na temat zarządzania. Agile jest modny. Agile jest trendy. Agile jest potrzebny. Agile dla firm innowacyjnych, które idą z duchem czasu to po prostu „must-have”. A mnie natomiast nowatorskość Agile wydaje się mocno przereklamowana. Hmmm, może powinnam ująć to inaczej: wydaje mi się, że Agile wcale nie jest tak unikatowy i wyjątkowy jakby się na pierwszy rzut oka wydawało. Aaaa, kij w mrowisko – checked. A niech się posypią i te sprzeczne komentarze. Tylko konstruktywnie, proszę! Już rozwijam temat

Na czym polega koncepcja Agile? Agile to w bezpośrednim tłumaczeniu „zwinny”. Innymi słowy elastyczny, zmienny, „łatwodostosowalny”. A jakie ma to bezpośrednie przełożenie na zarządzanie projektami? Wiodąca koncepcja Agile mówi, że na początku projektu nie powinniśmy na siłę planować całego jego przebiegu aż po produkt końcowy. Projekt powinniśmy wykonywać „w kawałkach”, tzw. iteracjach. W projektach zwinnych zakres nie jest ściśle określony, na początku projektu często nie wiemy jak ma wyglądać ostateczny wynik. Ustalamy razem z Klientem obszar produktu, nad którym popracujemy w pierwszej fazie (iteracji). Po ukończeniu fazy musimy koniecznie mieć namacalny produkt cząstkowy. Kawałek produktu, który da się zobaczyć, ocenić, by na jego podstawie móc ustalić co robimy dalej, w kolejnych iteracjach. I tak powtarzamy wielokrotnie aż do uzyskania upragnionego efektu końcowego. To co uwielbiam w Agile, to koncepcja zespołów „samoorganizujących się”. Zwinne zespoły to takie, które poniekąd same sobą zarządzają. Same ustalają kto jaką rolę będzie pełnił w danej iteracji, komu jakie zadania zostaną przypisane. Jak się domyślacie, rola lidera w projektach zwinnych jest mocno ograniczona. Zadaniem „przywódcy” jest tutaj ułatwianie pracy zespołowi, pokonywanie przeszkód jakie zespół projektowy napotyka w zderzeniu z otoczeniem pozaprojektowym, np. z ograniczeniami płynącymi z organizacji, w której zespół funkcjonuje. Zatem rolą lidera jest zazwyczaj również kontakt z Klientem. To jedynie zarys ogólnej koncepcji. Jest wiele metodyk, odłamów Agile. O nich może kiedyś w oddzielnych artykułach.

Agile a planowanie w stylu klasycznym

Jak to ma się do projektów zarządzanych klasycznie, stylem waterfall? Styl „wodospadowy” rzeczywiście skupia się na tym, by na początku projektu dobrze określić jego końcowy cel i kryteria sukcesu, by dokonać wszelkich dogłębnych analiz, by jak najwięcej czasu poświęcić na planowanie, bo ten czas podobno w fazie realizacji zwróci nam się z przysłowiową „nawiązką”. Ale ten styl również zakłada iteracje, czyli powtarzalność kroków wewnątrz poszczególnych faz projektowych. Ten styl również mówi o planowaniu kroczącym, które zakłada, że nie jesteśmy w stanie w szczegółach zaplanować całego projektu na samym początku. Co możemy, zrobić, to zaplanować fazy projektowe, podstawowe kroki, które musimy w projekcie wykonać i najbliższą fazę projektową zaplanować w szczegółach. Plany dla kolejnych faz projektowych będziemy doprecyzowywać zbliżając się do tych faz. Jeśli wiem, że pierwsza faza w moim projekcie to rekrutacja, a potem szkolenie, to dokładnie zaplanuję poszczególne kroki i scenariusze rozwiązania w fazie rekrutacji. Szkolenie prawdopodobnie zaplanuję na bardzo ogólnym poziomie, a plan ten doprecyzuję pod koniec rekrutacji. Wtedy dokładnie będę wiedziała ile osób weźmie udział w szkoleniu i jakie są potrzeby szkoleniowe. Czy czegoś Wam to nie przypomina? Jeśli chodzi o zarządzanie ludźmi, to „klasyka” nakazuje liderowi przypisywać zasoby do zadań. Czy znacie jednak teorię przywództwa, która mówi by robić to na siłę?

 Zmiany nieuchronne również w „klasyce”

Owszem, mogą zdarzyć się skrajne przypadki, w których rządzi klasyka. Wyobrażam sobie, że takich znajdzie się sporo w budownictwie, górnictwie, ogólnie w przemyśle. Jak przemyślę swoje doświadczenie, szybko jednak nasuwa się wniosek, że niejednokrotnie intuicyjnie działam w stylu Agile. Członkowie moich zespołów decydują na jakie zadania „rozbić” projekt i kto z nich będzie je wykonywał. Ja ich jedynie w tym zakresie wspieram. Nikt tego oficjalnie Agilem nie nazywa. Wszyscy niby myślą na nutę klasyczną. Tymczasem? Każdy wie, że określony cel projektowy będzie ewoluował w trakcie trwania projektu, że plany pewnie niejednokrotnie się zmienią, zmieni się otoczenie, zmienią się wymagania, zmieni się koncepcja. Tak! Bo rzeczywistość taka po prostu jest. W projektach ciągle się coś zmienia. Jeśli pracujemy dla organizacji, która chce być konkurencyjna, zmiana w projektach jest nieuchronna. Jeśli mogę pozwolić sobie na odrobinę szczerości, niejednokrotnie przysparzało mi to wiele frustracji. Jako świeżo upieczony kierownik projektu, denerwowałam się, że jeszcze wczoraj tak pięknie dopieszczony plan projektowy, dzisiaj już nie obowiązuje i trzeba go zmieniać. Przy dużych zmianach organizacyjnych zespołom tak trudno było doprecyzować finalną koncepcję struktury organizacyjnej i docelowego procesu, że wydawało mi się, iż z fazy planowania nigdy się nie wydostaniemy. I co? I trzeba było tworzyć jedynie zarysy nowej struktury, ramy nowego procesu, adresować obszary na daną chwilę bardziej oczywiste, ruszać z projektem i z czasem doprecyzowywać co dalej.

Agile a klasyczne koncepcje zarządzania ludźmi

Jeśli chodzi o zespoły, w klasycznym stylu zarządzania rzeczywiście może być różnie. Style zarządzania ludźmi i sposoby ich motywowania zależą od kierownika projektu, od kultury organizacyjnej. Jednak mój styl mocno wpasowuje się w Agile. Nie wyobrażam sobie zmusić kogoś do wykonywanej pracy. Wyznaję zasadę, że „z niewolnika nie zrobisz pracownika”. Sama jestem tego chodzącym przykładem. Za każdym razem, gdy moja praca ograniczała się do wykonywania zadań, za którymi nie przepadam, rozglądałam się za nowym zajęciem. Gdy moja nowa szefowa codziennie rozliczała mnie z pracy wykonanej w ciągu dnia, zaczęłam wysyłać CV. Na szczęście zdobyłam się na szczerą rozmowę i pozbyłyśmy się tego problemu w inny sposób. Staram się traktować ludzi tak samo, jak chciałabym być traktowana i w swoich projektach pozostawiam im dużą swobodę. Tak, nie zawsze ludzie wykorzystają tę swobodę w odpowiedni sposób. Z tym problemem jednak boryka się również Agile.

Dla kogo Agile?

Podsumowując, Agile jest świetną koncepcją dla każdej organizacji, niezależnie od branży. Jednocześnie Agile wcale nie jest czymś tak niesamowicie nowatorskim dla organizacji, które w metodzie klasycznej dawały swoim pracownikom dużo swobody i liczyły się z nieuchronnymi zmianami z projektach, czy też godziły się z faktem, że projektu nie da się na samym początku zaplanować od A do Z. Agile jest trudny do wdrożenia szczególnie dla kierownictwa wyższego szczebla przyzwyczajonego do tego, że zawsze widzi efekt końcowy, do którego zmierzamy, zna koszty całego projektu. Choć rzeczywistość dynamicznie rozwijających się organizacji jest taka, że zarówno kształt tego efektu końcowego, jak i koszty całego projektu zmieniają się w trakcie realizacji. I tego doświadczony management jest świadomy. W takich przypadkach organizacje wdrażają często Agile „na dole” struktury, a „góra” bądź Klient nadal dostaje raport w stylu klasycznym. Moim zdaniem to bardzo niekorzystne rozwiązanie i zaakceptowałabym je jedynie jako przejściowe. Owszem, mieszanie metodyk to świetne rozwiązanie. Nie ma jednej metodyki, która idealnie adresuje potrzeby organizacji. Każda organizacja powinna „uszyć sobie metodykę na miarę” swoich potrzeb. I takie rozwiązanie może mieć elementy Agile i waterfallowe. Nie ma w tym nic złego. Jeśli jednak wprowadzam elementy Agile do danego obszaru projektowego, to kompleksowo, w całe strukturze organizacyjnej. Nie ma sensu rozwiązanie, w którym „udaję”, że zakres jest nieokreślony i mogę sobie go doprecyzować w trakcie projektu, jeśli tak naprawdę za projektem jest już kontrakt podpisany z Klientem, w którym dokładnie sprecyzowaliśmy co otrzyma Klient, w jakim czasie i za ile.

To tyle gwoli zarysu fenomenu Agile. Polecam wnikać głębiej i wdrażać w swoich projektach. Osobiście uwielbiam swobodę i otwartość metodyk zwinnych.

Ci z Was, którzy znają mnie nie od wczoraj dobrze wiedzą, że nie jestem zwolennikiem żadnej z coraz popularniejszych „metod” skalowania Agile. Często wypowiadam się na ten temat i przeważnie negatywnie.

„Jeśli skalujesz Agile to robisz to źle.”

Wszystkie znane mi do tej pory metody i frameworki z SAFe (Scaled Agile Framework), Scrum of Scrums  i Agility Path na czele próbują narzucić rożne zasady i reguły, które maja być mniej lub bardziej uniwersalne dla każdej organizacji. To po prostu nie ma prawa działać.

Miałem okazję przez ostatnich kilka lat pracować z wieloma organizacjami, niektóre z nich były całkiem duże. Na tyle duże, że musiały zmierzyć się z problemem skalowania. Najczęstszym błędem który podczas takich prób zmierzenia się ze skalowaniem widziałem była próba zastosowania danej metody skalowania bez uprzedniego zastanowienia się nad problemami, które chce się rozwiązać.

Większość promowanych „metod” ze znajomości, których można sobie zrobić (kupić) różne certyfikaty których ładnie brzmiące nazwy możemy sobie później wpisać na linkedin według mnie nie rozwiązuje podstawowych problemów, lecz wręcz przeciwnie poprzez swoją pozorną prostotę i obietnicę naprawienia wszechświata generują więcej problemów niż rozwiązują. Nie – nie neguję wartości tych metod (nie wszystkich i nie całkowicie – tylko trochę) – niektóre z nich świetnie działają w pewnym kontekście. Niektóre pojedyncze elementy tych metod bazują przecież na prawdziwych wartości Agile i Lean jedyne co jest z nimi nie tak to próba zbudowania z nich zamkniętego narzędzia o uniwersalnym zastosowaniu.

Ktoś zarzucił mi nawet że jestem egoistą który twierdzi, że ludzie pracujący w dużych organizacjach nie zasługują na Agile. Hmm, niektórzy ludzie, w niektórych organizacjach – tacy, którzy nie chcą niczego zmienić, albo boją się zmian być może nie tyle nie zasługują na Agile  co Agile mógłby im zaszkodzić więc to raczej nie jest dla nich.

Powyższe nie oznacza, że nigdy z problemem skalowania się nie mierzyłem i nie mam w tym żadnego doświadczenia. Osobiście do tematu skalowania zawsze podchodziłem na kilku płaszczyznach i za każdym razem, w każdej organizacji wygląda to zupełnie inaczej, niemniej jednak często powtarzają się pewne tematy.

Po co skalować Agile?

Pierwsze zadawane przeze mnie pytanie tyczy się tego dlaczego dana organizacja jest na tyle duża, że potrzebuje jakiejś metody skalowania?

To pytanie może wydawać się proste, ale w większości przypadków próba zastanowienia się nad odpowiedzią prowadzi do źródeł wielu innych problemów, których rozwiązanie pozwala uniknąć potrzeby zastosowania metod skalowania. Czasem okazuje się, że wystarczy organizację podzielić na mniejsze, bardziej niezależne komórki skupione wokół poszczególnych produktów lub komponentów i okazuje się, że niczego nie trzeba skalować. Czasem dochodzimy do wniosku, że problemy, które chcemy rozwiązać są gdzieś indziej niż adresują to różne metody skalowania i wystarczy właśnie tam skupić swoją energię. To co niewątpliwie jest potrzebne w każdej organizacji bez względu na wielkość to określona metoda wspomagająca proces Continuous Improvements.

Co to znaczy skalować?

Drugie pytanie dotyczy tego co rozumiemy przez skalowanie?

Skalować możemy organizację zapewniając odpowiedni framework wymiany wiedzy oraz zapewniania transparentności i możliwości ciągłej inspekcji i adaptacji na wielu (wszystkich?) poziomach organizacji. Każda organizacja jest inna i narzucanie tutaj odgórnie struktury (tak jak próbuje to zrobić SAFe) jest raczej wątpliwie skuteczne. Czasem oczywiście (zwłaszcza gdy mamy do czynienia z chaotyczną organizacją o wątpliwej strukturze) narzucenie struktury jest świetnym posunięciem – tutaj SAFE z pewnością się sprawdza (przyznam, że jako konsultant poleciłem kilka razy SAFe właśnie w takich przypadkach).

Skalowanie to również skalowanie produktu. Jeśli mamy do czynienia z monolitycznym produktem, z dużym legacy i długiem technicznym to wartość wdrożenia jakiejkolwiek metody skalowania będzie raczej znikoma. Często do tego problemu docieramy zadając pierwsze pytanie powyżej – to taka architektura często jest przyczyną nadmiernego wzrostu organizacji.

Trzecie pytanie to w zasadzie obserwacja tego jak w tej chwili wygląda organizacja i w jaki sposób podejmowane są decyzje?

Wizualizacja tego procesu często jest już wystarczającym krokiem w kierunku poprawy i usprawnień. Value Stream Mapping i zaangażowanie odpowiednich osób w dyskusję może bardzo pomóc.

Następnie jest czas na pytania o to czy istnieje coś takiego jak wizja organizacji i wizja produktu? Jak ta wizja, misja i deklarowane wartości są reprezentowane przez realne, codzienne działania? Czy wizja jest klarowana i transparentna? Czy wszyscy w organizacji są jej świadomi? Czy mają na nią wpływ? Czy ludzie w organizacji utożsamiają się z wartościami deklarowanymi przez organizację.

Mając jasną wizję produktu możemy ją dekomponować na pracę dla poszczególnych zespołów produktowych. Mając jasną wizję organizacji możemy ją dekomponować i uskuteczniać w pętli Inspect & Adapt na poziomie każdego zespołu i całej organizacji.

W powyższy (opis mocno uproszczony) sposób staram się pracować z organizacjami już od dłuższego czasu dlatego też wczorajszego wieczoru zainteresowała mnie prezentacja mówiąca o „nowym” podejściu do skalowania: Scrum at Scale proponowana przez Scrum Inc. Tak jak w tytule jest to niewątpliwie światełko w tunelu dla osób poszukujących odpowiedzi na pytanie jak skalować organizację. Czy to światełko okaże się oczekiwanym rozwiązaniem wielu problemów czy może raczej nadjeżdżającym pociągiem? Myślę, że wszystko zależy od tego jak to dalej się potoczy i w którym kierunku popchną tą „metodę*” jej „twórcy**”. Na szczęście nie  ma (jeszcze) zmyślnej ścieżki certyfikacji co moim zdaniem daje nadzieję, na to, że ktoś faktycznie chce pomagać organizacjom a nie tylko i wyłącznie trzepać kasę kopiując model szkoleń i certyfikacji CSM i PSM z przed lat (za pierwszym razem to miało sens i wnosiło wartość – teraz certyfikatów na rynku zdaje się być kilkadziesiąt razy więcej niż możliwych do zastosowania w praktyce metod).

Z pewnością w najbliższym czasie będę chciał się bliżej przyjrzeć tej metodzie. Być może za jakiś czas przeczytacie o tym jak bardzo się myliłem i to tylko kolejny marketingowy BS, który ktoś próbuje wcisnąć ludziom z problemami zamiast pomóc im naprawdę te problemy zdiagnozować i rozwiązać…

*Scum at Scale cieżko jest mi nazwać metodą – to raczej zbiór kilku celów czy problemów które każda organizacja powinna zastosować. Ciekawą ideą jest wspomniana modułowość  proponowanego rozwiązania.

**Nie jest to też nic nowego bo podstawy są zbliżone chociażby do tego co można było znaleźć w początkowych wersjach SAFe, na pierwszy rzut oka widać też, że twórcy dużo inspiracji czerpią od takich autorów i myślicieli ze świata Lean i Agile jak chociażby Mary i Tom Poppendieck (Lean Software Development) czy Tom Gilb (Evo Method)

Jeśli mówimy o wymaganiach i specyfikacji i wprowadziliśmy już rozróżnienie tego czym są wymagania i czym jest specyfikacja, oraz że istnieje specyfikacja funkcjonalna oraz specyfikacja techniczna to teraz możemy swobodnie przemyśleć to jak skategoryzować poszczególne poziomy wymagań i specyfikacji.

Jak w tytule pozwoliłem sobie na wyróżnienie pięciu poziomów wymagań i specyfikacji, które można by przedstawić w postaci na przykład piramidy (Wygląda na to, że ludzie w IT lubią piramidy, nie wiem dlaczego…).

Na szczycie piramidy mamy pierwszy poziom: Jaki jest cel naszego przedsięwzięcia? 

Odpowiadając na pytanie po co nasza organizacja istnieje i po co tworzy produkty najprawdopodobniej dojdziemy do odpowiedzi, że oczywiście robi to dla pieniędzy. Tak, pieniądze i ich zarabianie są celem niemalże każdego biznesu (bezpośrednio lub pośrednio – np. zyski wizerunkowe, które później się monetaryzują). Warto o tym pamiętać bez względu na to gdzie w strukturach organizacji się znajdujemy bez względu na to czy tworzymy produkty dla naszej własnej organizacji czy jesteśmy jedynie dostawcami usług dla klientów/organizacji zewnętrznych. Aby osiągnąć cel (zarabianie pieniędzy) organizacja wytwarza pewne produkty – w IT mamy obecnie do czynienia raczej nie tyle z produktami w sensie wytwarzaniem pewnych dóbr materialnych co tworzeniem produktów będących narzędziami do świadczenia usług. Tworzymy produkty, które świadczą pewne usługi dla użytkowników końcowych za które są oni gotowi zapłacić.

Drugim poziomem jest odpowiedź na pytania: Kto jest interesariuszem naszego produktu i jakie problemy próbuje rozwiązać? 

Kto jest naszym odbiorcą i jest gotów zapłacić za „rozwiązanie” swoich problemów, spełnienie potrzeb? Jakich problemów i potrzeb? Warto pamiętać, że dla interesariuszy celem nadrzędnym też są raczej pieniądze więc myśląc nad produktami powinniśmy brać pod uwagę to w jaki sposób my możemy zarobić na tym, że zarabiają (oszczędzają) nasi klienci?

Mając problemy do rozwiązania i grupę odbiorców docelowych naszych rozwiązań mamy właściwie wysoko-poziomową definicję produktu.

Trzecie poziom to zdefiniowanie tego co będzie robił, czy też jakie funkcjonalności będzie zawierał nasz produkt by rozwiązać powyższe problemy interesariuszy?

Powyższe trzy poziomy to wymagania – co nasz produkt będzie robił by rozwiązać konkretne problemy, konkretnych interesariuszy. Na tym poziomie mamy zdefiniowane na pewnym poziomie abstrakcji ficzery naszego produktu. Możemy przystąpić do badania rynku i sprawdzania naszej hipotezy, że odbiorcy faktycznie potrzebują rozwiązać te problemy i są gotowi za nie zapłacić.

Czwarty poziom to  Specyfikacja Funkcjonalna – czyli odpowiedź na pytania w jaki sposób nasz produkt rozwiązuje problemy interesariuszy, jakie konkretne funkcjonalności dostarcza? 

Tutaj specyfikujemy jakie konkretnie funkcje naszego produktu użytkownicy będą mieli do dyspozycji. Możemy zbadać czy dane funkcjonalności są faktycznie przez użytkowników używane – czy są im potrzebne?

Piąty poziom to Specyfikacja Techniczna – w jaki sposób działają poszczególne funkcjonalności oraz jak są zaimplementowane?

Czwarty i piąty poziom to obszary w których możemy (a nawet powinniśmy) pokusić się o wykonywanie testów A/B i ciągłe usprawnianie dostarczanych przez nas funkcjonalności, tak by jeszcze lepiej spełniały oczekiwania użytkowników.

Na zakończenie jedna ważna uwaga: Nawet jeśli świetnie zdefiniujemy założenia co do wymagań i specyfikacji w naszym produkcie oraz poprawnie to zaimplementujemy to wcale nie znaczy, że nie mogą się one zmienić – to rynek zwaliduje czy mieliśmy rację. Dlatego też tak istotne jest testowanie naszych hipotez oraz wydawanie nowych wersji produktów – eksperymentowanie jak najczęściej, wprowadzając minimalne inkrementalne zmiany.

Z jednej strony fajnie, że się (developerzy) angażują i widzą pewne problemy w zespole (…) Nie chcę przerywać komuś kto odważył się włączyć do dyskusji w połowie zdania, bo wiem, że każdy tak naprawdę dojdzie do sedna tego co chciał powiedzieć. Ale z drugiej strony fakt, że nie jestem w stanie przewidzieć kto w kwestii danego problemu się odezwie i ile zajmie mu wypowiedź sprawia, że Retrospekcje strasznie się przeciągają – czasem nawet o półtorej godziny!

Nie mamy pomysłu co można by jeszcze zmienić. Do tej pory staraliśmy się zoptymalizować:

– przygotowanie planu spotkania (w miarę możliwości)

– wybieranie najważniejszych problemów (które mają odpowiednią ilość głosów innych członków zespołów)

– moje przypominanie ile jeszcze zostało do końca spotkania (ile mamy czasu)

I o ile dochodzimy do postanowień i wszystkie cele tego spotkania są spełnione, to jednak nie jesteśmy w stanie zmieścić się w czasie.

Rozmawiając ostatnio z kilkoma osobami na temat Lean Startup zaczęło mi brakować jasnej definicji czym jest Lean Startup. Zaczynając z kimś rozmowę na ten temat dobrze jest podać jeżeli nie definicję to chociaż krótkie „zdanie w windzie”, które szybko i sprawnie przekaże ideę tego czym jest Lean Startup. Na własne potrzeby stworzyłem więc taki opis, która w minimalnej liczbie słów stara się przekazać co to jest Lean Startup.

Lean Startup to zorientowana na budowanie wartości dla właścicieli, metoda iteracyjnego prowadzenia projektów rozwoju biznesu, w której miarą postępu jest dostosowywanie modelu biznesowego do realiów rynkowych.

2014

Najważniejszym elementem metody Lean Startup jest budowanie wartości rozwijanego biznesu. Wszystkie metodyki agile opierają się o przepływ wartości dodanej dla użytkownika końcowego. Agile jest tak skonstruowane, aby możliwie szybko dostarczać wartość (działające funkcjonalności) i sprawdzać je w praktyce, tzn. umożliwiając użytkownikowi końcowemu skorzystanie z nich. Bardzo podobnie działa Lean Startup, tylko inaczej definiowane jest pojęcie wartości. Ponieważ jest to metoda prowadzenia projektów rozwoju biznesu a nie operacyjnych to wartość jest generowana poprzez stworzenie „lepszego biznesu”. Czyli innymi słowy poprzez stworzenie biznesu, który ma większe szanse przetrwać na rynku i przynieść oczekiwane zyski dla właścicieli.

Metoda Lean Startup jest iteracyjna, co nie powinno dziwić w kontekście tego jaki sukces metody iteracyjne odniosły w tworzeniu produktów. Jedyne, co może dziwić to fakt, że tak długo trwało zanim ktoś opisał jak dokładnie przełożyć iteracyjność na projekt rozwoju biznesu. W przypadku tego typu projektów najbardziej istotną sprawą jest to, że wcześniej założenie było takie, że zanim zaczniemy tworzyć biznes powinniśmy mieć wszystkie możliwe badania rynkowe i plany modeli biznesowych. Sam projekt był tylko ich implementacją. Lean Startup natomiast postuluje, aby pierwsze badania i plany były ograniczone do absolutnego minimum (powstaje MVP – Minimum Viable Product), który natychmiast po powstaniu jest wypuszczany na rynek, gdzie próbuje się go sprzedać. Dostosowanie biznesu do oczekiwań rynku dzieje się natomiast już na bazie istniejącego MVP i realnych klientów w kolejnych iteracjach. Tak jak w agile oprogramowanie po każdej iteracji dostaje klient, aby mógł w nie poklikać.

Iteracje w metodzie Lean Startup służą do tego, aby wypracować lepszy model biznesowy. To jest chyba największa zmiana mentalna w porównaniu z agile. W agile na koniec każdej iteracji mamy namacalny (bądź klikalny) produkt. W Lean Startup mamy… lepszy model biznesowy, czyli nową zapisaną kartkę papieru. Innymi słowy: firmę lepiej dostosowaną do potrzeb rynku i mającą większe szanse na przetrwanie na rynku. Zmiany w modelu biznesowym nie muszą być wielkie, ważne aby przynosiły skutek w postaci lepszych wyników. Wyników, które rozumiane są jako lepsze wartości kluczowych wskaźników biznesu. .Te kluczowe wskaźniki to wbrew pozorom nie są pieniądze. Na wczesnym etapie rozwoju biznesu ważniejsze są np. wskaźniki dotyczące pozyskiwania nowych klientów, konwersji, etc. Ważne jest, że model biznesowy po każdej iteracji ma skuteczniej realizować te wskaźniki. To natomiast oznacza, że firma lepiej realizuje potrzeby rynku, czyli zwiększa się jej wartość (oczywiście przy założeniu, że wskaźniki są dobrze dobrane). Co znów jasno potwierdza, że metodyka nastawiona jest na szybkie i efektywne dostarczanie wartości właścicielom projektu (czyli w większości przypadków właścicielom biznesu).

Warto też podkreślić, że iteracja kończy się nie z chwila wypuszczenia nowej wersji produktu na rynek, tylko z chwila zmierzenia reakcji tego rynku i wyciągnięcia wniosku. W agile trzeba zamykać iteracje agile produkując działający produkt, potwierdzony na demie przez klienta. W Lean Startup trzeba zamykać iteracje dostarczając model biznesowy lepiej akceptowany przez rynek. Demo odbywa się tutaj w realnym świecie, na realnych klientach. Iterację zamknąć jednak trzeba, jeżeli ma z niej wyniknąć jakakolwiek nauka i lepszy model biznesowy.

Powyższe w skrócie tłumaczy czym jest Lean Startup. Definicja słownikowa to może nie jest, ale zacytowane na początku zdanie plus wyjaśnienia poniżej pomogły mi już nie raz zainteresować osoby, które wcześniej o tej koncepcji nie słyszały.