Z tego podcastu dowiesz się:

• Czym jest metodologia zarządzania
• Dlaczego jest tak wiele różnych metodologii
• Co wpływa na wybór odpowiedniej metodologii do projektu
• Jak dobrać odpowiednią metodykę
• Jaki cel mają wszystkie metodologie
• Czym jest Agile
• Do jakiego projektu wybrać Agile
• Gdzie Agile na pewno się nie sprawdzi
• Czym jest liniowa metodyka zarządzania
• Jakie cechy posiada Waterfall
• Czy Waterfall sprawdzi się w małych projektach
• Gdzie na pewno nie sprawdzi się Waterfall
• Jakie cechy ma Kanban
• Co odróżnia Kanban od Scruma
• Co to jest Scrumban i gdzie go wdrożyć
• Do jakich projektów Scrum się nie nadaje i dlaczego
• Gdzie Scrum sprawdzi się idealnie
• Lean Management – co to takiego?
• Jakie mamy rodzaje marnotrawstwa według metodyki Lean
• Co to jest Muda, Mura i Muri
• Na czym polega metodologia Six Sigma
• Gdzie nie stosować Six Sigma
• Co to Extreme Programming (XP)
• Jakie jest 5 zasad programowania ekstremalnego

Podcastu wysłuchasz także na:

• Spotify
• YouTube
• Google Podcasts
• Apple Podcasts

Przydatne linki oraz źródła:

1. Ogólnie o metodologiach zarządzania projektami https://www.teamwork.com/project-management-guide/project-management-methodologies/
2. Programowanie zwinne według Wikipedii https://pl.wikipedia.org/wiki/Programowanie_zwinne
3. Jakie metodyki do jakich projektów https://zenkit.com/en/blog/7-popular-project-management-methodologies-and-what-theyre-best-suited-for/
4. Czym tak naprawdę jest agile https://www2.deloitte.com/pl/pl/pages/technology/articles/czym-tak-naprawde-jest-agile.html
5. Zestawienie popularnych metodyk zarządzania https://www.lucidchart.com/blog/agile-vs-waterfall-vs-kanban-vs-scrum

Transkrypcja podcastu

Scrum, wszędzie Scrum. Tylko czy ten Scrum tak naprawdę do wszystkiego się nada? 

BYĆ JAK MANAGER podcast, epizod 4

Dzień dobry. Dziś temat – wydaje mi się – naprawdę na czasie. Temat, z którym spotkasz się Drogi Słuchaczu niezależnie od tego, przy jakim projekcie technologicznym, przy jakim projekcie IT będziesz pracował, tudzież już pracujesz. Ponieważ dziś chciałbym na czynniki pierwsze rozłożyć pewne popularne metodologie zarządzania. Zastanowić się, a następnie odpowiedzieć i mnie, i tobie na pytanie, jak dobrać właściwą metodologię zarządzania, do projektu, z którym przyjdzie ci się zmierzyć.

Jest taki duży hype na Scruma. Wszędzie, gdzie rozmawia się o projektach IT, zaraz słyszymy pojęcie scrum mastera, product ownera, wszyscy chcą robić i wdrażać produkty w sposób iteracyjny, dzielić kamienie milowe na fazy, na wdrożenia, na iteracje, na sprinty. Scrum opanował branżę IT. Ale czy naprawdę jest tak, że ten Scrum pasuje zawsze i wszędzie, do każdego projektu? Według mnie nie.

Nie wiem jakie jest twoje zdanie, natomiast dziś, tak tytułem wstępu, na pewno przejdziemy sobie przez kilka popularnych metodologii. Odpowiemy sobie na pytanie – po co właściwie wdraża się metodologię zarządzania? Dlaczego powstały metodologie zarządzania? A następnie spróbuję podzielić się z tobą kilkoma protipami, czyli w jaki sposób możesz łatwiej, sprawniej, bezpieczniej i skuteczniej, dobrać metodologię do projektu, którym będziesz kierował albo który będziesz współtworzył.

Zacznijmy.

Czym tak naprawdę jest metodologia zarządzania? Metodologia to jest pewien zbiór zasad, zbiór praktyk, które mają cię wspierać w prowadzeniu projektu, tak żebyś temu projektowi i pracy zespołowej zapewnił optymalną wydajność. Każda metodologia to jest swojego rodzaju framework, który pomaga ci zarządzać projektem w najlepszy możliwy sposób. I tyle.

Zarządzanie projektami jest, powiedziałbym, arcyważne dla firm i zespołów. Ale żeby to zarządzanie było efektywne, musisz postawić na odpowiednią metodykę zarządzania twoim projektem, twoim zespołem, organizacją, produktem, ale także celami tego zespołu. I teraz powstaje pytanie, dlaczego mamy aż tak wiele różnych metodologii zarządzania? I tutaj też nie ma zerojedynkowej odpowiedzi, ponieważ składa się na to wiele aspektów.

Po pierwsze – nie ma dwóch takich samych projektów. Po prostu nie ma. Każdy projekt jest swego rodzaju inny i ma pewne cechy, które go wyróżniają na tle innych, pozostałych projektów. I teraz, jeśli rozłożysz na czynniki pierwsze, przykładowo, różne cele projektów, różne KPI, różne metody produkcji, wytwarzania danego dobra, różne typy zespołów, a zwłaszcza chociażby różne rodzaje przemysłu, no to wtedy łatwo zauważysz, że na logikę i na chłopski rozum, nie może istnieć jeden model zarządzania. Generyczny, który pasowałby zgrabnie do tych wszystkich czynników. Tak się po prostu nie da.

Także to, co działa w jednym miejscu, nie do końca musi działać w innym miejscu. W innym miejscu, dla innych zespołów, może się okazać koszmarem.

Lata temu, programiści zaczęli odczuwać głównie na własnej skórze, że takie tradycyjne, my powiedzielibyśmy oldschoolowe metody i modele zarządzania, zamiast ułatwiać im pracę, to jeszcze bardziej ją utrudniają. W odpowiedzi na własne bolączki, inżynierowie zaczęli po prostu rozwijać własne metodyki zarządzania, które były skrojone według ich potrzeb, odpowiadały na ich potrzeby. I z czasem, z biegiem lat, te metodyki zyskiwały coraz bardziej na popularności, zaczęły być adaptowane przez innych inżynierów, w innych branżach, w innych przedsiębiorstwach. W ten sposób kolejne organizacje zmieniały i dostosowywały te frameworki do swoich unikalnych potrzeb w projektach. No i tym sposobem, jak już możemy się domyślić, powstało wiele odmian, a nawet zupełnie nowych metodologii zarządzania, które różnią się od siebie w ogóle i w szczególe.

Jeszcze zanim zacznę opowiadać o tym, jak wybieramy odpowiednią metodykę do projektu, to drogi słuchaczu, serdecznie dziękuję, że włączyłeś i ten podcast i z góry dziękuję, jeśli słuchałeś także moich poprzednich podcastów. I będę stokrotnie wdzięczny, jeżeli w ramach takiej dżentelmeńskiej, niepisanej umowy między nami – albo skomentujesz ten podcast na moim blogu bycjakmanager.pl, albo dasz mi znać w mediach społecznościowych, np. na Instagramie, tudzież na LinkedIn, czy podobał ci się ten podcast i co potencjalnie mógłbym zmienić lub poprawić, w moich przyszłych podcastach, to będę ci serdecznie wdzięczny. Ja ze swojej strony, to co mogę ofiarować i jaką wartość mogę ci dostarczyć, no to staram się, aby była to wartość wykazana właśnie w takich podcastach, gdzie dzielę się protipami, różnymi praktycznymi wskazówkami do tego, jak zarządzać produktem lub projektem w branży technologicznej. Dzielę się tą wiedzą za darmo. Z góry dziękuję, jeżeli także za darmo i bez zobowiązań, podzielisz się ze mną swoim feedbackiem na temat tego podcastu.

