Agile, czyli metodyka zwinna, a może wcale nie metodyka? Czym jest Agile i 12 zasad AGILE „metodyki” zwinnej? Kiedy w ogóle stosować Agile? Jakie są zalety prowadzenia projektów wg Agile? Dzisiaj wszystko, co warto wiedzieć o Agile i o metodykach zwinnych na start.
“Metodyka” Agile
Dlaczego słowo metodyka wrzuciłem w cudzysłów? Bo Agile jest na tyle modnym słowem, że przyczepia się do wszystkiego. O metodyce powiem czy jest czy nie jest, jak o tym myśleć, bo dużo osób jak usłyszy Agile to myśli, że tam jest pewne rozwiązanie na wszystkie problemy.
Co to jest Agile? Zacznijmy od definicji Agile to iteracyjne podejście do zarządzania projektami i tworzenia oprogramowania, które pomaga zespołom dostarczyć wartość klientom szybciej i przy mniejszej liczbie problemów. Zamiast stawiania wszystkiego na jedno wielkie wdrożenie zespoły Agile dostarczają pracę w niewielkich ale użytecznych przyrostach. (źródło definicji: attlasian.com/pl/agile).
W skrócie jak myśleć o Agile – to pewien sposób podejścia do wytwarzania czegokolwiek. Nie chcesz tego robić na zasadzie dużej kobyły, gdzie najpierw sobie zaplanujesz, później przygotujesz i czekasz na wynik. Agile powstało, dlatego, że są sytuacje, w których nie do końca wiesz co chcesz uzyskać. Wtedy planowanie, myślenie nic nie da, bo niektóre rozwiązania można zrobić tylko wtedy, gdy robi się je w trakcie doprecyzowując. Popełniasz dużo błędów, żeby sobie uświadomić o co naprawdę chodzi. Są projekty, które w ten sposób warto poprowadzić, ale są też projekty, w których już ktoś dobrze wymyślił pewne rzeczy i tam nie ma co wydziwiać. Tradycyjne projekty typu budowa mostu, wiesz jakie są zasady budowania mostów, zbudowano ich miliony, jest więc pewna rama według której będziesz postępował. Jednocześnie w trakcie wytwarzania możesz działać w zwinny sposób, bo na froncie robót dzieją się różne rzeczy – coś nie dojedzie, coś się zmienia, mimo całej analizy coś idzie nie tak. W skrócie zwinność polega na tym, żeby nie zakładać, że jesteś w stanie wszystko przemyśleć od początku do końca, tylko ruszyć w drogę i dać sobie prawo do dopracowania rozwiązania w trakcie. To jest esencja Agile. Problemy będą inne niż w projektach, w których dokładnie wiesz co robisz.
SCRUM, Lean, Kanban, Extreme Programming i inne
Powstało bardzo dużo rozwiązań, które jakoś starają się filozofię Agile przełożyć na narzędzia, metody i techniki, które można wykorzystać. Są podejścia bardziej lżejsze i takie, które są bardziej złożone.
Do tych lżejszych będzie należał SCRUM, gdzie cała metoda jest opisana, cały framework jest opisany na 16 czy 20 stronach, nigdy nie pamiętam, ale to małą ilość. Mówi o tym, że jak będziesz pracować w ten sposób to zachowasz zwinne zasady, jednocześnie masz zespół, który dostarcza wartość kawałkami i to wszystko rośnie.
Lean software development to połączenie podejścia z produkcji z software. Kanban, Extreme Programming – wykorzystywałem częściowo to podejście jak tworzyłem moja własną metodę.
Zwinność u źródła dotyczyła małych zespołów, bardzo dziwne jest to, że ta zwinność faktycznie działa przy mniejszych zespołach, a przy większych logika zaczyna się załamywać. Ludzie dążyli do tego, żeby stosować podejście Agile na większych zespołach i tak powstało Scrum-of-Scrums, Large-scale Scrum, Scaled Agile Framework itd. Jest cała masa metod, które mówią o zwinności na większą skalę. Nie neguję ich, warto rozumieć dlaczego takie powstały i gdzie możesz je zastosować, bo nie ma szansy, żeby wybrać z tego coś w miarę szybko.
Dzisiejszy film to kolejny odcinek, w którym bierzemy pod lupę Scrum Guide. Opowiem o teorii i filarach empiryzmu w Scrumie, czyli przejrzystości, inspekcji oraz adaptacji.
Definicja SCRUM
Definicja jest następująca – SCRUM to uproszczone ramy postępowania, które pomagają poszczególnym osobom, zespołom i organizacjom wytwarzać wartość poprzez adaptacyjne rozwiązywanie złożonych problemów.
Pierwsza bazowa rzecz – uproszczone ramy postępowania, ma być proste, daje pewną perspektywę w której działamy i pokazuje jak działać, żeby osiągnąć pewien rezultat. Wytwarzanie wartości – nie chodzi o to, żeby pracować więcej, tylko, żeby na koniec mieć rezultaty. Adaptacyjne rozwiązywanie złożonych problemów – adaptacyjne oznacza, że uczymy się. Musimy się nauczyć jak doprowadzić do danego rozwiązania, jak ze sobą pracować. Scrum nie powstał po to, żeby go używać do każdej rzeczy, to odpowiedź na sytuacje, gdzie mamy złożony problem, którego nie da się łatwo przeanalizować. Scrum to ramy postępowania, które pozwalają ci przepracować taki problem i przerobić na kawałki pracy, które da się przerobić, zebrać feedback i poprawić. Jeżeli zespół nie ma jasności jak coś zrobić to można wpaść w pułapkę, to nie róbmy, albo poczekajmy aż ktoś powie. Całe rozwiązanie kryje się pod spodem. Jak natrafisz na taką sytuację to Scrum jest dobrym pomysłem. Cynefin framework jest jednym z najfajniejszych modeli opisujących rzeczywistość, że nie jest ona jednoznaczna. Jedne projekty są poukładane, inne chaotyczne.
Teoria Scrum
Po kolei, zobaczmy co mówi nam Scrum Guide o teorii Scrum. “Fundamentem Scruma jest empiryzm i koncepcja lean. Istotą empiryzmu jest to, że wiedza wynika z doświadczenia, a decyzje podejmowane są na podstawie tego, co można zaobserwować.” To teraz się zastanówmy. Według mnie wiedza wynika też z innych źródeł, nie tylko z doświadczenia i tego co można zaobserwować. Warto robić to co mówią starsi, bardziej doświadczeni. Jak mówią nie rób tego, to warto posłuchać, po to, żeby się nie wpakować w problemy. To oczywiście oznacza, że pewnego doświadczenia nie zdobędziesz, ale to oszczędza życie. Nie jest tak, że nie zgadzam się ze stwierdzeniem z przewodnika, faktycznie tak jest, że dostajesz jakieś zasady, na nich pracujesz i dopiero jak doświadczysz pojawia się głębsze zrozumienie. Kwestia wyważenia tego w praktyce. Potrzebujemy czegoś doświadczyć, żeby zebrać z tego głęboką wiedzę, to jak najbardziej ma sens.
Jeśli nie wiesz jeszcze na czym polega zarządzanie projektami, na pewno warto odwiedzić artykuł – Zarządzanie Projektami – co to właściwie jest.
“Koncepcja lean ogranicza straty i koncentruje się na tym co najważniejsze.” Jak najbardziej się z tym zgadzam. Weźmy się do roboty i skupmy na tym, żeby nie robić roboty bez sensu, dla samej formy.
“Scrum wykorzystuje iteracyjne, przyrostowe podejście w celu zwiększania przewidywalności oraz kontrolowania ryzyka.” Jak to tłumaczyć sobie na życie? To oznacza małymi krokami do przodu, dlatego, że trudniej dzięki temu wpaść w przepaść. Scrum został zaprojektowany i działa dobrze w pewnym środowisku, w którym małymi kawałkami musisz zorientować się o co chodzi. Skakanie w przepaść skończy się słabo. Dlatego przy projektach złożonych w których robi się podejście Waterfallowe, jak nie wiadomo z czym się będziemy mierzyć, prawdopodobnie strzelimy sobie w kolano. Dlatego iteracyjnie krok po kroku Scrum prowadzi nas dalej.
“Scrum polega na pracy grup osób wspólnie posiadających wszystkie umiejętności oraz specjalistyczną wiedzę potrzebne do wykonania pracy oraz dzielą się tymi umiejętnościami bądź nabywają je w miarę potrzeby.” Albo masz ekspertów, których zebrałeś i wiedzą o co chodzi, albo masz przestrzeń na ich rozwój. Pytanie jak to jest u Ciebie. To ważny punkt filozofii. Dostajesz ludzi, którzy są nowi, nie ma czasu na ich rozwój i jedziemy, to nie jest dobre. Pozyskiwanie wiedzy jest częścią projektu. Zabudżetowanie sobie części czasu, pieniędzy na to, żeby się nauczyć to dobry pomysł.
“W Scrumie odbywają się cztery formalne wydarzenia umożliwiające inspekcję i adaptację w ramach obejmującego je wszystkie wydarzenia jakim jest Sprint. Wydarzenia te są konstruktywne i produktywne, ponieważ tworzą filary empiryzmu w Scrumie, czyli przejrzystość, inspekcję i adaptację.” To jest genialne, ze względu na prostotę, a te wydarzenia które się dzieją wyciągają wszystko na wierzch. Ludzie muszą zobaczyć jak jest, dać sobie feedback, nie ma za dużo miejsca na kombinowanie. Scrum jest skonstruowany tak, żeby zebrać doświadczenie, wartość i podziałać.
Pierwszy filar empiryzmu w Scrum – Przejrzystość
Promuję to gdziekolwiek się da, jeżeli nie wiesz jak jest naprawdę i tworzysz kulturę, w której bardziej opłaca się coś zamiatać pod dywan to podejmujesz decyzje na ślepo. Jest taki okres, szczególnie na początku, że nie wiesz co się dzieje i działasz bardziej na czuja. W pewnym momencie zaczynasz zbierać dane i możesz mierzyć się z rzeczywistością. “W Scrumie ważne decyzje podejmowane są na podstawie zaobserwowanego stanu jego trzech artefaktów.” Minimalna ilość artefaktów w Scrumie ma spory sens. Wiesz w każdym momencie co się dzieje, to prowadzi do sytuacji, w której możesz podejmować sensowne decyzje. “Przejrzystość umożliwia inspekcję” Jak nie wiesz, nie możesz zajrzeć jak działa mechanizm, to nie jesteś w stanie przejść do kolejnego etapu. “Inspekcja bez przejrzystości prowadzi do błędów i strat.” Dlaczego nie wszyscy mogą chcieć przejrzystości? Jak spojrzymy na statystyki problemów w projektach, to 55% ma problem z tchórzem projektowym. Ludzie nie mówią jak jest naprawdę, bo bardziej opłaca im się ukryć prawdę, albo zwalić winę na kogoś innego. Ponad 80% projektów ma problem z manipulowaniem priorytetami. Im bardziej to jest mgliste tym większa szansa, że ugrasz coś dla siebie. Jest dużo elementów, które sprawiają, że przejrzystość wcale nie jest prosta dla wdrożenia, ale bez niej nie ma efektywności. Nie zrobimy sensownej inspekcji i nie poprawimy tego co się dzieje.
Drugi filar empiryzmu w Scrum – Inspekcja
“Artefakty Scruma oraz postępy w dążeniu do uzgodnionych celów muszą być poddawane częstej i rzetelnej inspekcji, aby możliwe było wykrycie potencjalnie niepożądanych odstępstw lub problemów.” Wracamy do cyklu Deminga, esencją Inspekcji jest stanięcie w prawdzie. Jak naprawdę jest, to fajne doświadczenie, które warto samemu sobie przećwiczyć, stanięcie w prawdzie jak jest. Nie chodzi o kontrolę, chodzi o sterowanie, zobaczenie jak jest i podjęcie sensownych decyzji. “Aby to ułatwić Scrum zapewnia stały rytm w postaci pięciu wydarzeń.” Stały rytm pozwala na wyeliminowaniu błędu pomiaru. Jeżeli w różnych odstępach czasu sprawdzasz projekt, to trudno jest sprawdzić skąd wynikają odchylenia pod kątem dostarczeni zakresu. “Inspekcja bez adaptacji jest uznawana za bezcelową.” Czy czasem spotkania statusowe nie są sztuką dla sztuki? Spotykacie się, nic z tego nie wynika, nie ma przypisanych osób i następnych kroków. Po co sprawdzać jak jest, jeżeli nic z tym nie zrobimy. Inspekcja nas kosztuje, więc wyciśnijmy z niej jak najwięcej. “Celem wydarzeń w Scrumie jest wywoływanie zmian.” Warto popatrzeć na to głębiej. Stałe doskonalenie, świadomość tego, że musimy się zmieniać. Jak zaczyna zespół ze sobą pracować to dużo rzeczy nowych zaczyna wyskakiwać, jeżeli podchodzimy z podejściem adaptacyjnym, będziemy musieli się zmieniać to szczególnie na starcie warto wyciągać jak jest, co się dzieje. W Scrum każda zmiana ma swój koszt, jeżeli jest to transparentnie pokazane to klient wie, że jeżeli chce wrzucić więcej pracy do zrobienia, to musi za to zapłacić kosztem nie zrobienia czegoś innego.
Trzeci filar empiryzmu w Scrum – Adaptacja
“Jeśli jakikolwiek aspekt procesu wykracza poza dopuszczalne limity lub jeśli uzyskany produkt jest niemożliwy do zaakceptowania stosowany proces lub wytwarzane materiały należ