A więc, jak wybrać odpowiednią metodykę do projektu. I tutaj też na twoją decyzję o wyborze właściwej metodyki, wpłynie kilka czynników. Jednym z takich czynników będzie koszt i budżet. Należy sobie odpowiedzieć na pytanie, z jakim budżetem w skali 1-3 mamy do czynienia. Czy to jest mały budżet, średni budżet, czy to jest duży budżet. Czy istnieje pewna przestrzeń do tego, żeby powiększyć budżet, jeśli będzie to konieczne, żeby więcej budżetu przepalić na wdrożenie pewnej metodologii zarządzania. A może tak naprawdę budżet jest stały i nie do ruszenia. I pewne metodyki, które wymagają większego nakładu finansowego do wdrożenia, z góry będzie trzeba odrzucić, chociażby z uwagi na brak finansów. Jaka jest wielkość zespołu, to też jest pytanie, które należy sobie zadać. Ile osób będzie zaangażowanych w projekt, jaka będzie liczba interesariuszy, liczba inżynierów, deweloperów, liczba badaczy, jeżeli takowi są wymagani w projekcie. W końcu, czy zespół będzie kompaktowy i samoorganizujący się, czy bardziej rozciągnięty i rozsiany po całej organizacji.

Kolejny czynnik – jakie ryzyko możemy przyjąć albo na jakie ryzyko możemy sobie pozwolić. Czy to jest ogromny projekt z bardzo dużym wpływem na użytkowników, który musi być zarządzany niezwykle, ale to niezwykle ostrożnie, ponieważ mamy mały margines błędu. Dla przykładu jakieś aplikacje medyczne, które potencjalnie mają wykrywać raka chociażby, wśród swoich użytkowników. Nie wiem, czy takie technologie istnieją, teraz mówię z głowy, nie sugerujcie się tym, ale wyobrażam sobie, że w bardzo takich wrażliwych… przy pracy na wrażliwych danych, ten margines błędu, który możemy popełnić jako inżynierowie i menadżerowie zarządzający takim projektem, tudzież produktem, jest bardzo mały. A być może jest to mniejszy projekt, w którym możemy sobie pozwolić na trochę więcej swobody, na trochę więcej eksperymentów. Kolejnym czynnikiem jest elastyczność. Czy jako project manager widzisz możliwość zmiany scope’u, zmiany zakresu prac w trakcie trwania projektu. A co z finalnym produktem – czy ten produkt już jest zdefiniowany, jak ma wyglądać, czy on się może zmienić, jeżeli taka potrzeba wyjdzie nam z badań. Kolejny czynnik – timeline, czyli deadline’y. Jak wiele rzeczy trzeba dowieźć na szybko, a jak bardzo możemy sobie pozwolić na długotrwałą pracę nad produktem, żeby końcowy efekt był dopieszczony, wręcz wycyzelowany, nie wiem, jak jeszcze mogę to określić. I ostatni czynnik, który teraz przychodzi mi do głowy, to współpraca z klientem lub szeroko pojętym biznesem. Jak bardzo nasz klient musi albo chce być zaangażowany w ten proces. Jak bardzo ty musisz albo chcesz angażować klienta w pracę. Te czynniki na pewno wpływają na dobór odpowiedniej metodologii do twojego projektu. I teraz ważna rzecz to pamiętajmy, że są różne metodologie, ale one mają praktycznie zawsze ten sam cel – mają ułatwić sukcesywne dowiezienie projektu do końca. Do tego czasu, zanim nie dowieziemy projektu, każda metodologia tak naprawdę, niezależnie, którą poweźmiemy, pomaga nam zarządzać procesem zespołu wzdłuż całej struktury firmy i całej komunikacji w firmie. I to jest taki wspólny mianownik dla wszystkich metodologii zarządzania. Chcę teraz w kilku słowach przejść przez kilka według mnie bardzo popularnych metodologii zarządzania, natomiast zaznaczę z góry, że nie będę opisywał od podstaw każdej z metodyk. To można łatwo wygooglować. O każdej metodyce opowiem więc tyle, ile trzeba, żeby pokazać, do jakiego projektu będzie najlepiej dopasowana. A na stronie bycjakmanager.pl pod postem, gdzie opublikowałem ten podcast, znajdziesz także źródła, z których czerpałem wiedzę, informację, oczywiście poza swoim doświadczeniem, do dzisiejszego podcastu. 

Zacznijmy od Agile. Bardzo szerokie pojęcie. To jest metodologia zazwyczaj wykorzystywana przy wytwarzaniu oprogramowania. Tutaj chodzi o takie wspólne kross-funkcjonalne podejście do ukończenia pracy i zaspokojenia wymagań biznesowych. Tutaj mówię o ukończeniu pracy nad danym produktem, serwisem, czy mówiąc ogólnie projektem. I Agile odnosi się bardziej do konkretnych metodyk. To jest pewna grupa metodyk, chociażby do Scruma i Kanbana. Agile opiera się na takich adaptatywnych, równoległych przepływach pracy. I to jest tak naprawdę przeciwieństwo liniowych metodyk zarządzania, takich jak waterfall. Każda metodyka Agile, co warto pamiętać, czymś się charakteryzuje. Zaraz opowiem więcej o kilku poszczególnych metodykach Agile, tak że uzbrój się drogi słuchaczu w cierpliwość. Pomimo że każda metodyka Agile czymś innym się charakteryzuje, to niemal wszystkie dzielą projekt na pewne mniejsze iteracyjne okresy, które działają zasadniczo dobrze na produkt, nad którym pracujemy. Jednym z takich benefitów jest chociażby regularne iteracyjne testowanie funkcjonalności, nad którymi pracujemy, jeżeli mówimy o tworzeniu oprogramowania. Co warto wspomnieć to Agile opiera się na pracy przyrostowej, na tzw. inkrementach. Ponadto zespoły mogą się zmieniać, dostosowywać procesy z pewną częstotliwością. Z kolei, mówię to teraz dla kontrastu, taki waterfall, czyli liniowa metodyka, to bardziej stały set, jakaś grupa zasad, które są nieelastyczne, których nie powinniśmy zmieniać.

Metodyki Agile zachęcają zespoły do pewnych zmian i usprawnień, jeżeli zespół widzi taką potrzebę. To też jest istotne. I z racji tego, że Agile jest bardzo adaptatywnym, tudzież adaptacyjnym modelem zarządzania, sprawdzi się w następujących projektach. Tam, gdzie wymagania od biznesu mogą się zmieniać, chociaż oczywiście warto unikać częstych zmian. Agile sprawdzi się w miejscach, gdzie możemy być prawie pewni, że scope albo zakres prac nadchodzącej funkcjonalności się zmieni. Lub w drugą stronę, kiedy nie możemy być 100% pewni co do scope czy zakresu prac. Agile sprawdza się także w miejscach, gdzie częścią tego procesu wytwórczego będą różne badania, różne eksperymenty, testowanie, szukanie właściwej drogi rozwoju dla produktu. Agile sprawdzi się także w projekcie, który może być rozłożony na pewne mniejsze części, na iterację. Może być dowożony mniejszymi partami. I dalej Agile sprawdzi się w miejscu, gdzie projekt jest skomplikowany. Gdzie wymaga od nas i od pozostałych członków zespołu wielopłaszczyznowego podejścia lub w projektach, gdy nie możemy być pewni co do wyniku naszych prac albo finalnego kształtu produktu. W sensie pracujemy nad czymś, ale to jak będzie wyglądał ten końcowy produkt, jest jeszcze takim wielkim znakiem zapytania, my chcemy się w trakcie prac nad tym produktem dowiedzieć, jaka będzie ta najwłaściwsza, największa wartość tego produktu.

Idąc dalej, Agile sprawdza się także przy projektach, gdzie klient albo interesariusz, tudzież po prostu strona biznesowa, chcą być bardzo zaangażowani w te prace na każdym etapie. Ja bym to uprościł dla ciebie i radziłbym albo rekomendowałbym zapamiętać, że jeżeli myślisz sobie elastyczność, niech za tym pojęciem kryją się różne wartości. Ale jeśli myślisz sobie ogólnie – elastyczność – no to tutaj Agile będzie właściwym podejściem. Natomiast, gdzie nie sprawdzi się Agile? W miejscach, gdzie potrzebujemy ogromnej ilości dokumentacji. Na przykład, gdy onboardingujemy nowych ludzi do zespołu i projekt albo produkt, nad którym pracujemy, po prostu wymaga dużych ilości dokumentów i dokumentowania kolejnych etapów prac w każdym miejscu, gdzie wdrażamy nową funkcjonalność. Nie sprawdza się zazwyczaj Agile także w miejscach i przy projektach, gdzie potrzebujemy mieć rezultaty, które są przewidywalne, gdzie musimy być absolutnie pewni, co zostanie dowiezione na finał. Nie sprawdzi się także Agile, jeśli ty jako project manager i twój zespół, nie możecie sobie pozwolić na zmiany scope’u, na zmianę zakresu prac w trakcie developmentu. Jeżeli okaże się, że w trakcie developmentu coś może nie zadziałać do końca, ale wy nie możecie tego zmienić, w sensie, jeżeli nie możecie tego zmienić, to nie wybierajcie Agile jako tej kluczowej metodyki zarządzania waszym projektem. Aż w końcu, gdy nie masz wokół ludzi, którzy potrafią się sami motywować do pracy, to nie jest jakieś takie must have wymaganie, ale Agile raczej jest dla zespołów samoorganizujących się i tych, które mogą się samomotywować do stałego polepszania i usprawniania tego procesu wytwarzania oprogramowania. Aż w końcu, jeśli masz jasno określone przez biznes deadline’y, których musisz się sztywno trzymać, te deadline’y są nieprzesuwalne, nienegocjowalne, to lepiej nie idź w Agile. Bo Agile przewiduje, że pewien scope i pewne deadline’y mogą się zmienić w czasie. Tyle, jeśli chodzi o Agile. Zaraz jeszcze wrócimy do poszczególnych metodyk Agile, natomiast odejdźmy na chwilę od nich i porozmawiajmy o Waterfallu. 

Otóż Waterfall jako stricte liniowa metodyka zarządzania projektem, powstał tak naprawdę w budownictwie i w manufakturze, w branżach, gdzie jedna faza prac musi zostać w pełni ukończona, zanim rozpocznie się kolejna faza prac. Dla przykładu, czy możesz postawić dach, jeśli nie zbudowałeś jeszcze ścian budynku? Konstrukcję dachu jako tako zrobić można, ale nie zawiesisz jej w powietrzu. Musisz najpierw postawić ściany, pewne fundamenty, żeby na nich zawiesić i usadowić dach. I o tym traktuje waterfall, o pewnej liniowości wytwarzania dobra dla klienta, dla użytkownika. Waterfall zakłada, że nie możesz cofnąć się do poprzedniej fazy, jeżeli ukończyłeś kolejną. Każda korekta poprzedniej fazy wymaga bowiem tego żebyś ten cały proces rozpoczął od nowa.

Są takie domyślne fazy w Waterfallu, pierwszą fazą jest system & software requirements i to jest zebranie wymagań. Bardzo dokładne, bardzo szczegółowe, nie pozostawiające wątpliwości ani pytań, zebranie i zdokumentowanie wymagań co do tego, jaki powinien być finalny kształt produktu lub projektu, nad którym pracujesz. Drugą fazą analizy. Trzeba te wszystkie wymagania bardzo dokładnie przeanalizować, omówić z zespołem. Różnie się nazywa tę fazę – albo faza analiz, albo faza refinementu, albo faza elaboracji. Kolejną fazą, kiedy już analizy zakończą się pomyślnie i dojdzie się do konsensusu i pełnego zrozumienia pomiędzy działem technicznym a biznesem, no do to jest design, czyli trzeba zaprojektować te wymagania biznesowe. I dopiero później, wyobraź sobie, następuje faza koderska, powiedziałbym tak skrótowo, gdzie kodzi się wszystkie wymagania, bazując także na designach. Po fazie kodowania, po codingu, oczywiście mamy fazę testów, sprawdzania jak to działa, czy my naszą robotę wykonaliśmy poprawnie i należycie, czy nic nam się nie wysypuje po drodze. No i na samym końcu jest operations, czyli wiadomo, tutaj wdrożenie danego dobra na rynek, do klientów, do użytkowników.

Ten nacisk na liniowość tych postępów prac, w Waterfallu jest powiedziałbym centralnym punktem tej metodologii. On jest niezmienialny. Wymagania muszą być przez to bardzo jasne i bardzo dokładnie omówione już od samego początku, jeszcze zanim uruchomimy kolejną fazę prac nad produktem. I w tej metodzie najpierw zbieramy i dokumentujemy wymagania, a dopiero potem udostępniamy je członkom zespołu. Dodatkowo, co myślę warto pamiętać to, że zespół dokumentuje prace po każdej fazie projektu.

Nie na sam koniec, kiedy już zrobiliśmy wszystko i to co zrobiliśmy po prostu działa, tylko po każdej fazie projektu ta dokumentacja musi powstać. I ta dokumentacja jest piekielnie ważna, mówię już po raz czwarty o tym, wspominając o tej metodologii, ale to jest naprawdę istotne w podejściu waterfallowym. Jeśli któryś z pracowników odejdzie na przykład z firmy w trakcie trwania projektu, to wskazany zastępca na jego miejsce, powinien być w stanie kontynuować prace swojego poprzednika, zaraz po tym, jak zapozna się z dokumentacją. Ta dokumentacja to musi być know-how kompletny, stuprocentowy od początku do końca tego jak wygląda projekt i w którym kierunku dążymy. I Waterfall sprawdzi się w związku z tym co powiedzieliśmy, w następujących projektach. Tam, gdzie projekt jest realizowany w sposób liniowy, czyli chcemy przejść od punktu a przez punkt b, aż do punktów x, y, z. I w projektach, gdzie nie ma możliwości cofnięcia się do poprzedniej fazy, tak, żeby zmienić na przykład początkowe wymagania. No i teraz rodzi się pytanie, które to są te liniowe projekty. Najczęściej są to duże projekty, gdzie biznes daje rygorystyczne deadline’y, których trzeba po prostu przestrzegać. To są pewne projekty powtarzalne. Np. budowanie tego samego produktu po raz któryś, ale dla innego klienta, projekty, gdzie szanse na zakończenie czymś nowym, jakimś nowym rezultatem, są relatywnie małe. Jakby robiliśmy ten produkt już wiele razy, musimy go zrobić po raz kolejny i trzymać się deadline’ów. Tutaj nic nie zmieniamy, nie jest to dla nas eureka, nie odkrywamy koła na nowo.

Także w projektach, gdzie cel jest jasno zdefiniowany i wiemy, że na pewno się nie zmieni w przyszłości, produkt, tudzież serwis, usługę, którą musimy wytworzyć, pewne dobro jest ustalone z góry i ono się nie zmieni. Ono ma wyglądać dokładnie tak jak sobie ustaliliśmy. W projektach, gdzie prace są przewidywalne, no ale to samo przez się, jeżeli mamy z góry ustalony produkt, wygląd, ten finalny kształt produktu, to łatwiej jest przewidzieć te prace na poszczególnych etapach. Waterfall sprawdza się także w branżach, które wymagają obszernej dokumentacji i takiego dokładnego trackowania postępu prac. Jeżeli to jest liniowy proces, to nieco łatwiej i szybciej jest nam sprawdzić, na jakim etapie jesteśmy. Po prostu sprawdzimy na timeline, sprawdzimy na statusy prac i wiemy – aha, tak wygląda projekt. Tu jest początek, tu koniec, a my jesteśmy w tym miejscu. Także Waterfall może się sprawdzić w miejscach, jeżeli chcesz wciągnąć jako project manager, kolejne osoby do projektu w trakcie jego trwania. Tak, żeby przyspieszyć prace. Czyli jeżeli mamy dobrze skrojoną dokumentację, prace są liniowe, znamy scope, nie mamy po drodze żadnych badań, żadnych niewiadomych, ale chcemy nieco przyspieszyć, to potencjalnie jest duża szansa, że jeśli masz waterfall, to możesz wciągnąć kolejne osoby do projektu, rozdzielić te prace tak, żeby one postępowały szybciej. Ale pamiętajmy, że Waterfall nie sprawdza się wszędzie, tak jak zresztą pozostałe metodyki. Otóż nie sprawdzi się na pewno w projektach, które są narażone na zmiany, gdzie mamy sporo niewiadomych. Nie sprawdzi się także Waterfall w projekcie, jeśli nie posiadamy kompletnego obrazu wszystkich wymagań, zanim wystartujemy z projektem. Także tam, gdzie potrzebujemy adaptować nowe rozwiązania, nowe technologie, w trakcie trwania naszego procesu, no to Waterfall nie jest idealnym rozwiązanie. I podobnie, gdy produkt musi być testowany w czasie implementacji na różnych etapach, aby na bieżąco zbierać feedback od użytkowników, to także Waterfall nie wspiera tego typu działań. Pamiętaj o tym, a żaden Waterfall nigdy nie będzie ci straszny. 

Kanban. Kolega Kanban, o którym pewnie niejednokrotnie już słyszałeś, wiele osób często ustawia Kanban naprzeciw Agile i nawet można spotkać takie artykuły w sieci „Kanban vs Agile”, ale to jest nieprawda, ponieważ Kanban to jedna z agilowych metod zarządzania. I Kanban dąży do powiedzmy lepszego koordynowania i takiego balansowania pracy wraz z taką pojemnością i przepustowością pracowników. Brzmię teraz troszkę jak masło maślane, troszkę takiego korporacyjnego bullshitu rozsiałem, ale już wyjaśniam. Otóż koncepcja Kanbana została rozwinięta w fabrykach produkcyjnych Toyoty, mniej więcej w latach 40. ubiegłego wieku. I ta metodyka okazała się wtedy dla Toyoty na tyle elastyczna, że zaczęto ją wykorzystywać także w innych branżach. I Kanban wykorzystuje pewne pryncypia Agile, ale implementuje je do siebie w nieco inny konkretny sposób. Otóż mamy kanbanowy board. Tablicę kanbanową, która odzwierciedla pewien workflow zespołu. I ta tablica kanbanowa jest podzielona na kategorię prac do zrobienia, czyli to-do, w trakcie, czyli in progress oraz na prace ukończone, czyli done. Zespół oczywiście może dodawać kolejne kategorie albo statusy, jeżeli uzna to za zasadne, żeby lepiej wizualizować ten proces prac nad powiedzmy oprogramowaniem, a każde zadanie jest kolejno przesuwane z jednej kolumny do następnej, aż do momentu ukończenia. Czyli rozpoczynamy pracę nad zadaniem, ono jest w to-do, działamy na nim, jest in progress, kończymy je robić, jest done. Tak w największym uproszczeniu wygląda Kanban. I dzięki takiemu podejściu, cały zespół jest jednakowo informowany o tym, jaki jest postęp prac w projekcie. Patrzysz na taką tablicę i widzisz, kto jest na jakim etapie ze swoim zadaniem. Natomiast, tu dochodzimy do pewnego clou i rzeczy bardzo istotnej, jeśli mówimy o Kanbanie, jest pewien limit tasków, czyli zadań, które mogą być jednocześnie w kolumnie in progress. To jest tak zwany WIP limits – works in progress limits. Jeśli zespół widzi gdzieś wąskie gardło, to do momentu ukończenia obecnych tasków, pozostałe taski nie mogą być rozpoczęte. Jeśli ustalimy na początku, że maksymalnie możemy mieć in progress, czyli w trakcie, 5 różnych zadań, to my się tego trzymajmy. I żaden inny członek zespołu nie może wziąć kolejnego zadania i otagować je jako in progress, że jest w trakcie, dopóki nie ściągnięcie liczby obecnych tasków z in progress na done. I wtedy ten członek zespołu, który ma wolne przebiegi, może ewentualnie pomóc koledze z zespołu, aby szybciej zakończyć inne zadanie. I to jest taka motywacja dla zespołu, żeby wspólnie rozwiązać problem, który się pojawił, żeby móc ruszyć dalej z procesem developmentu. I celem takim kanbanowym jest ciągłe doskonalenie tego procesu. Zespół spotyka się oczywiście periodycznie, od czasu do czasu, żeby przedyskutować zmiany, które być może warto wprowadzić na stałe do procesu. I oczywiście te informacje wyświetlane na tablicy kanbanowej, pomagają temu zespołowi identyfikować w miarę szybko te miejsca w procesie, które wymagają tych usprawnień.

Gdzie Kanban sprawdzi się niemalże idealnie? Na pewno w projektach, które odpalasz z małymi zespołami. Małymi, czyli nie więcej niż 6-7 osób. Jeżeli potrzebujesz elastyczności w trakcie trwania tych prac nad produktem, czyli w trakcie developmentu, jeżeli chcesz być elastyczny, jeżeli chcesz zwiększyć także swoją osobistą produktywność. Ja korzystam z tablicy kanbanowej, robiąc sobie nawet taski personalne, osobiste, które dotyczą mojego rozwoju osobistego, rozwoju zawodowego. Jeśli szukasz np. dobrego sposobu na wizualne przedstawienie tego, jak postępuje projekt, to tablica kanbanowa charakteryzuje się dość dużą prostotą i jest rekomendowana tym, którzy chcą mieć szybki i łatwy podgląd na to, gdzie jesteśmy w procesie. Kanban sprawdzi się także w miejscu, gdzie chcesz ustalić właśnie ten limit work in progress, żeby nie zakopać się w liczbie zadań, które są w trakcie. Kanban może ci w tym pomóc i Kanban może ci także pomóc, jeśli twoja organizacja preferuje model ciągły prac, od iteracyjnego. Czyli powiedzmy takiego podzielonego na etapy. Dla przykładu powiem, że w różnego rodzaju help deskach, czyli w działach pomocy technicznej, gdzie siedzi grupa programistów i użytkownicy zgłaszają błędy, no to po drugiej stronie siedzi zespół, który łata te błędy i bardzo często pracuje na Kanbanie. Tam nie ma wielkiego scope’u, tam nie wiesz co się wydarzy jutro, tam po prostu kolejkujesz kolejne zgłoszenia od użytkowników i łatasz jeden po drugim. 

Gdzie się nie sprawdzi Kanban? Otóż Kanban na pewno nie sprawdzi się, jeśli twój proces jest naprawdę skomplikowany i zawiera wiele poziomów. Ponadto, jeżeli potrzebujesz rozplanować pewne fazy prac nad produktem w czasie, podzielić np. kamienie milowe na iteracje, tam też lepiej nie sięgaj po Kanbana. I jeśli chcesz wdrażać te kolejne zmiany, kolejne usprawnienia produktu właśnie w sposób etapowy, w sposób iteracyjny, chociażby po to, żeby móc lepiej i łatwiej wersjonować produkt w przyszłości. Czyli żeby było ci łatwiej ustalać, że ok, czyli na kolejne cztery sprinty, weźmiemy wrzucimy te funkcjonalności, dla użytkowników to będzie wersja 1.2 oprogramowania. A teraz pomyślmy co wrzucimy do wersji 1.3 itd. Kanban nie zakłada iteracyjności. Jeżeli takiej potrzebujesz, to nie idź w Kanban. 

Ale już przechodzimy do iteracyjności, ponieważ płynnie wchodzimy do świata Scruma. No i pogadajmy o tym Scrumie, o którym wspomniałem na początku, jakie ten słynny Scrum ma w ogóle wyróżniki. Ja troszkę mówię pół ironią, półserio – ja jestem ogromnym miłośnikiem Scruma, ale czasem drwię z tego, jak ludzie przewartościowują tego Scruma. Oni tak naprawdę nie potrzebują tego Scruma, ale implementują go do procesu na siłę, tylko dlatego, że gro ich znajomych też im to rekomendowało, no i wszyscy się chwalą później, opisy organizacji na stronach internetowych brzmią, że my jesteśmy Agile, my wdrożyli Scrum i dlatego jesteśmy tacy super. Ale Scrum nie świadczy o tym, że organizacja jest super, bo mógł zostać wdrożony do miejsca, gdzie nie był w ogóle potrzebny. Wracając do wyróżników scrumowych, w przeciwieństwie do Kanbana, który jest skupiony na usprawnianiu procesu, Scrum to jest pewna metodyka, która pomaga zrobić więcej pracy szybciej, ale za pośrednictwem sprintów. To jest oczywiście agilowa metodologia, co już wiecie, która zawiera tzw. inkrementy, pewne wartości dla użytkownika, dla odbiorców tego co robimy. I najczęściej Scrum spotykamy przy projektach, które opierają się na bardzo skomplikowanych pracach badawczo-rozwojowych. Zespoły scrumowe dodatkowo są małe, one muszą być małe i mogą pracować niezależnie od innych zespołów. To też jest bardzo ważne i to jest to miejsce, gdzie pojawia się wiele patologii w organizacjach. Organizacja dzieli duży zespół na mniejsze. Te małe zespoły wszystkie są cholernie zależne od siebie. Jak jeden zespół puści bąka, to drugi zespół na pewno to poczuje. Ale taka organizacja, która nie grzeszy powściągliwością, będzie mówiła, że oni są Agile i Scrum, ponieważ mają małe zespoły deweloperskie. Tylko tak długo jak te zespoły są piekielnie zależne od siebie, tak długo tego scruma tam nie będzie. To jest patologia quasi scrumowa.

Najczęściej w Scrumie wykorzystuje się sprinty, w sumie to zawsze, żeby wykonać konkretną robotę. Często te sprinty mają dwa tygodnie. Chociaż to też jest rzecz umowna, bywają sprinty tygodniowe, bywają 3-tygodniowe. Miesięczne trochę długie, ale też się z takimi spotykałem. Sprinty natomiast są zaplanowane z wyprzedzeniem. Przeprowadza się sprint planning, w czasie, którego zespół tworzy backlog sprintu i następnie odpala się sprint i deweloperzy z tego backlogu sprintowego biorą sobie zadania na tapetę, którymi się zajmują i nad którymi pracują. Z kolei zadania z tego backlogu, muszą być oczywiście zrobione w trakcie tych dwóch tygodni, to jest założenie. Skoro to jest sprint backlog, no to to jest backlog, który dotyczy, który ma się rozpocząć i zacząć w ramach tego konkretnego, na przykład dwutygodniowego sprintu. To jest umowa wewnątrz zespołowa. Oczywiście mamy też te codzienne, piętnastominutowe spotkania zespołu. Uczestnicy takich spotkań, potocznie nazywanych daily, codziennie opowiadają sobie o tym jaką wartość udało im się dowieźć dnia poprzedniego, żeby zbliżyć się do określonego celu, no i jaki mają plan na kolejne 24 godziny, czy tam na kolejne 8 godzin takich roboczych, żeby znów dowieźć tę wartość. Chodzi o to, żeby postępujące prace w zespole, były ze sobą zgrane. Stąd pomysł, żeby codziennie się łapać na takie krótkie catch upy i zsynchronizować się z tym, gdzie jesteśmy. Scrum oczywiście zachęca zespół do zarządzania jego produktywnością. W sensie produktywnością tego zespołu. I często pomocniczo stosuje się tzw. burndown chart, czyli wykres spalania, żeby członkowie zespołu mogli widzieć postęp prac na pierwszy rzut oka i tego jak oni się spalają. W sensie, jak są produktywni. 

To co także odróżnia Scrum od pozostałych metodologii Agile, to jest w jaki sposób operuje pewnymi rolami, pewnymi eventami tudzież artefaktami. No i pierwsza rola – product owner, ekspert produktu. To ten człowiek reprezentuje interesariuszy i biznes, przed zespołem deweloperskim. Jest oczywiście głosem klienta, ale także użytkowników, o tym trzeba pamiętać. Ja nie będę się rozwodził o product ownerze, ponieważ więcej o tej roli opowiadałem w podcaście nr 2, w którym skupiałem się na różnicach w kompetencjach pomiędzy product ownerem a product managerem. Serdecznie zachęcam, jeśli jeszcze drogi słuchaczu, nie miałeś okazji tego usłyszeć. Kolejną rolą jest zespół deweloperski. To jest grupa specjalistów, którzy dostarczają produkt, programiści, testerzy, designerzy. Scrum master oczywiście – nie należy o nim zapominać. Służebny, rzekłbym lider w organizacji, która upewnia się, że zespół podąża za tym scrumem. Bardzo ważna rola i bardzo właściwa, jeżeli chcemy dbać o wnoszenie wartości do tego naszego Scruma i kultywowanie go wewnątrz organizacji. Nie zapominajmy o scrum masterach. Istnieją oczywiście jeszcze dwa eventy – sprint review, gdzie ocenia się jak nam poszedł sprint, ale także retrospektywy. To takie cykliczne spotkania, gdzie zespół się spotyka i rozmawia o tym, co poszło nie tak, co powinniśmy usprawniać. 

Tyle o eventach, nie chcę się rozwodzić, wiadomo, odsyłam do Google. Przepraszam, że tak brutalnie, ale ważniejszą rzecz mamy do powiedzenia, mianowicie – w jakich projektach ten Scrum tak naprawdę się sprawdzi. Otóż, jeśli na projekty składają się małe, niezależne od siebie zespoły. Co to znaczy małe? To znaczy, że zespół nie powinien przekraczać liczby siedmiu osób. Jeżeli jest 9-10, nie nazywajmy tego scrumem. Ja mam ortodoksyjne podejście do metodologii. Jeśli pewne pryncypia mówią o max 7 osobach, to nie widzę powodów, żeby się tego pryncypia nie trzymać. W projektach także, w których zależy tobie jako project managerowi na tym lub product ownerowi, aby dążyć do jak największej optymalizacji prac programistycznych. Zwłaszcza w tych skomplikowanych projektach. Jak zoptymalizować pracę, to często nie jest zerojedynkowe. Także przy projektach, gdzie dążysz do ciągłego doskonalenia zespołu, produktu, komunikacji wewnątrz tego zespołu, jeżeli wersjonujesz swoją aplikację i chciałbyś ją podzielić na etapy, na iteracje, jeśli chcesz planować z zespołem prace w sposób właśnie iteracyjny, no to scrum wydaje się dla ciebie idealny. Nie bój się go użyć i eksploatować wspólnie ze swoimi współpracownikami. Ale pamiętaj drogi słuchaczu o tym, że Scrum nie sprawdzi się, gdy nie masz pełnej zgody zespołu, że oni naprawdę tego Scruma potrzebują. Nigdy, ale to nigdy nie wdrażaj Scruma na siłę, jeżeli członkowie zespołu, programiści, deweloperzy, testerzy, biznes, jeżeli oni tego nie czują, to nie funduj im tego w promocji. To musi być wspólna umowa i wspólna świadomość co do tego, że my tego scruma chcemy i będziemy nad nim pracować, będziemy się nim opiekować. 

Innym projektem, gdzie nie sprawdzi się Scrum to jest taki projekt, który nie jest bardzo skomplikowany. Np. ten help desk albo łatanie błędów, o których wspominałem przy okazji Kanbana. Tam, gdzie Kanban może, Scrum nie musi – tak bym uprościł te podejście. Oczywiście, jeśli bardzo szybko, ale to piekielnie szybko, chcesz wdrożyć produkt na rynek, nawet, jeśli produkt będzie daleki od ideału, no to też Scrum nie do końca musi ci w tym pomóc. Podobnie jak w przypadku projektów, gdy chcesz maksymalnie uprościć komunikację w zespole. Tutaj być może pomógłby ci extreme programming, metodyka, o której też za niedługo wspomnę. I teraz opowiem nieco o mniej popularnych metodykach zarządzania, które mogą lepiej albo gorzej pasować do twojego przyszłego projektu. Ja się też nie będę rozwodził, ponieważ każdej z metodyk poświęcę na pewno więcej czasu w moich przyszłych podcastach. Nie chcę wyczerpać tematu dziś, ale też nie chcę cię cholernie zanudzić. Stąd zachęcam przy tej okazji do zapisania się na mój newsletter na stronie bycjakmanager.pl. Zachęcam także do śledzenia moich mediów społecznościowych, zwłaszcza Instagrama i mojego prywatnego profilu zawodowego na LinkedIn. Śmiało wysyłaj do mnie zaproszenie do sieci kontaktów, na pewno je na LinkedIn przyjmę. Ja też dodam, że jeśli zapiszesz się na mój newsletter, to ja nie handluję danymi moich słuchaczy, nikomu twojego adresu mailowego ani imienia, bo to są dwie informacje, których potrzebuję nie udostępnię ani osobom trzecim, ani firmom i nie będę też spamował twojej skrzynki. Rozsyłam newsletter tylko i wyłącznie wtedy, gdy publikuję nowy podcast w sieci. Ale także w newsletterach uzupełniam niektóre informacje, o których zapomniałem wspomnieć w trakcie podcastu, więc jest tam też pewna wartość merytoryczna. 

Idziemy dalej. Czy słyszałeś drogi słuchaczu o czymś co nazywa się Scrumban? Otóż jeszcze lata temu i to w sumie przez długi czas, Scrumban był pewnym pośmiewiskiem. Jeżeli ktoś nie potrafił do końca wdrożyć Scruma i mylił go z Kanbanem albo wdrożyć Kanbana, bo mylił go ze Scrumem, to deweloperzy wewnątrz organizacji żartowali, że nie mamy ani jednego, ani drugiego, mamy Scrumban. Ale z czasem to podejście zaowocowało. W sensie te być może niedoskonałe wdrożenia Scruma albo Kanbana zaowocowały tym, że powstała taka troszkę poboczne metodologia nazywana Scrumbanem. I to jest tak naprawdę odpowiedź na pytanie, które wiele osób sobie w przeszłości stawiało – co by było, gdyby Scrum i Kanban mieli dziecko? No i w ten sposób powstał Scrumban, jako hybryda tych dwóch metodologii agilowych. To jest dziecko, które mawia się – posiada nos Scruma, ale oczy Kanbana. I teraz, jaki jest największy benefit takiego Scrumbana? Otóż nie ma w takim projekcie scrumowego decydowania o tym, który task z backlogu powinien trafić do kolejnego sprintu, bo normalnie to decyduje zespół, który task trafia do jakiego sprintu. A zamiast tego Scrumban pozwala zespołowi zaciągać kolejne zadania na bieżąco do sprint backlogu, jeżeli oczywiści capacity i wyporność zespołu na to pozwala. Czyli skończyłem jedno zadanie, ale nie martwię się tym, że w backlogu już nie ma zadań, tylko mogę sobie śmiało zaciągnąć do sprintu, kolejne zadanie z product backlogu na przykład, jeżeli tylko mam czas na to, żeby sobie kolejne zadanie wziąć. Ale obowiązuje jednocześnie ten kanbanowy limit work in progress, w czasie cyklu sprintowego. Czyli, pomimo że mamy sprinty, to mimo tego, nie możemy zaciągać sobie nie wiadomo ilu zadań, ponieważ ustaliliśmy sobie w takim kanbanowym stylu to, że nie bierzemy na przykład na tapetę więcej niż osiem jednocześnie uruchomionych zadań na backlogu. I teraz mając taki benefit kanbanowy, jednocześnie mamy benefity scrumowe, ponieważ wciąż możemy przeprowadzać scrumowe planowanie, review, tudzież retrospektywy. I tak naprawdę sprytnie zaimplementowany Scrumban może wnieść dużo wartości. Jeżeli kiedykolwiek jako project manager czy product owner spojrzałeś na Scruma i Kanbana, i pomyślałeś sobie – chciałbym ożenić jakoś ze sobą te dwie metodologie – no to Scrumban jest odpowiedzią na twoje marzenie senne. 

Natomiast jeśli miałbym jednym zdaniem odpowiedzieć, gdzie Scrumban się nie sprawdzi, no to w miejscach, gdzie w zespole znajdują się ortodoksyjni wyznawcy metodologii, którzy uważają, że Scrum i Kanban nigdy nie powinny się spotkać. Jeżeli jesteś takim ortodoksem, ja w sumie jestem ortodoksem, ja nie jestem fanem Scrumbana, ale jeżeli macie bardzo elastyczne, bardzo takie flexible podejście zespołu do metodologii jaką chcecie wdrożyć, macie na to budżet – śmiało, do it, spróbujcie. 

Kolejną metodologią jest metodologia Lean. Szybciutko o metodologii Lean. Troszkę mniej znana. Ona polega na tym, żeby maksymalizować wartość kliencką, przy jednoczesnym minimalizowaniu potrzebnych zasobów. O co chodzi? Chodzi o to, aby jak najbardziej zwiększać wartość, którą się dowozi dla klienta lub dla użytkownika, a jednocześnie jak najbardziej zmniejszyć zasoby, które są potrzebne do wytworzenia tej wartości. Lean management wywodzi się w sumie z japońskiej manufaktury, z tamtejszego przemysłu, gdzie zwiększało się jakość wytwarzanych dóbr, ale także redukowało się koszty produkcji. To jest dość mocno biznesowe podejście do zarządzania projektem. Ta metodologia identyfikuje 3 typy marnotrawstwa, znane jako 3M. Jako że to jest wywodząca się z Japonii metodologia, to tutaj mamy trzy takie terminy – muda, mura i muri. Muda zakłada, że należy się pozbyć z produkcji wszystkiego co kradnie czas, co kradnie pieniądze, co kradnie zasoby, a co tak naprawdę nie wnosi wielkiej wartości dla końcowego produktu. I te takie marnotrawstwa według mudy, to może być transport, prowadzenie produkcji w kilku miejscach. Magazynowanie niepotrzebnej ilości rzeczy, zbyt dużej ilości rzeczy, które są niepotrzebne. Mogą to być jakieś fizyczne dobra, które firma musi utrzymywać, a te z kolei długo czekają na swój finał. Kolejnym takim marnotrawstwem jest oczekiwanie. Jeśli firma musi czekać, aż maszyna skończy jakąś pracę. Albo musi czekać na materiały, które muszą dojechać. Albo musi czekać na cokolwiek, to jest to marnotrawstwo i trzeba to zlikwidować. Kolejnym marnotrawstwem wg mudy jest nadprodukcja. Gdy wytwarzamy więcej dobra niż potrzebują klienci. No i później musimy to magazynować, musimy o to dbać, to kosztuje czas, to kosztuje pieniądze. Jest jeszcze taki zwrot – overprocessing. On pojawia się wtedy, kiedy wdrażamy kolejne procesy do produkcji, chociaż tak naprawdę my ich nie potrzebujemy. No to po co my je wdrażamy, na siłę? Żeby managerowie, którzy wdrażają procesy mogli pokazać, że coś robią w naszej firmie? Zlikwidujmy procesy, których nie potrzebujemy. No i kolejnym takim marnotrawstwem są defekty, czyli gdy wytwarzamy produkty, które wymagają poprawek. Które zawierają błędy. To też kradnie czas i pieniądze. Z kolei Mura, to jest eliminowanie pewnych rozbieżności, które występują w przepływie pracy na poziomie różnych terminów, różnych operacji. Wyjaśniam – uspójnienie rozjazdów w procesie, żeby wszystko szło płynnym tempem. Podam przykład. Wyobraź sobie, że publikujesz magazyn lifestyle’owy, masz pewien deadline, ten deadline mówi o tym, że w ciągu dwóch miesięcy magazyn musi pójść do druku. I teraz, jeżeli zauważysz, że edytor spędza zbyt wiele czasu na edytowaniu samej treści, to może być jakiś dziennikarz, jakiś redaktor, no to siłą rzeczy, jeżeli jedna osoba, na początku procesu jest to dziennikarz lub edytor, spędza za dużo czasu na wartości merytorycznej, no to wtedy zespół designerski, który musi to jeszcze ładnie zaprojektować, będzie miał siłą rzeczy mniej czasu na zaprojektowanie tego, przed wypuszczeniem magazynu do druku. Ta filozofia mura w tym Lean management zakłada, że wtedy wykonasz pewną magię, która sprawi, że ten edytor będzie mniej czasu spędzał na edycji, tak, żeby ten zespół designerów miał tyle samo czasu na projektowanie, co edytor miał na edytowanie. No i ta trzecia filozofia, czyli muri, to jest pozbycie się przeładowania, żeby nic nie spowalniało zespołu. I to dotyczy na przykład managerów albo business ownerów, którzy teoretycznie wywołują niepotrzebny stres wśród pracowników i ten stres mogą wywoływać przez słabą organizacją pracy, przez niejasne zasady pracy. Przez korzystanie z niewłaściwych narzędzi. Usprawnij pracę tych managerów albo pozbądź się tych managerów. To jest bardzo brutalne, ale to jest też bardzo skuteczne.

Gdzie sprawdzi się Lean? Lean management sprawdzi się w miejscach, gdzie szukasz pewnego zbioru zasad, które pomogą ci wyciąć zbędne rzeczy z procesu i zoptymalizować przepływy w firmie, przy projektach, gdzie zawsze starasz się poprawiać i zwiększać jakość tego co oferujesz swoim klientom, no i oczywiście przy projektach, gdzie chcesz maksymalnie obniżyć koszty produkcji. Lean management może ci w tym pomóc. 

Natomiast, gdzie się nie sprawdzi? W miejscach, gdzie nie posiadasz budżetu na wdrożenie tej metodologii. Tutaj ważna rzecz, o której chcę wspomnieć, nawet jeżeli w teorii Lean management mówi o redukowaniu kosztów, to już samo jego wdrożenie do organizacji, do firmy, może być sporym kosztem. Oczywiście jest to koszt jednorazowy. Raz dobrze wdrożona metodologia będzie procentować na przyszłość przez kolejne lata, ale ten koszt trzeba podjąć. Więc pamiętajmy też o kosztach wdrażania metodologii. Nie sprawdzi się Lean management w miejscach, gdzie to co robisz wymaga prac badawczych i takiego bardzo elastycznego podejścia do wytwarzania dóbr dla klienta. Także w miejscach, gdzie lubisz eksperymentować i gdzie masz pewien budżet, nawet większy, na poszukiwania, na robienie researchu, na analizowanie rynku, na poszukiwanie tej idealnej, być może najlepiej dopasowanej chociażby metodologii. Jeżeli masz więcej elastyczności, to nie musisz się wcale Lean managementem tutaj zamykać w te ramy takie bardzo biznesowe, bardzo skrojone pod produkcję. 

Six sigma – przedostatnia metodologia, o której chcę wspomnieć. Six sigma to metodologia zarządzania projektami, o której tak naprawdę jako pierwsi opowiedzieli światu inżynierowie Motoroli. I to było w 86 roku ubiegłego wieku, czyli rok przed moimi narodzinami, bo ja jestem rocznikiem 87. I ta metodologia, ja tutaj tylko dwa słowa o niej powiem, bo nie chcę poświęcać jej zbyt wiele czasu – ona zakłada zwiększanie jakości poprzez zmniejszenie liczby błędów w procesie. W skrócie – najpierw zidentyfikuj to co nie działa i usuń to z procesu. I Six sigma stosuje pewne jakościowe metody zarządzania, zarówno takie empiryczne, jak też statystyczne. Oczywiście ta metodologia uznaje ekspertyzy specjalistów tych metod, bo tak naprawdę każdy projekt Six sigma, który jest realizowany w ramach organizacji, odbywa się wg pewnej określonej sekwencji i zbioru etapów, no i ma konkretne wartości docelowe, np. skrócenie czasu cyklu procesu. Zmniejszenie zanieczyszczenia, zmniejszenie kosztów. Zwiększenie zadowolenia klientów i zwiększenie zysków chociażby. Skupia się bardziej dokładnie na pewnych metrykach, które chcemy przepracować i jeszcze bardziej usprawnić. 

Jednym zdaniem – Six sigma sprawdzi się przy projektach, gdy mówimy o bardzo dużej organizacji, która chce stale polepszać jakość oraz efektywność produktu, ale przede wszystkim zespołu i ta organizacja bazuje w głównej mierze na metodologii Data-Driven, czyli opartej na danych. 

Ostatnia metodologia, która jest jedną z moich ulubionych, muszę przyznać. Nie miałem zbyt wiele okazji w życiu, żeby wdrażać tę metodologię do zespołów, ale uważam, że ma dość duży potencjał, ponieważ wierzę, że siła tkwi w prostocie. Tą metodologią jest Extreme Programming, w skrócie XP, a po polsku Programowanie Ekstremalne. I to jest metodologia dedykowana głównie wytwarzaniu oprogramowania i ona kładzie nacisk na pracę zespołową wzdłuż całej organizacji, tj. od menadżerów, przez klientów, na deweloperach kończąc. I tutaj zespoły muszą być samoorganizujące. Jest takie 5 zasad, które definiuje ta metodologia programowania ekstremalnego. Pierwszą zasadą jest prostota, drugą jest komunikacja, najlepiej twarzą w twarz. Trzecią jest feedback, czyli obiektywne ocenianie się nawzajem. Czwartą zasadą jest szacunek. Traktujemy się z szacunkiem, niezależnie od statusu i pozycji w firmie. No i ostatnią zasadą jest odwaga. Musimy mieć odwagę, żeby działać dynamicznie, działać razem, być szczerymi, feedbackować się nawzajem, trzymać tę komunikację, pilnować prostoty naszej pracy. To wszystko wymaga odwagi. I w przeciwieństwie do Scruma, Extreme Programming pozwala na ciągłe zmiany w roadmapie albo w bieżącym planie prac. Tak naprawdę nie chcę powiedzieć, że wszystkie chwyty dozwolone, ale powiedziałbym, że wszystkie chwyty dozwolone, jeśli mieszczą się w ramach tych pięciu zasad. Funkcjonalności nad którymi pracujemy, one nie muszą być idealne. My nie musimy mieć dopieszczonego produktu, który chcemy wypuścić na rynek. Te funkcjonalności muszą być akceptowalne. Jeżeli klient jest z czymś ok, no to dla nas jako zespołu deweloperskiego oznacza to zielone światło dla relase’u, klient jest ok, wdrażamy na rynek, a marketing komunikuje produkt. Mnie się Extreme Programming kojarzy ze Stanami Zjednoczonymi, a przede wszystkim z Doliną Krzemową, bo tam jest cholernie dużo startupów. I teraz każdy startup dostał jakieś niewielkie dofinansowanie w postaci bańki czy dwóch baniek na start, przy pierwszej transzy inwestorskiej i tam, uwierzcie mi, że business ownerzy nie bawią się w jakieś Scrumy itd. Tam leci programowanie ekstremalne. Ale wydaje mi się, że pewną szlachetnością menadżerską jest to, aby nawet, kiedy biegniemy, kiedy skaczemy przez płotki, kiedy wdrażamy coś szybko i potrzebujemy jak najszybciej to wydać na rynek jest to, aby trzymać się tych pięciu zasad, które definiuje programowanie ekstremalne – prostota, komunikacja, feedback, szacunek i odwaga. 

Gdzie sprawdza się XP? XP sprawdza się w miejscach, gdzie chcemy pielęgnować pracę zespołową. I drugie takie założenie, przy którym sprawdza się programowanie ekstremalne, to jest wtedy, kiedy masz niewielki zespół, który – i to jest niemalże konieczne – pracuje w tej samej strefie czasowej, a idealnie, jeśli pracuje w tym samym biurze, kiedy nie masz pracy zdalnej, ponieważ ta komunikacja twarzą w twarz, ten duży nacisk na komunikację, na prostotę, zakłada, że my nie chcemy sobie w żaden sposób życia biurowego komplikować. Mały zespół, to samo biuro, ta sama strefa czasowa, najlepiej nawet ten sam język. My po prostu chcemy zadbać o jak największą prostotę. Jesteśmy odważni, żeby to zrobić. 

Natomiast Extreme Programming nie sprawdzi się na pewno w miejscach, gdzie twój zespół jest rozsiany po różnych biurach, różnych strefach czasowych, a tym bardziej, jeśli operuje na różnych poziomach językowych. W sensie, wiadomo, że oczywiście zespoły rozsiane międzynarodowe, tym językiem umownym jest język angielski, ale znów – to gdzieś przeczy prostocie komunikacji. W miejscach, gdzie lubisz zmieniać albo łamać zasady i żeby dopieszczać ten proces, no to też Extreme Programming nie jest dla ciebie. Chcesz wymyślać zasady, łamać zasady – sięgnij po jakąś inną agilową metodykę, chociażby Scruma, on daje dużą dowolność. Także w miejscach, gdzie mamy projekty przypisane do dużych organizacji albo w takich organizacjach, gdzie dąży się do ustabilizowania tego procesu, do wdrożenia pewnej iteracyjności, do pewnych cyklów prac nad produktem. Bardzo wiele startupów, małych firm, zaczyna od programowania ekstremalnego, a później, kiedy produkt trafia na rynek i ta sytuacja w firmie się nieco stabilizuje, dopiero wtedy business ownerzy stwierdzają – ok, już nie musimy tak pędzić. Możemy sobie wdrożyć jakąś fajną metodykę, planować długoterminowe nasze prace, więc odchodzi się wtedy od programowania ekstremalnego, na rzecz jakichś fajnych elastycznych metod agilowych. 

No i to tak naprawdę tyle z mojej strony. To wszystko co chciałem ci dziś wyłożyć. Mam nadzieję, że nie zasnąłeś do tego momentu. Serdecznie dziękuję za każdy komentarz i opinię jaką być może zostawisz w moich mediach społecznościowych lub prześlesz mi bezpośrednio na adres mailowy albo przez media społecznościowy. Zachęcam jeszcze raz do zasubskrybowania mojego newslettera na stronie i tutaj obiecuję po raz kolejny, że nie wykorzystam twojego adresu mailowego w żadnej nieprzyzwoity sposób. Na dziś dziękuję. Będę serdecznie wdzięczny, jeżeli uznasz, że wyczerpałem temat, ale także będę wdzięczny, jeśli uznasz, że ja tego tematu nie wyczerpałem i powinienem zrobić dogrywkę. Chciałem tym tematem i tym podcastem udowodnić, jakoby że nie zawsze powinniśmy być tak namiętnie i romantycznie zapatrzeni w Scruma, ponieważ wokół nas jest dużo równie pięknych, wspaniałych i barwnych metodyk zarządzania, po które możemy sięgnąć, jeśli nasz zespół, nasz projekt i nasza organizacja, naprawdę tego wymaga. 

Dobrego dnia, dbaj o siebie i innych. Cześć.